Web Part Type IDs have always been something of a mystery for folks. In short, web part type ids are unique guids that represent a web part type. When the web part framework was built for SharePoint v2, our team decided that we needed a way to optimize the load sequence during a render cycle. Out of the effort emerged a component known as web part type ids. They are a way for SharePoint to clearly identify the types of each web part instance that is stored in the database while allowing the SafeMode parser to pre-cache the list of SafeControl types found in the web.config and hence run through the safe/not-safe validation quickly.
For developers, web part types ids are entities that we hardly ever ever need to manage. SharePoint generates the web part types ids based on type and assembly information. However there are 2 phases where web part type ids start to bubble up in importance:
- Upgrade from SharePoint version to version
- Upgrade from Web Part version to version
For the latter, the general guidance that developers need to follow is that it is wiser to never use use binding redirect to upgrade the assembly version of a web part assembly.
For the former, administrators will likely see errors in this space long before a developer is called into to help debug the problem. Administrators will run into the problem as they run through the upgrade process from from v.old to v.next. The problem will show up when explicitly running through upgrade or via the test-spcontentdabase commandlet.
“Webpart class [some-guid] is referenced … but is not installed in the current farm”. The error message is unfortunately not very informative; after all, web part type ids were never meant to be human consumable! Although, this is the primary exposure point, other pre-upgrade tasks and general web part operations may also generate message that include the web part type id.
How are folks supposed to know what the guids represent?
Prior to SharePoint 2010, the answer was always buried somewhere. If you are an old timer with SharePoint, you might remember a tool called the SharePoint Configuration Analyzer. It’s a tool that I wrote somewhere in the beta time frame of v2 to help my former team gather information about the rendering characteristics of a SharePoint deployment as the beta rolled out. The tool would surface the “normal” names alongside the web part type ids.
If you are upgrading to SharePoint 2010, you still need some help. Check out the pdf file WebPartTypeIDs I created this morning that outlines all the web part type ids from SharePoint 2003, SharePoint 2007, and SharePoint 2010. It’s worth calling out a few caveats about the list.
- The SharePoint 2003 list of web parts does not contain the SharePoint Portal Server controls, only the WSS controls. I didn’t feel like installing SPS this morning. :)
- The SharePoint 2003 list does include the optional add-on set of web parts that was called “the pickle” or more officially known as the “Office 2003 Add-in: Web Parts and Components”. This add-on piece was most famously known for early charting controls and the WebCaptureWebPart.
- With the exception of 1 custom web part that was installed on all of test machines and The Pickle parts, this list represents only out of box SharePoint web parts.
How does SharePoint 2010 improve on the experience moving forward?
SharePoint now records the assembly name and type name whenever a web part is associated to a page. The type id is still a critical component of the page rendering process, but the additional information allows the error message to be friendlier and eliminates the need to use an external reference. The message still contains the web part type id, but SharePoint 2010 now reports back the more human readable representation of the type in the form of both the type full name and assembly full name. No more guessing as to what that funky guid represents. Nice!