Developing Custom Web Parts for Windows SharePoint Services 3.0
SharePoint web parts provide support to create both customized and personalized
user interfaces. Customization in this case means that the changes for the web
part are seen by all site users. Individual users can personalize their web
pages further by adding, moving and removing web parts in their view of the web
page. In this case, personalization means that the changes made to the web
parts are only visible to the user who made the change.
When developing custom web parts, you can extend the Windows SharePoint site's
functionality in an easy and powerful way.
Web parts were first introduced in Windows SharePoint Services (WSS) V2.0. In
Windows SharePoint Services 3.0 they are no longer just a SharePoint feature,
because the ASP.NET team adopted the web part concept and rebuilt the entire
web part framework using ASP.NET 2.0.
Because Windows SharePoint Services V3.0 uses .NET Framework 2.0, WSS web parts
can also use the ASP.NET 2.0 web parts control set. When you are creating web
parts for WSS V3.0, you have the option of inheriting from the
System.Web.UI.WebControls.WebParts.WebPart (ASP.NET 2.0 web part) or Windows
SharePoint Services web part class. The Windows SharePoint Services web part
class was part of Windows SharePoint Services V2.0, before the ASP.NET web
parts were introduced, where they supported web part development.
Developers can now easily apply their .NET development experience and use Visual
Studio 2005 to create new ASP.NET 2.0 web parts for Windows SharePoint Services
Windows SharePoint Services (WSS) V3.0 Web Part
The WSS V3.0 web part infrastructure uses many of the ASP.NET 2.0 web part
control sets. The infrastructure also creates its own controls by inheriting
them from the base class provided by the ASP.NET 2.0 web part control set.
There are three controls that make up the core web part infrastructure in WSS
V3.0. They are SPWebPartManager, WebPartZone and WebPart.
WSS V3.0 web pages don't use standard ASP.NET WebPartManager in their pages.
Windows SharePoint Services 3.0 uses the SPWebPartManager
(Microsoft.SharePoint.WebPartPages.SPWebPartManager) that inherits from the
ASP.NET WebPartMnager (System.Web.UI.WebControls.WebParts.WebPartManager)
class. (There is an additional "SP" character in the SharePoint
WebPartManager). The reason for having different names in ASP.NET and
SharePoint is that the WebPartManager is a new concept introduced by ASP.NET
web part controls. SPWebPartManager acts as the central hub, managing all the
web parts and zones. In WSS 2.0 site pages, many of the tasks handled by
SPWebPartManager were done by web part pages (adding, removing, moving web
parts to zones, etc), web part zones, and the web part itself.
By default, the SPWebPartManager object is added to the master page of the WSS
V3.0 pages. The SPWebPartManager is included in every content page by default
because the master page contains an instance of SPWebPartManager. Because it's
already set up for you, you can add a web part to a WSS V3.0 page without
having to worry about the SPWebPartManager object.
All web parts now belong to the SPWebPartManager object in a page. This means a
reference to the Parent property of the web part class will return
SPWebPartManager object rather than the WebPartZone object in WSS V2.
The WebPartZone provides a way to organize the web parts in to regions in the
web page. WSS V3.0 uses its own WebPartZone
(Microsoft.SharePoint.WebPartPages.WebPartZone) that is inherited from the
standard ASP.NET 2.0 WebPartZone
(System.Web.UI.WebControls.WebPartsWebPartZone) class. The same name is used in
both ASP.NET web part control and WSS 3.0 web part controls. This is because
the WebPartZone concept was introduced in WSS V2.0 and having the same name
supports backward compatibility.
The WebPartZones control the appearance of the web part controls. Each zone is
rendered as an HTML table in the browser. A page can contain more than one
WebPartZone control. There are two types of WebPartZones:
WebPartZoneBase - Contains all the web parts in the web part page.
ToolZone - A specialized zone that enables users to change the properties of
the web parts within the selected zone.
The SPWebPartManager and WebPartZone controls manage the serialization of the
web part's data with the Windows SharePoint Services content database. ASP.NET
web parts must be placed on a page with these two controls, if you want the
data to persist and to support personalization.
ASP.NET 2.0 web parts will run on both ASP.NET web pages and WSS site pages. You
can build a web part for WSS V3.0 site that drives from:
When you create web parts for WSS 3.0 sites, Microsoft recommends using ASP.NET
2.0 web parts rather than SharePoint web parts. An exception to this is when
you require additional functionalities that are not part of ASP.NET 2.0 web
part control set, but which are provided from SharePoint web parts. I will be
looking at those special scenarios later in this article.
Differences between ASP.NET 2.0/WSS V3 and WSS V2
ASP.NET 2.0/WSS V3
||New concept. Handles adding, moving, removing, personalizing,
importing, exporting and managing connections between web parts.
||Did not exist. The web part, web part zones and the pages look
after the work of SPWebPartManager.
||Includes header, footer, border and CSS style sheet support to
provide a common user interface for all web parts.
||Was not easy to control the user interface of all the web parts
within a web part zone.
||Supports ASP.NET 2.0 and WSS V3
||WSS V2 only
|Web Part Parent property
||The web parts belong to SPWebPartManager object in the page. The
Parent property of a web part will return SPWebPartManager object.
||Web Part belongs to web part zone object. The Parent property of a
web part will return the WebPartZone object.
|Web Part Connections
||Connections are referenced, based, and managed by SPWebPartManager
ASP.NET 2.0 supports unlimited provider connections, but is limited to a single
|Based on event handlers and web parts that handle the connections
Supports unlimited provider and consumer connections.
Importing and Exporting Web Parts
You won't be able to simply copy your ASP.NET 2.0 web parts to Windows
SharePoint Services V3.0 pages. To use your ASP.NET web parts in the SharePoint
environment, you must first export your ASP.NET web parts and then import them
to the SharePoint pages. (The Building ASP.NET 2.0 Web Part for Windows
SharePoint Services 3.0 and Microsoft SharePoint Server 2007 article covers
When to Use Windows SharePoint Services Web Part Class
There are a few cases when you will have to use Windows SharePoint Services web
parts instead of ASP.NET web parts. Windows SharePoint Services web parts
support additional Windows SharePoint Services features that are not supported
through an ASP.NET web part. Following is a list of features that are only
supported through Windows SharePoint Services web parts:
Connections between web parts that are outside of a Web Part zone
Cross page connections
A data caching infrastructure that allows caching to the content database
Client-side connections (Web Part Page Services Component)
Another reason for using Windows SharePoint Services web parts is when you want
to upgrade your Windows SharePoint Services V2.0 web parts to the V3.0
environment. The new version of the web part should be driven from the
SharePoint web part class. SharePoint web parts can only be hosted in Windows
SharePoint Services site pages.