Deploying Sandboxed Solutions

Lately I’ve been working on some Sandboxed solution for Office 365. We all know that they differ on lots of points from Farm Solutions. On the coding end by now we know all the limitations and best practices but how about deployment of these solutions. Some experiences from my end in this post.

Dependencies

Maybe a no-brainer but dependencies between sandboxed solutions can be killing and may result in errors on Solution Activation level. For instance Content Type references in a List Definition with an instance attached to it. The Content Type should be in the same solution as the definition. If there are more Feature in one Solution, make sure to use Activation Dependencies. Again make sure that two different features in two different solutions don’t have any direct dependencies with each other.

Upgrading Shared Resources

When Branding is needed in a Sandboxed solution like MasterPage, PageLayouts, CSS, Images etc. we can use the SharePoint Module SPI for provisioning. However when 1 of these resources is checked out by someone else then the user who deploys and activates the Feature which holds that module, SharePoint will give a Runtime error on Activating the feature. In this case it doesn’t matter if the person deploying the Solution is a sitecollection admin. The settings on the the library for Mandatory Check Out don’t help much either. Even when this is turned off and the file is still checked out, the error occurs.

So it’s important to make SURE that all the files that need to be upgraded are Checked In! And off course this doesn’t apply only to branding files but ALL files that are being provisioned by a Module SPI.