Building Web Parts for SharePoint Products
and Technologies
Add features to your SharePoint sites through reusable Web Parts
by Jason Mauss

For This Solution: C#, Microsoft ASP.NET 1.1, Microsoft Windows SharePoint Services Beta 2, Microsoft Windows Server 2003, IIS 6.0, Microsoft Visual Studio .NET (2002 or 2003)

With the release of Microsoft ® Windows ® SharePoint ^TM Services 2.0, both developers and users will have a much more powerful way of pulling information from multiple locations into a single display. Included is an extensible infrastructure (including a .NET object model) for building components from which users can assemble their own sites.

At the heart of this infrastructure are three things. First, there are Web Part Pages, which are the pages the end users see and can personalize to fit their needs. Second, contained within Web Part Pages are Web Part Zones, which are the containers of the third item, Web Parts. The focus of this article is to show you how you can build Web Parts that users can then add to their Web Part Pages, customizing the look (if desired).

The Skinny on Web Parts
As mentioned earlier, SharePoint Services provides a .NET object model for you to program against, in much the same fashion as does the standard .NET Framework. In fact, the Web Part infrastructure extends many of the ASP.NET classes. One of the classes the SharePoint Framework contains is the WebPart class, located in the Microsoft.SharePoint.WebPartPages namespace. This is the base class that your Web Parts inherits from.

Much like ASP.NET server controls, Web Parts are simply classes that extend from a base class in the same way server controls inherit from either the Control or WebControl class. Furthermore, the Web Part Infrastructure provides interfaces your classes can inherit from, that enable your Web Parts to be data-aware, communicate with each other, share information, synchronize their behavior, or even filter values for a Web Part based on the selection in another Web Part. Figure 1 illustrates the way Web Part Pages contain Web Part Zones, which contain Web Parts. Because Web Parts are an extension of server controls, you have the ability to do anything with Web Parts than you can do with server controls, such as consuming a Web Service, or accessing data sources with ADO.NET.

What role does SharePoint Services play in all this? Web Parts are dependent on SharePoint Services to provide many things. SharePoint Services manages the sites, user permissions (who has access to certain resources on the SharePoint machine, like the ability to customize Web Parts), and persistence (through a database and/or XML) of users' customizations made to one or many Web Parts. SharePoint Services also manages the underlying architecture Web Parts rely on to function. Figure 2 shows this relationship.

One of the major differences between ASP.NET server controls and Web Parts is the way in which they are consumed. With ASP.NET server controls, you are adding them to ASP.NET pages by changing the page source, perhaps with an IDE like Visual Studio .NET. With Web Parts, users do not have to edit the page source but can drag them into a Web Part Zone within a Web Part page within their Web browser. Just like an ASP.NET Server Control, the Microsoft.SharePoint.WebPartPages.WebPart base class inherits from the same parent class as server controls, the System.Web.UI.Control class. Thus, in order to create a Web Part, your Web Part class must inherit from the WebPart base class. By inheriting from this class, your Web Part inherits all the properties, methods, and other functionality of the WebPart base class, such as a Title property that allows you to modify the text displayed on the title bar of your Web Part.

Building a Web Part for Windows SharePoint Services
Start by downloading the Web Part template at Web Part Templates for Microsoft Visual Studio .NET. You can install the Web Part Template so that a “Web Part” project type appears in your New Project options in Visual Studio .NET for both C# and VB.NET Projects. You can choose which languages you want to install templates for during installation. Another requirement during installation is to input the location of Microsoft.SharePoint.dll. This can be found at local_drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\ISAPI\ once you have installed Windows SharePoint Services on your computer. The Web Part template automatically generates much of the boilerplate code and required namespace references required for building Web Parts. The template also generates an XML Web Part class file (.dwp) that contains Web Part metadata and an XML manifest file that is used if you decide to distribute your Web Part in a CAB file. (This is discussed later on in more detail.)

To build a Web Part, all you have to do is create a Web Part Project in Visual Studio. NET (see Figure 3), or optionally if you do not have the Web Part Template installed, create an ASP.NET Web Control Library Project. The first thing you'll want to do is modify the Output Path location of your Web Part build to point to the bin directory of your SharePoint site (see Figure 4.). This will cause the compiler to place your Web Part assembly in the folder you set in the Output Path. To do this, right-click your Web Part project, and choose Properties. In the left pane of the resulting dialog, choose Configuration Properties and then Build. Under the Outputs section, choose Output Options and click the ellipsis button to browse ,or type in the location of your virtual server's bin directory. This directory should be located somewhere like local_drive:\Inetpub\wwwroot\bin. Once you've set that, click OK to dismiss the dialog.

Now let's take a look at the code generated for us by the Web Part template (or the code you'll need to add if you chose a Web Control Library project). You will probably want to change the names of source files and class names to something more meaningful or easier for you to remember.

Looking at the code in Listing 1, we can see that three SharePoint namespaces have been referenced:

1. Microsoft.SharePoint
2. Microsoft.SharePoint.Utilities
3. Microsoft.SharePoint.WebPartPages

The last namespace, Microsoft.SharePoint.WebPartPages, contains the WebPart base class, which our Web Part class derives from. Also note that like ASP.NET server controls, your Web Part class overrides a method called RenderWebPart, much like the Render and RenderContents methods you override when deriving from the Control or WebControl classes, respectively. This method accepts an HtmlTextWriter class, also similar to server controls. Furthermore, since Web Parts are part of the same server control infrastructure as ASP.NET server controls, they follow the same lifecycle execution process.