Web Parts are building blocks for creating modular Web sites. Microsoft SharePoint Portal Server 2003 and Windows SharePoint Services utilize Web Parts as the key component to add modular functionality and provide configurable user interfaces. As a developer, you know it's impossible to create a single interface that satisfies all users; however, Web Parts enable end users to assemble and arrange a complete Web page out of premade Web Parts. The Web Parts infrastructure allows data sharing between Web Parts to enable a connected user experience instead of stovepiped functionality. Because they are modular, Web Parts allow developers to encapsulate functionality and reuse across many different sites or, better yet, they can be posted centrally and left for users to use as they see fit.

It should be no surprise that Web Parts utilize the ASP.NET platform. In fact, Web Parts are ASP.NET Server Controls, so if you are familiar with building Server Controls, then you will find it really easy to develop Web Parts. Server Controls are compiled components that perform application logic on the server, then spit out HTML and script to the browser. Before the advent of Web Parts, developers were limited to adding Server Controls to a Web page at design time, but now Web Parts allow users to add them at runtime to configure a unique interface. Another difference from Server Controls is that Web Parts take care of creating the "chrome" around the control, such as the border and title, which users can use to customize the Web Part by setting properties and applying themes.

As with anything, Web Parts are as simple or as complicated as you make them. In this article I will create a simple Web Part and then build on the concepts shown to develop a more complicated one.

Developing a "Hello World" Web Part
To create a new Web Part, first ensure that the Web Part Templates for Visual Studio .NET are installed on the development machine. These provide the code templates used when a new Web Part is created. You do not need the Web Part Templates, or Visual Studio .NET for that matter, to develop Web Parts, but it does save time and make it easier to develop new Web Parts.

After the templates are installed, open a new project in your desired language and select Web Part Template Library. Yes, our first Web Part will be the infamous "Hello World" example, so I will name the project "HelloWorldWebPart" (see Figure 1). The project contains all the files needed to create a Web Part: a manifest, a .dwp file, and a class. The manifest is an XML file used to assist in the installation of the Web Part. The .dwp file is an XML document that captures a snapshot of the property settings for a Web Part and a reference to the assembly and class used to create it. The class is simply the ASP.NET Server Control that makes up the Web Part.

The class or classes that make up the Web Part are responsible for implementing the business logic, display, and user-configurable properties of the Web Part, also known as the Tool Part. All Web Parts have a method called RenderWebPart, which is responsible for sending the HTML and script to the browser. For the "Hello World" example we just want to display some text in the Web Part, so we need to tell RenderWebPart to output only that text. This is all that is needed to display the text within a Web Part, so it is ready to be compiled and deployed.

The RenderWebPart method, shown in Listing 1, is all it takes to create the "Hello World" Web Part.

/// <summary>
/// Render this Web Part to the output parameter specified.
/// </summary>
/// <param name="output"> The HTML writer to write out to </param>
protected override void RenderWebPart(HtmlTextWriter output)
{
//just send "Hello World" in Bold down to browser
output.Write("Hello World");
}

Developing a Functional Web Part
The "Hello World" Web Part is a good start, but useful Web Parts require data access and controls to create a rich user interface. I created another example that grabs data from an external source and displays it in an ASP.NET Datagrid Control. At the time of writing this article my favorite baseball team, the Chicago Cubs, are in first place. As many of you know, this does not happen often, so I wrote a Web Part that imports the standings data and displays it to the user. I am using a flat XML file as the data source, but the process would be the same for XML coming from a Web service that is querying a sports database.

This Standings Web Part uses two controls: a label to display text, and the DataGrid to display the standings in a table. The idea is that when the Web Part loads, it gets the data, places it in the DataGrid, and displays it within the chrome of the Web Part. All controls within a Web Part are instantiated within the CreateChildControls method (see Listing 2). The CreateChildControls method is called automatically after the Web Part is loaded. Just as with the "Hello World" Web Part, the RenderWebPart method will render the controls and send the HTML to the browser. The EnsureChild- Controls method is called prior to rendering the controls to make sure that all the controls are created before rendering them.

