SPOnline: using feature upgrades
Ok so we’re building sandboxed solutions for SharePoint Online, great! Now suppose you’ve got your solution deployed and your customer starts working with it. All is well and of course they’re superpleased with you and start sending you gifts and stuff. But then, one day, you get a call: “hey, could you also add this webpart and that list for us?”. So now it’s time to upgrade your feature and add new stuff in it. But how?
On premise, this process is supported by the feature upgrade framework. Basically, you update the version of your feature (in the features properties) and write some XML in the XML manifest of the feature. You can do stuff like deploying new fields, adding fields to existing contenttypes, or executing your own code. If you’ve got the Visual Studio 2010 Power Tools for SharePoint installed, this is even supported from Visual Studio by setting the projects “Active Deployment Configuration” to “Upgrade”.
Ok, but how about sandboxed solutions? Well the process is similar, but different. Why? I don’t know either, because they made it more difficult for us developers.I’ll point out what to look out for.
- You can’t upload your WSP under the same filename. SharePoint will complain about a file already existing and won’t upload your file, even when you tell it to overwrite existing files.
- If you deactivate and remove your WSP, remember that this will also deactivate all of your features. You probably don’t want to do that, or can’t because your site columns are already in use (for instance).
- If you do want to upgrade, you need to upload your WSP with a new filename. SharePoint will compare the ID of your solution with existing ones and that way it will discover upgrades.
- Now after uploading, the interface will give you an option to upgrade your solution. This is what’s similar to the on premise process; it will upgrade your feature definitions to their new versions and will activate your new code in the user code process.
- One more thing to note is that this whole procedure isn’t supported in Visual Studio. Doing it by hand means manually renaming the file, uploading it, and upgrading the solution. You’ll probably want to script that and use the script as an external tool in Studio. I’m not sure if you can use such a script to also attach the debugger.
So why aren’t they using versioning to upload the file under the same filename? No clue…
Why isn’t this supported in Studio? No clue…
How to automate the testing of these solutions and especially upgrading them? No clue… yet!
I’m going to contact the CKS DEV folks to see if they have any plans for an Upgrade Sandboxed action from studio, that would be sweet.
Leave a Comment