More fun with deploying Document Sets via XML

Thu, Sep 15, 2011 4-minute read

To finish a set of posts about the fun I’ve had in deploying document sets as XML content types, here’s a fun little bug vagary I encountered. In the video walkthrough, there’s a section on deploying the custom WelcomePage to your site, and provisioning some WebParts automatically to that page.

You achieve this in the Elements.xml file of your WelcomePage module by including some > sections. Within those tags, you enter the definition of the webpart, and you can reuse the built-in webparts.

(Hint: to get at the required definition for built-in SP webparts, find the webpart in the Webparts Gallery in Site Settings, save a copy of the file to your hard drive (as a .dwp file) and then open that file in Visual Studio. You get the required info. Neat.)

You can then deploy your feature, and assuming you’ve covered all the bases your Document Sets, with custom Welcome Page should be deployed. But here’s a problem. Let’s say you make some changes to it, and redeploy the feature. You may experience one of a series of behaviours:

  1. None of your changes are displayed
  2. Your changes are displayed OK
  3. You end up with multiple webparts on your custom Welcome Page.

It’s the third issue I tripped over, and it seems to occur if/when you manually deactivate and reactivate your feature (using the “deploy” feature from VS doesn’t seem to cause this.) It makes some sense - the Elements.xml file says “add these webparts to this page”. Assuming you’ve not added any FeatureDeactivating event receiver to remove the webparts when the feature is deactivated, well, you’ll end up with lots of webparts on the one page.

This being the case, how do you actually go about getting rid of the extra webparts on the page? Retracting the solution doesn’t help. You could completely bin your site content type, site or even site collection. That would probably do it. But it’s a bit drastic. The alternative? Update the database manually. You can decide if this is more drastic than the previous options.

To be clear, you should never, ever, on any account, ever, manually hack the SharePoint content database!

But if you want to do it, here’s how:

Disclaimer: this approach is never recommended and I can’t take any responsibility for any bad things that may result. Sorry.

This is all done on the relevant Content DB. In simple installations, there’ll be only one. But if you have multiple content databases, you should be able to find it from Application Management in Central Admin.

The required code is in the comments below. Login in to SSMS, and assuming you know which ContentDB you’re in, you need to locate your offending page using the query in #1. You can use the results to work out which is the offending docsethomepage based on the dirname and the TimeCreated property. You can do a bit of sanity checking, by also using the results of #2, which will give you the page IDs of pages, ordered by those with the most webparts on them. You can cross-check the IDs in the both resultsets, and satisfy yourself the places you’re going to need to delete. Remember: if you have List(s) that are you using your Content Type, then you will have both a “Site” version of the docsethomepage, and the copy of it for each list. So you may need to delete in multiple places.

Once you’re happy with what you need to delete, it’s now time to commit. (Consider backing up your database before you do this, or at least wrapping things with BEGIN TRANS etc.)

For each id (in the form of a {GUID}) you’ve located on your query on AllDocs, issue the delete command (#3).

You can then refresh your WelcomePage and all webparts should have disappeared. You can then deactivate and activate your feature, and you should now have a working WelcomePage with the correct number of webparts.