Saturday, June 19, 2010

SharePoint 2010 – BinarySerializedWebPart element and XsltListViewWebPart provisioning

The BinarySerializedWebPart is a new feature element introduced in SharePoint 2010 and … its purpose is to be used mainly internally by the SharePoint save-site-as-template functionality. The element can appear below a View element in a Module feature that provisions web part pages with XLV web parts.

A known issue in SharePoint 2007 was that when you use the View element in an ONET.XML file or a Module feature element to add a List View web part (LVWP) to a page you can only specify one of the existing Views defined in the list definition feature (its schema.xml) of the target list instance – this is achieved with the BaseViewID attribute of the View element. So if you need a slightly modified View for a LVWP you have to either create a custom list definition (if you already have one – you have to extend it) or to use code to make the necessary list view schema changes – in the case of LVWP and XLV web parts there is always a hidden SPView associated with the web part (you can check a previous posting of mine treating this topic in detail - ListViewWebPart & SPView – two sides of the same coin). The problem with both approaches is that they require some extra effort for this relatively simple provisioning task.

And how about the new SharePoint 2010 – well, the View element works pretty much the same in the sense that if you use the View element alone you have again only the BaseViewID attribute to specify a View definition (limited to the predefined ones in the list template’s schema.xml). And here comes the new BinarySerializedWebPart element – you can see it working when you, say, have a normal team site and add a XLV web part to its home page and then modify the View of the web part adding for instance several more view fields and changing the filter fields. Then you can use the “save site as template” command from the “site settings” page of the site and after you have the site template, you can create a new site based on it, where you will see that you have the exactly same XLV web part with the exact same customizations in place (this didn’t work in the SharePoint 2010 beta but is fixed in the RTM version). The last exercise may sound like a nonsense since we had this functionality in SharePoint 2007 too, but the important difference here is that site templates in SharePoint 2007 were saved as “stp” files while in SharePoint 2010 site templates are saved as standard “wsp” solution packages comprising standard SharePoint features. And this means that in SharePoint 2010 it is possible to provision XLV web parts with arbitrary view customizations totally declaratively with standard feature element syntax. You can check that when you open the “wsp” file and extract the feature files from it using a standard archiving program that can handle CAB files (“wsp” packages are actually CAB files). In the Modules feature of the “wsp” package (there is one per site template package) you will see a View definition that will look something like:

<View List="Shared Documents" DisplayName="" Url="" DefaultView="FALSE" BaseViewID="1" Type="HTML" WebPartOrder="0" WebPartZoneID="Left" ContentTypeID="0x" ID="g_ba709f71_6af5_4e3c_a8b1_01be2d3f95e8" Hidden="TRUE">



      <GUID Id="5ba54c0a_6d0a_4667_8889_27fcfc904193" ListUrl="Lists/Announcements" />

      <GUID Id="2d9a46bd_f3e1_4cc6_9630_5763fc589317" ListUrl="Lists/Links" />

      <GUID Id="76f78fed_a0f9_498b_b2e4_8aa9ff2b4a2f" ListUrl="Shared Documents" />

      <GUID Id="ea419abd_36c7_4a42_94e3_b661ef52af44" ListUrl="Lists/Calendar" />


    <WebPart ID="{ba709f71-6af5-4e3c-a8b1-01be2d3f95e8}" WebPartIdProperty="" List="{$ListId:Shared Documents;}" Type="1" Flags="8388621" DisplayName="" Version="1" Url="/sites/1/default.aspx" WebPartOrder="0" WebPartZoneID="Left" IsIncluded="True" FrameState="0" WPTypeId="{874f5460-71f9-fecc-e894-e7e858d9713e}" SolutionId="{00000000-0000-0000-0000-000000000000}" Assembly="" Class="" Src="" AllUsers="B6Dt/i4AAAABAAAAAAAAAAEAAAAvX2xheW91dHMvaW1hZ2VzL2l0ZGwucG5nAP8BFCsAEAICAgMCAgEEAAIBAgkBAAACCAKCAQUZL19sYXlvdXRzL2ltYWdlcy9pdGRsLnBuZwKVAQUmezc2Rjc4RkVELUEwRjktNDk4Qi1CMkU0LThBQTlGRjJCNEEyRn0FBkxpc3RJZCgpWFN5c3RlbS5HdWlkLCBtc2NvcmxpYiwgVmVyc2lvbj0yLjAuMC4wLCBDdWx0dXJlPW5ldXRyYWwsIFB1YmxpY0tleVRva2VuPWI3N2E1YzU2MTkzNGUwODkkNzZmNzhmZWQtYTBmOS00OThiLWIyZTQtOGFhOWZmMmI0YTJmBRVJbml0aWFsQXN5bmNEYXRhRmV0Y2ho" View="qKkwMQwAAAByAQAAeJxtkNsKwjAMhl+l9AUmeNsNPA0GHuf0vtp0BNtFYkX29tZ5QNiuQvL9P/kTdUR45AjO3DLV1RKsWGsPqZzTuThTI5MeWWJzydFBE7sBvCKDFsEMoIXBQDwAZgw6vC3Jf6bdHbjN1IYN8LTt2Yp55/jh5KOf1DVDrQNScxNH7e5Ru7H2JS7psUSPQWx1DSaVVXlYyGw8UsmXZGpFp3ieeJcigO/mqRzLz2yP/urgF7T/korInTSLqr3G1TkDWGIfyRMdinz/" />



OK … so this is the fully declarative provisioning of the customized XLV web part but as you see what you have is actually the binary serialized property data of the web part which cannot in any way be manually modified in case you need some further adjustments. If you want to make some changes you need to have the feature deployed, change the provisioned XLV view and then export the whole containing site as a template again. Obviously this approach is good for the “saving as site template and site replication based on a site template” functionality but not that good for creating and maintaining manual view provisioning features. So again maybe the two previously mentioned approaches that were used for SharePoint 2007 before to get the XLV views configured correctly still can be considered as good alternatives.

And lastly one small detail – the BinarySerializedWebPart element will appear in the “save as site template” generated “wsp” solution package only for XLV web parts whose views were modified and are different from the standard predefined list template base views. This also holds for changes made to the XLV web part’s XSLT that you can do using the SharePoint 2010 designer. For XLV web parts that were not modified after they were added to a page, the “save as site template” command will generate a “standard” View element that will contain a normal CDATA section containing a WebPart element with the XML of all properties of the web part – i.e. the standard web part feature provisioning format that we use in web part features.


  1. Hi,

    You can read more about the BinarySerializedWebPart and how to decode that to a web part instance on my blog:


  2. This comment has been removed by the author.

  3. Thanks for the write up, you've really given me a lot of insight into the code base I've just received from another team. What are some of the drawbacks with developing web parts this way?

    Thanks again!