Writing WSS2.0 WebParts using Visual Studio 2005

Problem statement:

Your corporate intranet portal/site is using Sharepoint Portal Server 2003 / Windows Sharepoint Services 2.0. You are mulling over whether to have Visual Studio .Net 2003 or the newer, cooler, and definately awesome Visual Studio 2005 as your corporate development tool of choice. You also want to make sure that you can develop webparts for SPS 2003/WSS2.0 using the same IDE.

Tough choice? It's really simple.

Here's how:

1.) Ditch Sharepoint Portal Server 2003. Upgrade to the latest, baddest kick-ass portal in town, SharePoint Server 2007. Go with Visual Studio 2005, and you will attain unparalleled awesome-ness.

2.) If you MUST develop for SharePoint Portal Server 2003 with Visual Studio 2005 - see #1 above.

Ok, seriously. Building web parts for SPS 2003/WSS2.0 using Visual Studio 2005, and you will undoubtedly venture into the problem area where you would want to use VS 2005 to build for .Net 1.1 runtime.


Enter MSBuild, the Microsoft Build Engine for Visual Studio / .Net platform. All it takes is some target specifications to direct MSBuild to build for .Net 1.1 runtime. Sounds easy? Not.


Unless you have MSBee, which will provide us some pre-defined target files to use with MSBuild. To install MSBee, make sure you have all the pre-requisites already installed (as noted in its download page).

Now we are ready to build a webpart on .Net 1.1. Since we don't have any Web Part templates for SPS2003/WSS2.0 in Visual Studio 2005, we will start off with a plain old Class Library project.

First thing to do is to add a reference to Microsoft.Sharepoint.dll assembly from C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\ISAPI\

Add the "using" redirectives for Microsoft.Sharepoint, and remove the default System.Collections.Generic - we don't have generics in .Net 1.1.


using System;
using System.Text;
using Microsoft.SharePoint.WebPartPages;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Reflection;

namespace SharePoint2003WebPart
    public class MyWebPart: WebPart
        protected override void CreateChildControls()
            Label message = new Label();
            message.Text = "CLR Version: " + Assembly.GetExecutingAssembly().ImageRuntimeVersion;

Next, open the .csproj file, and add the following import statements into it:

Add a reference path to the project so that MSBuild can locate our Microsoft.SharePoint.dll assembly:

Provide a strong name key and we're ready. We have to sign it the old-fashioned VS.Net 2003 way - use "sn -k yourfile.snk" and adding the attribute [assembly: AssemblyKeyFile(../../yourfile.snk")] into AssemblyInfo.cs.

Now we are ready to MSBee it. From the Visual Studio command prompt, use the following command line:

msbuild {your csproj file} /p:TargetFX1_1=true

Almost there now... Grab the assembly under the bin\FX1_1\debug (or release) folder, (instead of \bin\debug) and drop it into the Global Assembly Cache. 

For SPS2003/WSS2.0 webparts, we need to create a corresponding .dwp file, contrasting to the self-reflected .webpart file in MOSS. In Visual Studio 2005, add a new xml file and name it anything with .dwp extension. Get the PublicKeyToken value from the GAC, or use the -T command line switch with the Strong Name utility: sn -T assemblyName.

<?xml version="1.0"?>
<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2">
   <Assembly>AssemblyName(with no .dll extension), Version=VersionNumber, Culture=Culture, PublicKeyToken=PublicKeyToken</Assembly>

From SPS2003/WSS2.0 site, import the newly created dwp file, and we're done!

Can it be better? You bet.

Right-click on your Visual Studio 2005 menu bar, and select Customize (waaay down below). On the Commands tab, select "Rearrange Commands". Select "Add" and choose "File" and then "Export Template" from the Commands selection.

When done, the new "Export Template" command will be available from the "File" menu. What this do is to take the existing SharePoint2003WebPart project and convert it into a Project template with all the project import targets and references intact, and the .dwp file is included as well.