Browse DevX
Sign up for e-mail newsletters from DevX


Developing Web Parts for SharePoint Portal Server 2003 in .NET : Page 2

This article provides a step-by-step introduction to developing Web Parts using Visual Studio .NET by showing you how to build both simple and complex Web Part components. Along the way, you'll see how to debug Web Parts both locally and remotely—and learn a few tricks and tips.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Creating a Simple Web Part in Visual Studio .NET
Installing the Web Part template adds a new template to the New Project dialog, Templates area (see Figure 5).

Figure 5: To create a new Web Part using the Web Part template in Visual Studio, select the Web Part Library template, and then enter a name and location for the project.

To begin a new Web Part Project, select the Web Part Library from the Templates panel. Like a normal .NET application, provide a name and a location for the application. Then click OK.

By default, VS .NET creates the application will be created with three files: WebPart1.cs, WebPart1.dwp and Manifest.xml files as shown in Figure 6.

Figure 6: Here's how the Solution Explorer in Visual Studio .NET looks after you create a new Web Part project.

The Web Part Class File
The WebPart1.cs is the default name provided by VS .NET for the Web Part Class. You will write code against this file to develop a Web Part. The biggest difference between creating a Web Part and an ASP.NET Web Form is that there's no design view and no graphical tools available for Web Part projects—in other words, there's no way to drag and drop Server or HTML controls from the Toolbox.

The .dwp file
One of the new files added when you create a new Web Part project is WebPart1.dwp, an XML file that holds the reference to the assembly and class used to create it. In previous versions of Web Part technology, the .dwp file contained the code to implement the logic of Web Part. But in the current version, you implement Web Part logic in compiled.NET class files as part of managed assemblies, and the .dwp file contains the name of the assembly and class for each Web Part.

By default, the file contains Title, Description, Assembly and TypeName elements as shown in Figure 7. VS .NET uses the Title and Description properties to identify the Web Part when you add it to the SharePoint web page. You can specify the name of the Web Part in the Title element and a short description about the Web Part in the Description element. The description information displays as a tool tip.

Figure 7: This simple .dwp file image shows the overall XML structure for dwp files.

You specify the class name of the Web Part in the TypeName element. For example, the file in Figure 7 shows that MyWebPart1 is the namespace and WebPart1 is the class name, as exemplified in the following code fragment:

namespace MyWebPart1 { /// <summary> /// Summary description for WebPart1. /// </summary> [DefaultProperty("Text"),ToolboxData( "<{0}:WebPart1 runat=server></{0}:WebPart1>"),XmlRoot( Namespace="MyWebPart1")] public class WebPart1 : Microsoft.SharePoint.WebPartPages.WebPart { // more code here

TIP: If you change the namespace or class name after creating the project, you will also need to update the same information in the .dwp file. You can confirm the name of the assembly by looking at the Property dialog for the application (see Figure 8).

Figure 8: You can confirm the name of the project assembly by retrieving the Assembly Name from the project's Property Pages dialog.

The Manifest.xml file
VS .NET uses the Manifest.xml to populate CAB files when deploying the Web Part to a different location, such as from your development machine to a test or production environment.

Setting the Output Path for Your Web Part Application
It's important to remember that you should set the Output Path property of the Web Part application to the bin folder of your SharePoint Portal site. If you're developing in a local environment, click on the Output Path field in the project's Property dialog and use the browse button to select the path. Typically, the output path will be


TIP: You can confirm this by opening the web.config file of the selected directory (Ex: wwwroot) and verify that it contains the SharePoint information.

If you are developing against a remote machine, you should set the output path to the remote location's bin directory as shown in Figure 9.

Figure 9: When developing against a remote server, the output path should point to the remote machine.

Server_Name is the name of the remote server on which SharePoint Portal Server is running.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date