Develop SharePoint web parts in ASP.NET

Question

I have been asked to develop some usercontrols in ASP.NET that will at a later point be pulled into a SharePoint site as web parts. I am new to SharePoint and will not have access to a SharePoint server during the time I need to prototype these parts.

Does anyone know of any reasons that this approach will not work? If this approach is not recommended, what would other options be? Any suggestions on a resource/tutorial on what to consider when developing an ASP.NET web part with SharePoint in mind?

Thanks

Edit: 12/31/2008 I finally marked an answer to this one. It took me a while to realize that going the SharePoint route right away, though painful at first, is the best way to go about it. The free VPC image makes getting set up to develop relatively painless.

While you can, as I did, develop web parts in ASP.NET without SharePoint, when it comes to developing and deploying SharePoint applications you haven't learned a thing, only pushed the learning curve off into a time when you think you are done, (and have probably informed stakeholders to that effect). To delay the SharePoint learning curve doesn't do you or your project any favors, and your final product will better for the expertise you gain along the way.

Answer 1

you need to have access to a sharepoint server because you can't simulate your webpart without it, you have to deploy it to your sharepoint site to test if it's working. debugging would also be a pain. or you can use SmartPart, it's a webpart that acts like a wrapper for your user controls to display in a sharepoint site.

Answer 2

I guess the easiest way is to use the SmartPart for SharePoint from CodePlex. The project description says "The SharePoint web part which can host any ASP.NET web user control. Create your web parts without writing code!", which I guess is exactly what you want to do.

Answer 3

Setting up my machine to develop for Sharepoint took me a couple of days.

See http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx

Answer 4

Build and test the control as you would for a typical .net web site. Solution 1 = the controls Solution 2 = dummy website to host the controls.

Deployment on Sharepoint:

You'll need to sign the controls.

Drop the signed DLL into the GAC on the sharepoint server (Windows/assembly)

Mark the control as safe in the virtual server root web.config on the sharepoint site.

i.e.

<SafeControl Assembly="MyControl, Version=1.0.0.0, Culture=neutral, PublicKeyToken=975cc42deafbee31" Namespace="MyNamespace" TypeName="*" Safe="True" AllowRemoteDesigner="True" />

Register the component in your sharepoint page:

<%@ Register Namespace="MyNamespace" Assembly="MyControl, Version=1.0.0.0, Culture=Neutral, PublicKeyToken=975cc42deafbee31" TagPrefix="XXXX" %>

Use the control:

<XXXX:ClassName runat="server" Field1="Value1" Field2="Value2" ....></XXXX:Classname>

If you need to replace the control using the same version number, then you'll need to recycle the app pool to reload.

Answer 5

If you don't need to do anything SharePoint-specific (ie accessing lists, other webparts, etc) then you can build your webpart just like a regular webpart (derived from System.Web.UI.WebControls.WebParts.WebPart class) and it will work when added to a SharePoint site.

Answer 6

ASP.NET web parts work in SharePoint the same as they work in ASP.NET. That's the route I would take (custom control that derives from the ASP.NET Web Part class). This will alleviate any requirement to actually develop on a SharePoint server.

The only issue you are going to encounter is that you will not be able to take advantage of the SharePoint framework. If you are doing anything advanced in SharePoint this is a big deal. However, SharePoint is ASP.NET plus some additional functionality, so anything you can develop using the System.Web.UI.WebControls.WebPart class should work great in SharePoint.

Some considerations that will help ease your pain as you go from pure ASP.NET to SharePoint:

• If you can put everything inside of a single assembly, deployment will be easier
  • try to put everything you need into the DLL's that are deployed to SharePoint
  • use assembly resources to embed JS, CSS, and image files if needed
• Strong name the assembly you are building
  • Most SharePoint deployments end up in the GAC and a strong name will be required

Here is a relevant blog post; Developing Basic Web Parts in SharePoint 2007

Answer 7

If it's a very short-term thing, Microsoft has a time-limited WSS evaluation VPC image:

WSS3 SP1 Developer Evaluation VPC image

That will get you started if you don't have time/resources to set up your own VPC image right now.

Answer 8

You do not need SharePoint to develop WebParts. You can develop webparts by inheriting from the System.Web.UI.WebControls.WebParts. And this is the preferable way of creating web parts unless you want the following features like

* Connections between web parts that are outside of a Web Part zone

* Cross page connections

* A data caching infrastructure that allows caching to the content database

* Client-side connections (Web Part Page Services Component)

In which case you need to develop webparts by inheriting from Microsoft.SharePoint.WebPartpages.WebPart. You can find more useful info here

Answer 9

Is there any particular reason why your user controls must be deployed as web parts? It is perfectly feasible to deploy user controls directly to Sharepoint sites either through the CONTROLTEMPLATES folder in the 12 hive or to a location in the web app virtual directory, which you can then reference from web pages using Sharepoint Designer.

If however the web part requirement is crucial then I recommend Smartpart for Sharepoint as already mentioned.

Answer 10

Actually, Web Parts should always be deployed to the sharepoint's bin folder due to their 'abusive' nature. Always deploy web parts to the bin if possible and write your own CAS and include it in your manifest.