The CreateChildControls, GetStandings, and RenderWebPart methods are important pieces of the Web Part. CreateChildControls creates all the controls necessary for the Web Part to function; GetStandings (see Listing 3) retrieves data from an XML document; and RenderWebPart (see Listing 4) outputs the resulting HTML.

Deploying Web Parts
After successfully compiling a Web Part you are left to install it on a server running SharePoint Portal Server or Windows SharePoint Services. There are two ways to deploy a Web Part: either by copying it to a /bin directory below the system_drive:\Inetpub\wwwroot directory, or by installing it in the .NET Global Assembly Cache (GAC). For the purposes of debugging (and for this article), I simply copied the HelloWorldWebPart.dll to the \bin directory. It is recommended that a Web Part not be installed it in the GAC until it has been properly tested and is ready to be deployed.

Allowing users or even members of the Administrators group to have the freedom to import new Web Parts can expose the hosting server to security threats. To reduce this risk, Web Parts must be explicitly designated as safe before they can be activated on the server. A Web Part is made safe by making entries in the SafeControls section of a Web.config file for the virtual server. The Web.config file is typically found at system_drive:\Inetpub\wwwroot\Web.config.

Each SafeControl entry identifies an assembly that contains one or more Web Parts. You can list Web Part classes individually or you can specify that all Web Parts in the assembly are safe. Listing 5 is an example of the SafeControls section of a Web.config file, with tags preceding it that show how it fits into the XML hierarchy of the file.

The SafeControl entry, as well as .NET Code Access Security, prevents unwanted Web Parts from being imported and executed on the server.

Once a control is made safe, it is ready to be imported and placed onto a Web Page. As previously mentioned, .dwp files are XML files that contain metadata about a Web Part. The .dwp file is used to import the Web Part so that it can be placed within a Web Part zone. It should be noted that if any changes are made to the .dwp file after the Web Part is imported, then the Web Part will have to be reimported to incorporate the changes. The following instructions detail how to add a Web Part using a .dwp file.
1.  On the Web Part Page, click Modify My Page or Modify Shared Page.
2.  Point to Add Web Parts, and then click Import.
3.  In the task pane, type the path to the .dwp file (c:\HelloWorld.dwp), or click the Browse button, and then browse to the location of the .dwp file. The selected Web Part appears in the task pane (see Figure 2).
4.  Drag the Web Part to a Web Part zone on the page, or use the "Add to" menu to select a Web Part zone (see Figure 3), and then click Add.

Assuming that there are no errors within the Web Part, and it has been registered as a SafeControl, it will display on the page to which it has been added (see Figure 4).

Debugging Web Parts
Unfortunately, it is rare that code works on the first try, so it is important to be able to quickly debug Web Parts. Debugging Web Parts is similar to debugging Server Controls and can be tricky. Debugging is not as simple as just pressing run in Debug mode in Visual Studio, but once you have done it, it's a snap. The reason why debugging is more difficult is that the ASP.NET worker process executes all the code to create a Web Part, so you must attach the Debugger to that process in order to debug the Web Part being executed.

The first step to debugging is to deploy a Debug version of the Web Part to the server and set a breakpoint where it is needed in the code. Next, follow the instructions below to attach the Debugger to the ASP.NET worker process:
1.  On the Debug menu in Visual Studio .NET, click Processes.
2.  Verify that the "Show system processes" check box is selected.
3.  Verify that the "Show processes in all sessions" check box is selected.
4.  Under Available Processes, click W3wp.exe in the Process list, and then click Attach.
5.  Under "Choose the program types that you want to debug," select Common Language Runtime, and then click OK.
6.  Click Close.

You must browse to the page that the Web Part is installed on so that the worker process can execute the code and hit the set breakpoint. After the breakpoint has been hit, debugging the Web Part is similar to debugging any other application in Visual Studio .NET. When finished, press the stop button in Visual Studio to detach the Debugger from the worker process.

Conclusion
Web Parts are the building blocks for building modular and customized Web sites. They allow users to add Web Part functionality from Web Part galleries to Web Part zones. Web Parts leverage ASP.NET to create a rich, functional user interface. What is more, Web Parts enable developers to encapsulate functionality and reuse it across an organization.