“SYSTEM.IO.FILENOTFOUNDEXCEPTION: COULD NOT LOAD FILE OR ASSEMBLY ‘MICROSOFT.SHAREPOINT.CLIENT. WORKFLOWSERVICES”

Vous lancez votre application ou solution SharePoint utilisant CSOM et Workflow Manager 1.0(WorkflowServicesManager, Workflow Definition), vous avez le message suivant qui s’affiche : “System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.SharePoint.Client.WorkflowServices, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ or one of its dependencies. The system cannot find the file specified.”

Solution 1 (application seulement) :

Vous copiez les DLLs suivantes à la racine de votre applications (si c’est une solution SharePoint, cette solution n’est pas applicable) :

  • – Microsoft.SharePoint.Client.dll
  • – Microsoft.SharePoint.Client.Runtime.dll
  • – Microsoft.SharePoint.Client.WorkflowServices.dll

Solution 2 :

Si gacutil.exe n’est pas sur votre serveur de production/qualification, copiez depuis le répertoire de votre machine de développement “C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6 Tools” (ou d’un répertoire v8.0, v8.1A) les fichiers suivants :

– gacutil.exe
– gacutil.exe.config
– 1033\gacutlrc.dll

Ouvrez une console en tant qu’administrateur. Depuis l’emplacement où vous avez copier gacutil.exe (ou depuis n’importe quel emplacement si vous avez mis gacutil dans le PATH), saisissez :

gacutil -i “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.dll”

gacutil -i “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.Runtime.dll”

gacutil -i “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\ISAPI\Microsoft.SharePoint.Client.WorkflowServices.dll”

Pour chaque commande, vous devriez avoir le message suivant : Assembly successfully added to the cache

Toutes les DLLs requises pour votre solution utilisant CSOM / Workflow Manager sont maintenant disponibles dans le GAC et votre solution devrait fonctionner.

Flux de travail SharePoint 2013 non disponible dans SharePoint Designer

Lors de la préparation de quelques démos en vue d’une présentation sur le développement de workflow avec SharePoint 2013, l’installation en standalone a tendance à créer un proxy d’application de service pour workflow non fonctionnel (en général c’est aussi le cas d’autres services…).

Par conséquent, si vous faites un tour dans SharePoint Designer 2013 et que vous essayez de créer un flux de travail, vous n’aurez que le choix du type ‘Flux de travail SharePoint 2010’, la version 2013 n’étant pas disponible :

post_workflow_spd2013 (1)

Il suffit d’aller dans l’administration centrale pour constater du non appareillage du service Workflow Manager avec votre ferme SharePoint 2013 (naviguez dans Gestion des applications > Gérer les services > Workflow Service) :

post_workflow_spd2013 (2)

Pour résoudre ce problème, il suffit de supprimer puis de recréer un proxy du service de Workflow. Néanmoins, si vous essayez de créer ce proxy depuis l’Administration Centrale, vous risquez de tourner en rond assez longtemps car le type de service n’est pas proposé par l’interface :

post_workflow_spd2013 (3)

Voici la procédure pour venir à bout de ce problème :

  1. Dans la fenêtre des services, supprimer le service ‘Workflow Service’
  2. Exécuter la ligne de commande PowerShell suivante dans une console SharePoint 2013 Management Shell : Register-SPWorkflowService –SPSite “http://devcontoso/” –WorkflowHostUri “https://devcontoso:12291″ –AllowOAuthHttp

Note : mon serveur Workflow Manager 1.0 (version Refresh nécessaire si vous êtes sur Windows Server 2012) est hébergé sur le même serveur que SharePoint 2013, j’autorise donc la communication http avec le paramètre –AllowOAuthHttp. Consulter la documentation technet pour d’autres types de topologies et protocoles : http://technet.microsoft.com/en-us/library/jj658588%28v=office.15%29.aspx

Remarque : si vous déjà enregsitré un scope « SharePoint » dans votre serveur Workflow Manager, un message d’erreur s’affiche. Dans ce cas, forcez l’enregistrement avec le paramètre -Force pour écraser l’ancien scope :

post_workflow_spd2013 (4)

Formulaires dans SharePoint Server 2016 : InfoPath Forms Services reste !

Le doute planait depuis plus d’un an, Microsoft aura mis du temps à tenir ses clients au courant sur ce point, parfois critique pour les sociétés grande utilisatrice de InfoPath Forms. La nouvelle est enfin tombée : InfoPath Forms va continuer son chemin dans SharePoint  Server 2016 ‘on prems’ (installation locale) et pleinement supporté dans Office 365. Microsoft assure que les formulaires pourront être migrés sans problème vers SharePoint 2016. Néanmoins, comme annoncé InfoPath 2013 est bien la dernière version du produit client et fonctionnera avec SharePoint Server 2016.

Vous pouvez retrouver l’intégralité de l’annonce dans ce billet de l’équipe Office : http://blogs.office.com/2014/01/31/update-on-infopath-and-sharepoint-forms/

L’annonce énonce bien le fait qu’il ne s’agit que d’un décalage dans le planning de retrait d’InfoPath. Néanmoins, et malgré un support dans SharePoint Server 2016 qui devrait emmener les entreprises jusqu’en 2018/2019, InfoPath semble néanmoins le technologie qu’il faudra envisager de changer à moyens termes. En espérant que l’éditeur ne réitère pas ce comportement de « black out » total sur la question à nouveau lors de la prochaine release de SharePoint Server.