This post expands on a small tidbit I mentioned at the end of another post a few days ago.

Web Parts were first introduced in Windows SharePoint Services v2. The concept was so compelling that the model was improved and added to the second generation of ASP.NET: ASP.NET 2.0. This wasn't the only addition to ASP.NET 2.0. Other improvements and enhancements allowed the Windows SharePoint Services team to revamp their underlying architecture that resulted in it being rebuilt on top of ASP.NET 2.0 (previously, WSS v2 had it's own rendering engine).

With these two significant events (Web Parts -> ASP.NET 2.0 & WSS v3 being built on top of ASP.NET 2.0), now ASP.NET 2.0 Web Parts will work within WSS v3 websites. However, that's not the end of the story... not only can you build Web Parts that derive the ASP.NET 2.0 WebPart class (System.Web.UI.WebControls.WebParts.WebPart), but you can also build Web Parts that derive the WSS v3 WebPart class (Microsoft.SharePoint.WebPartPages.WebPart). The WSS v3 WebPart class is actually derived from the ASP.NET 2.0 WebPart class.

"Why do you have two WebPart classes?" According to the Windows SharePoint Services v3 SDK:

The Windows SharePoint Services (version 3) WebPart class has been rebased to inherit from the Microsoft ASP.NET 2.0 WebPart class, providing a compatibility layer to ensure that Web Parts written for Windows SharePoint Services (version 2) work in Windows SharePoint Services V3 without modification. It exists primarily for the purpose of backward compatibility, and secondarily, to provide a small set of features that are not available in the ASP.NET WebPart class.

"So I ~only~ use the WSS v3 WepPart class when I'm upgrading a WSS v2 Web Part derived from the WSS v2 WebPart class? Otherwise, only build Web Parts derived from the ASP.NET 2.0 class?"  No... not exactly. There are four cases when you should use the WSS v3 WebPart class over the ASP.NET 2.0 WebPart class... according to the SDK:

• 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

Now we are left with three different WebPart classes: (1) WSS v2, (2) ASP.NET 2.0, and (3) WSS v3. As you'd expect, none are the same. However, the ASP.NET 2.0 WebPart class was based off the concepts of Web Parts in WSS v2, so there's likely to be quite a few similarities. In addition, the SharePoint team went to significant lengths to make sure WSS v2 WebParts would work in WSS v3, thus many members were added to the WSS v3 class for backwards compatibility. There are also a handful of new members that were added to the WSS v3 WebPart class.

The table below outlines the additional members you'll find in the WSS v3 WebPart class (Microsoft.SharePoint.WebPartPages.WebPart) from the ASP.NET 2.0 equivalent(System.Web.UI.WebControls.WebParts.WebPart [MSDN documentation link here]) and those that have been retained for backwards compatibility with the WSS v2 WebPart class (I've omitted the members inherited from it's derived ASP.NET 2.0 WebPart class and those that were retained from the WSS v2 class (MSDN documentation link here).

Everything listed in the table below is from the WSS v3 Beta SDK. Obviously it is subject to change.

Public Fields
	LimitOneConnection	Specifies that a connectable Web Part can accept no more than one connection to another Web Part.
	UnlimitedConnections	Specifies that a connectable Web Part can accept an unlimited number of connections to another Web Part.
Public Properties
	SerializedAttachedPropertiesShared	Supports the Windows SharePoint Services Web Part connection infrastructure. Not intended to be used directly from your code.
	SerializedAttachedPropertiesUser	Supports the Windows SharePoint Services Web Part connection infrastructure. Not intended to be used directly from your code.
Protected Properties
	CacheType	Determines the type of caching being used by the Web server.
	ClassResourcePath	Gets the base path to Web Part class resources.
	ContainerWidth	Gets the value set by the page author as a hint to the Web Part of how wide to expect the containing Web Part zone to be. Obsolete.
	OverflowAuto	Gets a value indicating whether you can override the default setting for the cascading style sheet (CSS) overflow attribute when rendering the Web Part.
	SaveProperties	Gets or sets whether a Web Part's properties have changed and should be persisted at the end of page rendering.
	SerializeAll	Gets whether a retrieved property value should be serialized for use in the client-side WPSC property collection.
	ServerRelativeClassResourcePath	Gets the server-relative path to Web Part class resources.
	ShouldValidate	Gets a value indicating whether the Web Part infrastructure should perform data validation of Web Part properties before setting them.
	WebPartMenu	Gets or sets the Web Part menu source that is rendered in the frame of the Web Part.
	WorkItemTimeout	Obsolete.
Public Methods
	ShouldSerializeAllowConnect	Returns whether the AllowConnect property has changed from its default value.
	ShouldSerializeAllowEdit	Returns whether the AllowEdit property has changed from its default value.
	ShouldSerializeAllowHide	Returns whether the AllowHide property has changed from its default value.
	ShouldSerializeHelpMode	Returns whether the HelpMode property has changed from its default value.
	ShouldSerializeID	Returns whether the ID property has changed from its default value.
Protected Methods
	RequiresWebPartClientScript