Question

I currently support a SharePoint “solution”, when I say “solution” I mean a collection of features (like web parts, list definitions and so on) packaged for deployment as a .wsp file. This approach is called the developers approach and currently since we give out this .wsp in the form of an MSI, the upgrade process requires the users retract the entire solution and redeploy.

Before I go recreating the wheel with coming up with new ways of upgrading, I wanted to ask SO SharePoint experts for suggestions on how we can mitigate the cumbersome process of retracting a solutions and redeploying for updates/patches while keeping the sharepoint solution store up to date with the latest dlls.

Initial ideas:

• (1) Create a powershell script that automates as many steps as possible, such as retracting the old solution, redeploying the new solution, copying/updating configuration files. Basically redeploying the solution. (Currently used method)
• (2) Have any new patch deployed as a new feature.
• (3) Your ideas/methods here.

Answer 1

I actually do not use .msi installers for deploying SharePoint solutions, largely because I feel like retracting, upgrading, and redeploying solutions is a tad more invasive than necessary for a simple update.

The stsadm SharePoint administration tool supports upgrading a SharePoint solution in-place. The appeal of using stsadm -o upgradesolution is that you can avoid retracting, updating, and redeploying code.

On the other hand, the appeal of .msi installers is the double-click-that’s-it, no-need-for-a-console installation solution. I try to bridge the gap between the installer experience and the raw stsadm experience by drafting up a PowerShell script to handle all the stsadm commands, etc.

Upgrade-in-place is usually pretty effective; however, if you plan to make changes to event receiver classes, you may find that a full deactivate-retract-upgrade-deploy-activate cycle is necessary.

For example, I have some WebApplication-scoped features that add new WebConfigModification entries to an application’s web.config when the feature is activated. Should I add new web.config entries, the new entries will not appear until the feature is deactivated and reactivated.

A reasonable strategy to avoiding the disadvantage above is to implement new features when a change would otherwise force a deactivate-reactivate cycle.

At any rate, there’s my two cents on solution deployment strategy. I hope it helps.