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 http://www.mywebapplicaton.com -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.
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 http://www.mywebapplicaton.com -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.