Paul Galvin's (old) SharePoint space [SharePoint

Just another site

SharePoint Features & Solutions Management — Don’t Forget the U in CRUD (or the D for that matter)

We collectively spend a great deal of time thinking about SharePoint solutions — how to create them, which tool to use, what happens when they fail to deploy, timer jobs, scopes, etc.  We spend so much time thinking about the up-front bits that it’s easy to forget that we need to retract them as well.  Retracting solutions is probably more difficult, from a conceptual design perspective, than deploying them.  Deployment is basically a cookbook affair.  Typically, install a feature, maybe have a feature receiver load some data into a list, that sort of thing.  However, retracting is potentially more complex.

A given solution may create artifacts like these:

  • Content Type
  • List Definition
  • Site Definition
  • Data in a list
  • Even receivers
  • InfoPath forms

The list goes on.

While it’s obviously important to design a solution that instantiates those artifacts correctly, it’s just as important to consider the update and delete cases.  If your solution creates a new list and populates that list with data, what happens when the solution is retracted?  In some cases, the list should be deleted.  In other cases, it should be left intact for historical purposes.  Your business requirements will guide you to the right decision.

To help with this, create a matrix that lists each artifact your solution deploys to SharePoint.  List three columns per artifact, one for create, update and delete.  For each case, determine the correct outcome for that operation.

This sort of analysis is obviously best done before the solution is ever deployed to a SharePoint farm.  However, like smoking, it’s never too late to start doing things correctly.  Create that matrix and develop a plan to address the missing update/delete scenarios.  It may be a hard problem to solve, but at least you’ll have put a box around the problem.


Subscribe to my blog.

Follow me on Twitter at

Technorati Tags:

2 responses to “SharePoint Features & Solutions Management — Don’t Forget the U in CRUD (or the D for that matter)

  1. Unknown November 11, 2008 at 4:37 am

    When I started developing solutions and features I did look for a setting somewhere in the definition that defines what happens on deletion or update.  It left me wondering if there should be a few built in behaviours to a WSP – or a swtich on stsadm – that do some of the common tasks you mentioned above such as on deleting a solution – remove everything or leave everything and on updating – remove and replace or simply update the definition and then have the option of doing a custom action in a feature receiver.

  2. Unknown November 22, 2008 at 12:56 pm

    @no nameThat\’s what the Feature Receiver class is for. You write custom code to handle what ever you want within the Object Model in override methods within your custom Feature Reciever. See the MSDN article here.Hope that helps :)@PaulI\’m linking this article in this months SharePoint user group presentation because, as was discussed at this months SPUG, this is really a central issue to creating robust SharePoint features.-john (blog)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: