Configurer des SharePoint hébergés par un fournisseur pour la distribution
Cette page explique les problèmes qui peuvent survenir lors du partage d’un SharePoint hébergé par un fournisseur avec d’autres développeurs ou lors de l’obtention d’une copie à partir d’un système de contrôle source tel que Team Foundation Server, Git ou Visual Studio Team Services.
Tous les SharePoint de produits hébergés par un fournisseur créés à l’aide de Visual Studio incluent un package NuGet qui ajoute du code spécifique à SharePoint et des références à l’application web qui sert de RemoteWeb pour le 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 du package NuGet et, par conséquent, tente d’effectuer une restauration de package NuGet échoue, 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 RemoteWeb pour les applications hébergées par un fournisseur SharePoint. Ce package, app for SharePoint Web Shared Computer Toolkit, ajoute les éléments suivants au projet web :
- Assemblies and references to the SharePoint client-side object model (CSOM) assemblies.
- Fichier de code TokenHelper.cs qui vous aide dans le processus d’authentification des applications.
- Fichier de code SharePointContext.cs qui facilite la création et la maintenance d’SharePoint contexte dans l’application web.
La façon dont Visual Studio fonctionne est qu’il contient généralement une copie locale du package NuGet afin que les développeurs n’ont pas toujours besoin d’être connectés à Internet pour télécharger les packages NuGet. Le package que les outils incluent a un ID d’AppForSharePoint16WebToolkit.
Lorsque les projets sont engagés dans le contrôle de source, les packages ne sont généralement pas inclus dans le cadre de la validation, car ils peuvent ajouter de nombreuses demandes d’espace de stockage supplémentaires 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 font après avoir obtenu une copie du projet à partir du contrôle de source consiste à exécuter NuGet restauration de package.
La difficulté est qu’un package avec le même ID n’existe pas dans le registre NuGet package ; il n’existe aucun package avec un ID d’AppForSharePoint16WebToolkit. Au lieu de cela, le même package a été ajouté au registre du package NuGet comme AppForSharePointWebToolkit (notez l’absence de 16 l’ID).
Préparer un projet de add-in hébergé par un fournisseur pour le contrôle source et la distribution
Tant que les Outils de développement Office pour Visual Studio n’ont pas été mis à jour pour résoudre ce problème, nous vous recommandons de modifier le projet avant de vous engager dans votre système de contrôle source, que vous utilisiez Team Foundation Server, Visual Studio Team Services, Git ou toute autre solution.
Après avoir créé le projet, recherchez dans le fichier packages.config du projet et recherchez un package avec un ID d’AppForSharePoint16WebToolkit. Le moyen le plus sûr de mettre à jour le projet consiste à désinstaller puis à réinstaller le package.
Ouvrez la console Gestionnaire de package dans Visual Studio et entrez les entrées suivantes pour désinstaller le package :
PM> Uninstall-Package -Id AppForSharePoint16WebToolkit
Notes
Si la désinstallation a pour effet de ne pas trouver le package, supprimez simplement la référence du package du fichier packages.config manuellement et enregistrez vos modifications.
À présent, installez la version publique du même package NuGet à partir du Registre public :
PM> Install-Package -Id AppForSharePointWebToolkit