Configurer des compléments hébergés par un fournisseur SharePoint pour la distribution
Cette page décrit les problèmes qui peuvent survenir lors du partage d’un complément hébergé par un fournisseur SharePoint avec d’autres développeurs ou lors de l’obtention d’une copie à partir d’un système de contrôle de code source tel que Team Foundation Server, Git ou Visual Studio Team Services.
Tous les compléments hébergés par un fournisseur SharePoint créés à l’aide de Visual Studio incluent un package NuGet qui ajoute du code et des références spécifiques à SharePoint à l’application web qui sert de RemoteWeb pour le complément SharePoint.
Le package NuGet ajouté au projet d’application web par les Outils de développement Office dans Visual Studio n’est pas présent dans le registre des packages NuGet et, par conséquent, les tentatives de restauration d’un package NuGet échouent, car il ne trouve pas de package correspondant.
Comprendre le problème
Les Outils de développement Office pour Visual Studio, version 12.0.31105, ajoutent un package NuGet aux applications web créées en tant que compléments hébergés par un fournisseur RemoteWeb pour SharePoint. Ce package, App for SharePoint Web Toolkit, ajoute les éléments suivants au projet web :
- Assemblys et références aux assemblys de modèle objet côté client (CSOM) SharePoint.
- Fichier de code TokenHelper.cs qui facilite le processus d’authentification des compléments.
- Fichier de code SharePointContext.cs qui permet de créer et de gérer un contexte SharePoint dans l’application web.
Le fonctionnement de Visual Studio est qu’il ou les compléments contiennent généralement une copie locale du package NuGet afin que les développeurs n’aient pas toujours besoin d’être connectés à Internet pour télécharger les packages NuGet. Le package inclus dans les outils a l’ID AppForSharePoint16WebToolkit.
Lorsque les projets sont engagés dans le contrôle de code source, les packages ne sont généralement pas inclus dans le cadre de la validation, car ils peuvent ajouter beaucoup d’espace de stockage supplémentaire et augmenter inutilement la taille d’un package lors du partage avec d’autres développeurs. Par conséquent, l’une des premières tâches que les développeurs effectuent après avoir obtenu une copie du projet à partir du contrôle de code source consiste à exécuter la restauration de package NuGet.
Le problème est qu’un package avec le même ID n’existe pas dans le registre de packages NuGet . il n’existe aucun package avec l’ID AppForSharePoint16WebToolkit. Au lieu de cela, le même package a été ajouté au registre de packages NuGet que AppForSharePointWebToolkit (notez l’absence de dans 16 l’ID).
Préparer un projet de complément hébergé par un fournisseur pour le contrôle de code source et la distribution
Jusqu’à ce que les outils de développement Office pour Visual Studio soient mis à jour pour résoudre ce problème, nous vous recommandons de modifier le projet avant de valider votre système de contrôle de code source, que vous utilisiez Team Foundation Server, Visual Studio Team Services, Git ou toute autre solution.
Après avoir créé le projet, examinez le fichier packages.config du projet et recherchez un package avec l’ID AppForSharePoint16WebToolkit. Le moyen le plus sûr de mettre à jour le projet consiste à désinstaller, puis réinstaller le package.
Ouvrez la console du Gestionnaire de package dans Visual Studio et entrez ce qui suit pour désinstaller le package :
PM> Uninstall-Package -Id AppForSharePoint16WebToolkit
Remarque
Si la désinstallation génère une erreur de non-recherche du package, supprimez simplement manuellement la référence du package du fichier packages.config et enregistrez vos modifications.
À présent, installez la version publique du même package NuGet à partir du registre public :
PM> Install-Package -Id AppForSharePointWebToolkit