Web Parts Overview

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Web Parts are server-side controls that run inside the context of special pages (that is, Web Part Pages) within an ASP.NET application or a Windows SharePoint Services site. They are the "building blocks" of pages in Windows SharePoint Services. Windows SharePoint Services includes built-in Web Parts that you can use as soon as you have installed the product. In addition, you can build your own Web Parts and deploy them to the server.

Because of the popularity of Web Parts in Windows SharePoint Services 2.0, support for a new Web Part infrastructure for ASP.NET 2.0 was added to Windows SharePoint Services 3.0. The new Web Part infrastructure is similar yet distinct from the Web Part infrastructure in Windows SharePoint Services 2.0.

Types of Web Parts in Windows SharePoint Services 3.0

There are now two different Web Part styles in Windows SharePoint Services 3.0. Both are supported, but the ASP.NET 2.0 Web Part is the recommended style for your new projects.

• SharePoint-based Web Parts — The older style Web Parts have a dependency on Microsoft.SharePoint.dll and must inherit from the WebPart base class in the Microsoft.SharePoint.WebPartPages namespace. These Web Parts can only be used in SharePoint Web sites. Yet in Windows SharePoint Services 3.0, the Microsoft.SharePoint.dll was changed so that Web Parts written in the older style would be compatible with the Windows SharePoint Services 3.0 runtime.

  Note

  For more information about when to derive from the Windows SharePoint Services WebPart Class, see the section "When to Derive from the Windows SharePoint Services WebPart Class" in the Web Part Infrastructure in Windows SharePoint Services topic.

• ASP.NET 2.0 Web Parts — These Web Parts are built on top of the ASP.NET Web Part infrastructure. The newer ASP.NET-style Web Parts have a dependency on System.Web.dll and must inherit from a different base class named WebPart in the System.Web.UI.WebControls.WebParts namespace. These Web Parts can be used in Windows SharePoint Services applications whether Windows SharePoint Services is involved or not, making them highly reusable.

  Note

  If you are creating your Web Part specifically for a SharePoint site, and it will consume the Windows SharePoint Services object model, you can derive from the ASP.NET System.Web.UI.WebControls.WebParts.WebPart base class and add a reference to the SharePoint object model in your project.

More about ASP.NET 2.0 Web Parts

The Windows SharePoint Services 3.0 Web Part infrastructure is built on top of a control named SPWebPartManager that is derived from the ASP.NET 2.0 WebPartManager control. The SPWebPartManager control overrides the standard behavior of the WebPartManager control to persist Web Part data inside the Windows SharePoint Servicescontent database instead of in the ASP.NET services database. In most cases, you don not have to worry about dealing directly with the SPWebPartManager control because the one and only required instance is already defined in default.master. When you create a content page that links to default.master, the SPWebPartManager control is already there.

When you create a Web Part Page for a standard ASP.NET 2.0 application, you need to add logic that interacts with the WebPartManager control to manage the Web Part display mode, and generally you also need to explicitly add editor parts and catalog parts to the page along with the HTML layout to accommodate them. Fortunately, you do not have to perform these changes when creating content pages for a Windows SharePoint Services 3.0 site. Instead, you inherit from the WebPartPage class that is defined inside the Microsoft.SharePoint.WebPartPages namespace and it does all the work behind the scenes for you.

For more information about creating ASP.NET Web Parts, see ASP.NET AJAX in Windows SharePoint Services and Web Parts Control Set Overview in the ASP.NET documentation.

Custom Web Parts

Custom Web Parts provide developers with a method to create user interface elements that support both customization and personalization. A site owner or a site member with the appropriate permissions can customize Web Part Pages by using a browser or by using Microsoft Office SharePoint Designer 2007 to add, reconfigure, or remove a Web Part.

In Windows SharePoint Services 2.0, developers could extend SharePoint sites by creating custom Web Parts, to add the extra dimensions of user customization and personalization. The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them. Developing custom Web Parts provides an easy and powerful way to extend Windows SharePoint Services sites.

Because the Windows SharePoint Services Web Part infrastructure is now built on top of the ASP.NET 2.0 Web Parts control set, you can reuse your knowledge of ASP.NET programming to create quick and robust custom Web Parts.

Following are some ways in which you can benefit from and use custom Web Parts:

• Creating custom properties you can display and modify in the user interface.

• Improving performance and scalability. A compiled custom Web Part runs faster than a script.

• Implementing proprietary code without disclosing the source code.

• Securing and controlling access to content within the Web Part. Built-in Web Parts allow any users with appropriate permissions to change content and alter Web Part functionality. With a custom Web Part, you can determine the content or properties to display to users, regardless of their permissions.

• Making your Web Part connectable, allowing Web Parts to provide or access data from other connectable Web Parts.

• Interacting with the object models that are exposed in Windows SharePoint Services. For example, you can create a custom Web Part to save documents to a Windows SharePoint Services document library.

• Controlling the cache for the Web Part by using built-in cache tools. For example, you can use these tools to specify when to read, write, or invalidate the Web Part cache.

• Benefiting from a rich development environment with debugging features that are provided by tools such as Microsoft Visual Studio 2005.

• Creating a base class for other Web Parts to extend. For example, to create a collection of Web Parts with similar features and functionality, create a custom base class from which multiple Web Parts can inherit. This reduces the overall cost of developing and testing subsequent Web Parts.

• Controlling the implementation of the Web Part. For example, you can write a custom server-side Web Part that connects to a back-end database, or you can create a Web Part that is compatible with a broader range of Web browsers.

See Also

Tasks

How to: Export an ASP.NET Web Part and Import it to a Windows SharePoint Services Site

Reference

Microsoft.SharePoint.WebPartPages

Concepts

Web Part Infrastructure in Windows SharePoint Services

Developing Web Parts in Windows SharePoint Services

Other Resources

Discover Significant Developer Improvements In SharePoint Services