The BinarySerializedWebPart is a new feature element introduced in SharePoint 2010 and … its purpose is to be used primarily internally by the SharePoint save-site-as-template functionality. The element can appear not more than 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 classification feature (its machinate.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 any make a custom list classification (if you already have one – you have to extend it) or to use code to make the necessary list view machinate 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 superfluous 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 classification (limited to the predefined ones in the list template’s machinate.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 make 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 vital 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 illogical view customizations perfectly declaratively with standard feature element syntax. You can check that when you open the “wsp” file and extract the feature files from it by a standard archiving program that can handle CAB files (“wsp” packages are really CAB files). In the Modules feature of the “wsp” package (there is one per site template package) you will see a View classification that will look something like:

OK … so this is the fully declarative provisioning of the modified XLV web part but as you see what you have is really 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, exchange the provisioned XLV view and then export the whole containing site as a template again. Obviously this deal with is excellent for the “saving as site template and site replication based on a site template” functionality but not that excellent for making and maintaining manual view provisioning features. So again possibly the two previously mentioned approaches that were used for SharePoint 2007 before to get the XLV views configured correctly still can be considered as excellent 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 by 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.

Check it out:Stefan Stanev’s SharePoint blog