SharePoint RetractSolution

Pitfalls of RetractSolution with AllContentUrls

Pitfalls of RetractSolution

This is quick note about some of the pitfalls with using retractsolution with the allcontenturls option in SharePoint. It’s easily done when writing deployment scripts to minimise the hardcoding of specific urls. For example consider the following script:

stsadm -o retractsolution -name mysolution.wsp -allcontenturls -immediate

stsadm -o execadmsvcjobs

stsadm -o deletesolution -name mysolution.wsp

stsadm -o addsolution -filename mysolution.wsp

stsadm -o deploysolution -name mysolution.wsp -url -immediate -allowgacdeployment

stsadm -o execadmsvcjobs

The retract command above removes files matching the solution manifest across all web applications. What’s not immediately obvious is that this happens regardless of whether the solution was ever deployed to the application in the first place. It’s also worth noting that it performs no signature checking against assemblies targeted to the local bin directory prior to their removal.

The result is that any files matching on name will be deleted from those applications even if they were not originally deployed as part of the retracted WSP, and even if they possess a different strong name.

Avoid AllContenturls

So the moral is if you’re juggling multiple applications and multiple WSPs, it pays to be specific and avoid allcontenturls, in particular when targeting the bin.

stsadm -o retractsolution -name mysolution.wsp -url -immediate

On a related note (not specific to the use of allcontenturls) bare in mind that when retracting WSPs containing shared assemblies targeted to the GAC, that SharePoint is not smart enough to leave a copy behind if it’s still referenced by another deployed WSP. It’s therefore advisable to package and deploy these assemblies separately at the global scope. This avoids breakage of one application when upgrading another and in the case where upgradesolution is not an option.