Hi everybody,
At Negotium we’re building multiple SharePoint products (www.oceanik.com www.theattributesolution.com …)
We’ve recently had a complex issue. Let’s say these two products have a common dependency (newtonsoft.json in our case). Now let’s say both products are installed on a single farm and that for some reason you have to uninstall one of them.
When SharePoint will retract the wsp, it will retract all dll’s that were included within it. Including the common dependency the other product still needs. That is going to break the other product.
A good SharePoint administrator will understand that promptly and issue a install-spsolution <nameofthesolution> -gacdeployment –Local –Force on each impacted server.
However not all customers are lucky enough to have properly trained SharePoint administrators. So here is the question we had: how to build my solution resilient enough to repair itself when things like this happen?
After a lot of thinking it appears that SharePoint doesn’t have a full coupling module (in fact the problem comes from .Net and how Windows is built in general).
Some experienced SharePoint developers will say that we have ActivationDependency for solutions. Indeed, but that is only useful when deploying, nothing prevents an administrator from retracting a solution that other solutions depend on.
Others will say that we can kind of patch that adding features dependency on because these one check for any dependent feature when deactivating. But features are not meant for that, they are meant for provisioning elements, moreover nothing prevents an administrator from retracting a solution containing features still activated (but don’t do that, it’s really bad).
The only technical solution to solve this issue (and I took time to chat with the SharePoint product team on that matter) is to build a timerjob with no dependency that will check if our dependencies are here and if missing redeploy the solutions.
Once again, if you can build apps instead of full trust solutions it is far better and you won’t have that kind of issues ;-)
PS: I’d like to thank my team for the time they spent thinking about that matter, namely Benoit, Pascal, Yann, Sébastien, Jeff and Jordan