Cet article s’adresse aux développeurs SharePoint full trust qui ont (vont) développé un service (SPService) pour SharePoint.
En effet dans le cadre où vous bâtissez un produit pour SharePoint comme on le fait chez Negotium (www.oceanik.com www.theattributesolution.com ) vous avez probablement intégré une application de service dans votre solution.
Si c’est le cas votre application de service a probablement un service SharePoint dédié pour exécuter son code (que ce soit un service porté par IIS ou un service windows).
Dans ce cas de figure il arrive à un moment (activation de la fonctionnalité, installation…) où vous voudrez provisionner le service (au moins sur une des machines)
Si vous appelez MonSPServiceInstance.Provision() sur le serveur courant, aucun problème. Par contre dès que vous commencez à vouloir le provisionner l’instance de service sur un serveur distant, vous prenez une exception.
Ceci est causé par le fait que l’instance de service ne veut pas se lancer sur un serveur distant. Voir plutôt le code décompilé de SharePoint.
Si on prend le temps d’y penser quelques minutes c’est quelque part censé, pour démarrer un service il faut être administrateur de la machine locale dans un contexte d’exécution privilégié. Et ce n’est pas le cas lorsque le code est exécuté à distance.
Du coup au lieu d’appeler la méthode de provisionnement directement il est préférable de lancer un timerjob pour effectuer ce provisionnement à votre place. Et pas besoin de le développer, il existe déjà.
Simplement instancier un SPServiceInstanceJobDefinition en passant en paramètre votre instance de service et un booléen pour le provisionner ou le dé-provisionner.
Ensuite il suffit de donner une Schedule (one time) et de mettre à jour le timerjob (.Update()).
Voilà qui devrait vous éviter pas mal de recherche sur le sujet puisque ce n’est actuellement pas très bien documenté sur MSDN.
Merci à Jordan de mon équipe qui a passé la majeure partie du temps sur le sujet et qui m’a permis de publier cet article.