• Provisioning custom services for SharePoint

    This article is targeting SharePoint full trust developers who have (will) developed a custom service (SPService) for SharePoint.

    Indeed, if you are building a product for SharePoint like we’re doing at Negotium ( ) you probably built a custom service application within your solution.

    If that’s the case your custom service application probably relies on a dedicated custom SharePoint service to run its code (it can be a service within IIS or a windows service).

    Then comes a moment (feature activation, installation…) where you want to provision the service (at least for one of the machines).

    If you call MyCustomSPServiceInstance.Provision() on the local server, no problem. But if you do the same for a remote server, you get a weird exception.

    This is because the service instance doesn’t “want” to provision itself from a distant server by default.

    If you take the time to think about it, it kind of makes sense, to startup a service you need to be local administrator and have a privileged execution context on the machine. This is not the case when the code executes remotely.

    Instead of calling the provision method from the remote server, it’s better to start a timerjob to do it on the local machine. And you don’t even need to develop it, it already exists!

    You only have to instantiate SPServiceInstanceJobDefinition give the spserviceinstance in parameter and a Boolean to provision or un-provision it.

    Then just give it a schedule (one time) and update it.

    This should save you some investigation time on that matter as it’s not very well documented on MSDN.

    I’d like to thank Jordan from my team who spent most of the time investigating this issue and who allowed me to publish this post.

    • 27/7/2015
  • Shared dependencies resolution and SharePoint full trust development

    Hi everybody,

    At Negotium we’re building multiple SharePoint products ( …)

    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.

    You’ll find an example here.

    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

    • 18/7/2015