Web Part Infrastructure in SharePoint Foundation
Applies to: SharePoint Foundation 2010
Web Parts are server-side controls that run inside the context of Microsoft SharePoint Foundation site pages. You can use them to customize the user interface (UI) and to edit the content of a site page. SharePoint Foundation includes default Web Parts as well as the ability to build custom Web Parts. There are two supported types of Web Parts in SharePoint Foundation. They are referred to as SharePoint and ASP.NET Web Parts. ASP.NET Web Parts use the System.Web.UI.WebControls.WebParts.WebPart base class while SharePoint Web Parts use the Microsoft.SharePoint.WebPartPages.WebPart base class. Both types are supported but the ASP.NET Web Part is recommended for all new projects.
Object Model for Web Parts
Web Parts in SharePoint Foundation are based on the Microsoft ASP.NET Web Part infrastructure. To create Web Parts for applications that target SharePoint Foundation, you should build custom Web Parts on top of the ASP.NET Web Part infrastructure. However, in a very few cases, you may have to create Web Parts that support SharePoint Foundation features that are not available in the ASP.NET Web Part infrastructure.
ASP.NET Web Parts
The ASP.NET Web Part infrastructure is based on a WebPartManager class that manages the lifetime of Web Part instances at run time.
Each ASP.NET page that uses Web Part controls must contain the following objects in order to support personalization:
Exactly one WebPartManager object that tracks which Web Parts have been added to each particular zone and that stores and retrieves data about how each Web Part has been customized and personalized.
One or more WebPartZone objects, into which Web Parts are placed.
To run SharePoint Foundation Web Parts in an ASP.NET application, you must create an .aspx page that contains exactly one instance of the WebPartManager control and one or more WebPartZone controls. The WebPartManager is responsible for serializing Web Part-related data as well as storing and retrieving it from the database.
The SPWebPartManager and WebPartZone controls manage the serialization of data associated with Web Parts into the appropriate SharePoint Foundation content database. To be able to persist data, your ASP.NET Web Parts must be placed on a page with these two controls.
Because these SharePoint Foundation-specific controls are required on pages that contain Web Parts, you cannot simply copy your ASP.NET page into a SharePoint Foundation site. To move ASP.NET Web Parts from an ASP.NET application to a SharePoint Foundation application, export them from ASP.NET as .webpart files and import them into a SharePoint Foundation site.
SharePoint Web Parts
The SharePoint Foundation Web Part infrastructure uses many of the controls in the ASP.NET Web Part control set, and introduces several of its own controls that inherit from base classes supplied by the ASP.NET Web Parts control set.
For example, site pages for a SharePoint Foundation site do not use the standard ASP.NET WebPartManager class. Instead, they use the SharePoint Foundation-specific SPWebPartManager class that inherits from the ASP.NET WebPartManager.
Note
The default master page that is provided with SharePoint Foundation includes an instance of SPWebPartManager class, so this control is automatically included with all of your SharePoint Foundation content pages.
Similarly, a Web Parts page for a SharePoint Foundation Web site also use a SharePoint Foundation-specific WebPartZone class that inherits from the ASP.NET WebPartZone class.
When to Derive from the SharePoint WebPart Class
In a very few cases, you may have to create Web Parts that support SharePoint Foundation features that are not available in the ASP.NET Web Part infrastructure. In these cases, you can create a class that inherits from the SharePoint WebPart base class. Web Parts such as these are known as SharePoint-based Web Parts and can only be used in SharePoint Foundation sites.
Following is the list of features provided exclusively by the SharePoint WebPart class:
Cross page connections
Connections between Web Parts that are outside of a Web Part zone
Client-side connections (Web Part Page Services Component)
A data caching infrastructure that allows caching to the content database
Another reason you may consider deriving from the WebPart class is related to creating new versions of your Web Parts. If your original Web Part derived from the WebPart class, and you want to upgrade instances of that Web Part to a new version, then the new version of the Web Part should also derive from the SharePoint WebPart class.
See Also
Reference
Microsoft.SharePoint.WebPartPages