Monday, November 14, 2011

How to update the assembly in sandboxed solutions

Sometimes we need to make changes to the assembly in a deployed SharePoint 2010 sandboxed solution. Perhaps we need to add something in an event receiver. Or perhaps we added a bug fix (not relevant - the code always works). Or some custom webpart needs to do something else than what it is doing right now.

The only problem is that the solution is deployed in a production environment. We can't just delete and recreate the site, then add the updated solution package, and then tell the users to start all over. So what do we do?

Not to worry: This is a piece of cake - and a small piece at that.

Why cant we just swap the solution package for the updated version?

You cannot just remove the original solution package and then deploy the updated package on the site instead. When you deactivate a package you also remove the feature definitions. When you then activate the updated solution the site collection features are automatically activated. This may cause conflicts with already-created content. Also, you might need to activate some web-scoped features (because of some feature dependencies) that could cause even worse conflicts:

  • Your feature could make configuration changes to the site
  • ... or add content ...
  • ... or interfer with changes made by the administrator ...
  • ... or (you get the picture).

So what do we do instead?

Instead of deactivating, deleting, uploading and activating, you just need to upgrade the solution package. For a 'I only changed the code' upgrade this is really simple:

  1. Make the code changes in your project. Don't change the assembly version - this will lead to problems with particularly web part references.
  2. Build the solution and create the WSP file. Don't change the solution ID - this must be the same as in the original solution for SharePoint to be able to match the old and the new solution.
  3. Rename the WSP file. A good idea would be to include the version in the file name. Minor versions (X.Y) could designate code-only changes, while major versions (X.0) could designate schema changes, added functionality etc..
  4. Upload the renamed WSP file. Instead of a 'Activate' option you will be presented with a 'Upgrade' option. Use it.

Or the short version: Change the code. Rename the WSP. Upload, and press 'Upgrade'.

If you followed the simple steps above (the last two being the crucial ones) then the only effect is that you have swapped the original assembly for your updated assembly. No other changes were made.

Of course if you need to make further changes, such as adding fields, new lists etc., then you have do dive into the new feature versioning features (eh... functionality). The UpgradeActions Element is what you need to look at then.

1 comment: