Upgrading sandboxed solutions

I’ve had a big focus on Application Lifecycle Management and SharePoint 2010 recently, covering things such as the changes in the Solutions and Features frameworks, in particular to allow for ‘upgrading’ Features. I’ve not posted much info here (yet), but delivered the material over two sessions at the recent SharePoint Evolutions conference (you can get my slide decks here) and have a chapter in ‘Real World SharePoint 2010’ (aka the MVP book) on the topic. Today I want to briefly cover some info which I didn’t manage to talk about at the conference – specifically ALM and the sandbox. Just like farm solutions, most sandboxed solutions will most likely evolve over the course of their lifetime, with new functionality added and existing functionality refined - changes will be made to both code and artifacts (e.g. content types, list definitions etc.). Vendors will release new versions of their products, and clients will demand enhancements to other solutions they use which are delivered as sandboxed solutions. Importantly, the process for implementing such changes to existing apps is different between farm and sandboxed solutions – this post explores these differences.

Sidenote: the best starting point for this info is having an understanding of SP2010 ALM concepts such as Feature upgrade, better support for assembly versioning etc. - my slide decks linked earlier cover these, but I’ll try to provide some background with each point.

Difference 1 – upgrading Solution packages

Most devs and admins are familiar with upgrading WSPs using STSADM –o upgradesolution or the ‘retract/dedeploy’ cycle. In SharePoint 2010 much stays the same here aside from the addition of PowerShell commands such as Update-SPSolution. The key difference when upgrading sandboxed solutions is that a new filename for the WSP must be provided each time it is upgraded – the solution ID is then used internally to tie things together. I’m assuming this is because all versions of a sandboxed solution are stored in the Solution Gallery (unlike farm solutions, which only store the latest version once deployment/upgrade is complete) and of course, the Solution Gallery is fundamentally a SharePoint list – which, like any other, doesn’t allow multiple items with the same title. 

No doubt Microsoft could have chosen other options such as using list item versioning or making use of separate fields for name and title, but clearly these approaches were not preferred, so renaming WSPs it is. The logical approach will probably be to add version numbers into WSP filenames for sandboxed solutions.

Difference 2 – Feature upgrade and QueryFeatures()

The Feature upgrade framework is often a great way to make changes to existing SP2010 sites – in a nutshell, it is typically used in conjunction with the new QueryFeatures() method in the API, which helps you find Feature instances at different scopes which need upgrading. A Feature instance needs upgrading when the corresponding Feature.xml file in the SharePoint root has an incremented version number (e.g. 2.0.0.0) but SPFeature.Upgrade() has not yet been called for that instance. What happens is that you run QueryFeatures() on the appropriate object (e.g. SPSite to find Site or Web-scoped Feature instances), and then call SPFeature.Upgrade() for all items returned, assuming you wanted to upgrade the Feature everywhere. As an example, if you had a site collection with 50 webs and called SPSite.QueryFeatures(SPFeatureScope.Site, true), you would then get a collection of 50 Feature instances at Web scope and call SPFeature.Upgrade() on each one. Alternatively, you might choose to only upgrade selected webs – e.g. when only certain web should receive the updated functionality.

The key difference in the sandbox is that it is not possible to upgrade Feature instances selectively – upgrading the WSP has the effect of calling SPFeature.Upgrade() automatically for all instances. This means there is perhaps less flexibility in this area which could be important in some scenarios.

Difference 3 – issues with assembly versioning in the sandbox

A key improvement in ALM in SharePoint 2010 is increased support for versioning assemblies. WSP packages can now add BindingRedirect elements to web.config, meaning a reference to a 1.0.0.0 assembly can be redirected to (e.g.) 2.0.0.0. In some cases this works equally well in sandboxed and farm solutions, but my testing shows issues with sandboxed assemblies which contain web parts or other controls. Aside from the main issue, there is currently a minor gotcha with both sandboxed and farm solutions and SafeControl entries - the WSP deployment removes the 1.0.0.0 entry, and a 2.0.0.0 SafeControl entry alone isn’t sufficient so a “type not registered as safe” error occurs. However, note this can be mitigated by manually editing the solution manifest to add a 1.0.0.0 entry which will be merged with the automatically-generated entry for 2.0.0.0. Something seemingly more serious is that when versioning assemblies with web parts in the sandbox, even performing this mitigation step to ensure all BindingRedirect and SafeControl entries are correct results in a broken web part (error “Unhandled exception was thrown by the sandboxed code wrapper's Execute method in the partial trust app domain: An unexpected error has occurred”).

Since many web part vendors are expected to use the sandbox (in addition to the rest of us), this would mean that many are unable to leverage the versioning and release management improvements in the sandbox (for web parts at least). Other strategies such as using the FileAssemblyVersion instead for versioning may be necessary (doesn’t affect binding/SafeControls). Some folks in the Product Group are looping me in with the team who implemented versioning in the sandbox, so I’ll hopefully find out more and update this post. Right now I’m hoping there was a flaw in my (many) tests - if not, I’m hoping it’s something we might see fixed fairly soon. I’ll keep you posted.