Création d'un répertoire commun de paquets nuget pour toutes les solutions lorsque certains projets sont inclus dans plusieurs solutions

j'ai une situation similaire, avec interne et externe des sources de paquets avec des projets référencés dans plus d'une solution. Je viens juste de le faire fonctionner avec une de nos bases de code aujourd'hui et il semble fonctionner avec les postes de travail des développeurs et notre serveur de construction. Le processus ci-dessous a ce scénario à l'esprit (bien qu'il ne soit pas difficile de s'adapter pour avoir le dossier commun des paquets else where).

• Codebase
  • Projet A
  • Projet B
  • Projet C
  • Solutions
    • Solution 1
    • Solution 2
    • Solution 3
    • Paquets (c'est la commune partagée par toutes les solutions)

mise à jour de la réponse à partir de NuGet 3.5.0.1484 avec Visual Studio 2015 Mise À Jour 3

ce processus est un peu plus facile maintenant que lorsque j'ai abordé à l'origine cette question et j'ai pensé qu'il était temps de le mettre à jour. En général, le processus est le même, juste avec moins d'étapes. Le résultat est un processus qui résout ou fournit ce qui suit:

• Tout ce qui doit être affecté au contrôle du code source est visible et suivi dans la solution
• installer de nouveaux paquets ou mettre à jour des paquets en utilisant le Gestionnaire de paquets dans Visual Studio utilisera le chemin correct du dépôt
• après la configuration initiale, pas de piratage .csproj files
• aucune modification du poste de travail du développeur (le Code est construit prêt à la sortie)

il y a des inconvénients potentiels dont il faut être conscient (Je ne les ai pas encore vécus, YMMV). Voir Benol's réponse et commentaires ci-dessous.

Ajouter NuGet.Config

vous voulez créer un NuGet.Fichier de configuration dans la racine du dossier \Solutions\. Assurez-vous qu'il s'agit d'un fichier encodé UTF-8 que vous créez, si vous ne savez pas comment le faire, utilisez le menu Fichier->Nouveau - >de Visual Studio et choisissez ensuite le modèle de fichier XML. Ajouter à NuGet.Config suivante:

<?xml version="1.0" encoding="utf-8"?>
<configuration>  
  <config>
    <add key="repositoryPath" value="$\..\Packages" />
  </config>
</configuration>

pour le paramètre de chemin de repositoryPath, vous pouvez spécifier un chemin absolu ou un chemin relatif (recommandé) en utilisant le token$. Le $ token est basé sur où est le NuGet?Config est situé (le token $ est en fait relatif à un niveau en dessous de l'emplacement du NuGet.Config). Donc, si j'ai \Solutions\NuGet.Config et je veux \Solutions\Packages j'aurais besoin de spécifier $\..\Packages comme valeur.

ensuite, vous voudrez ajouter un dossier Solution à votre solution appelé quelque chose comme" NuGet " (clic droit sur votre solution, Ajouter->nouveau dossier Solution). Les dossiers de Solution sont des dossiers virtuels qui existe dans la solution Visual Studio et ne créera pas un dossier réel sur le lecteur (et vous pouvez référencer les fichiers de n'importe où). Cliquez avec le bouton droit de la souris sur le dossier de la solution "NuGet", puis ajoutez->L'élément existant et sélectionnez \Solutions\NuGet.Config.

La raison pour laquelle nous le faisons, c'est qu'il est visible dans la solution et devrait aider à s'assurer qu'il est correctement engagé à votre contrôle de code source. Vous pouvez faire cette étape pour chaque solution dans votre base de code qui est participer à vos projets communs.

en plaçant le NuGet.Fichier de Config dans \Solutions\ au-dessus de tout .sln files, nous profitons du fait que NuGet va naviguer récursivement la structure du dossier vers le haut à partir du "répertoire de travail courant" à la recherche d'un NuGet.Fichier de configuration à utiliser. Le "répertoire de travail courant" signifie deux choses différentes ici, l'une est le chemin D'exécution de NuGet.exe et l'autre est la situation de l' .la sln fichier.

changement de dossier de vos paquets

tout d'abord, je vous recommande fortement de parcourir chacun de vos dossiers de solution et de supprimer tout \Packages\ dossiers qui existent (vous aurez besoin de fermer Visual Studio d'abord). Cela permet de voir plus facilement où NuGet place votre nouveau répertoire \Packages et garantit que tout lien vers le mauvais répertoire\ Packages échouera et pourra alors être corrigé.

ouvrez votre solution dans Visual Studio et Tout Reconstruire. Ignorez toutes les erreurs de compilation que vous recevrez, ceci est attendu à ce point. Cela devrait toutefois déclencher la fonction de restauration du paquet NuGet au début du processus de compilation. Vérifiez que votre répertoire \Solutions\Packages\ folder a été créé à l'endroit voulu. Si ce n'est pas le cas, examinez votre configuration.

maintenant, pour chaque projet dans votre solution vous voudrez:

1. droit-cliquez sur le projet et sélectionnez décharger le projet
2. faites un clic droit sur le projet et sélectionnez Modifier votre-xxx.1519130920"
3. trouvez toute référence à \packages\ et mettez-les à jour vers le nouvel emplacement.
   • la plupart de ces références seront , mais pas toutes. Par exemple, WebGrease et Microsoft.Bcl.Build aura des paramètres de chemin séparés qui devront être mis à jour.
4. Enregistrer la .csproj et puis droit-cliquez sur le projet et sélectionnez Recharger Projet

une fois tous vos .les fichiers csproj ont été mis à jour, lancer une autre reconstruction et vous ne devriez plus avoir d'erreurs de compilation sur les références manquantes. À ce stade, vous avez terminé, et vous avez maintenant NuGet configuré pour utiliser un dossier paquets partagés.

à partir de NuGet 2.7.1 (2.7.40906.75) avec VStudio 2012

la première chose à garder à l'esprit est que nuget.config ne contrôle pas tout des paramètres de chemin dans le système de paquets nuget. C'était particulièrement déroutant à comprendre. Plus précisément, le problème est que msbuild et Visual Studio (appelé msbuild) n'utilisent pas le chemin dans nuget.config mais plutôt primordial dans la nuget.le fichier des cibles.

Préparation De L'Environnement

tout d'abord, je vais parcourir le dossier de votre solution et supprimer tous les \packages\ folders qui existent. Cela permettra de s'assurer que tous les paquets sont visiblement installation dans le bon dossier et pour vous aider à découvrir toutes les références de mauvais chemin à travers vos solutions. Ensuite, je voudrais m'assurer que vous avez la dernière extension de studio visuel nuget installé. Je m'assurerais aussi que vous ayez le dernier nuget.exe installé dans chaque solution. Ouvrez une invite de commande et allez dans chaque $(SolutionDir)\ .nuget \ folder et exécuter la commande suivante:

nuget update -self

définition du chemin du dossier du paquet commun pour NuGet

Ouvrez chaque $(SolutionDir)\ .nuget\NuGet.Config et ajouter ce qui suit dans la section < configuration>:

<config>
    <add key="repositorypath" value="$\..\..\..\Packages" />
</config>

Note: vous pouvez utiliser un chemin absolu ou un chemin relatif. Gardez à l'esprit, si vous utilisez un chemin relatif avec $ qu'il est relatif à un niveau sous l'emplacement du NuGet.Config (croyez que c'est un bug).

définir le dossier de paquet commun chemin pour MSBuild et studio visuel

ouvrir chaque $(SolutionDir)\ .nuget\NuGet.cibler et modifier la section suivante (notez que pour les non-fenêtres il y a une autre section Sous elle):

<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
    <!-- Windows specific commands -->
    <NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
    <PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
    <PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>

mise à Jour PackagesDir être

<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>

Note: le GetFullPath résoudra notre chemin relatif en un chemin absolu.

restauration de tous les nuget packages dans le dossier commun

ouvrez une invite de commande et allez à chaque $(SolutionDir)\ .nuget et exécuter la commande suivante:

nuget restore ..\YourSolution.sln

à ce stade, vous devriez avoir un seul \packages\ folder dans votre emplacement commun et aucun dans l'un de vos dossiers de solution. Si non, alors vérifiez vos chemins d'accès.

fixation des références du projet

ouvert tous .fichier csproj dans un éditeur de texte et trouver n'importe quel références aux paquets \et mettez-les à jour vers le chemin correct. La plupart d'entre eux seront des références , mais pas tous. Par exemple, WebGrease et Microsoft.Bcl.Build aura des paramètres de chemin séparés qui devront être mis à jour.

Construisez votre solution

ouvrez votre solution dans Visual Studio et démarrez une construction. Si elle se plaint de paquets manquants qui doivent être restaurés, ne supposez pas que le paquet est manquant et doit être restauré (erreur peut être trompeuse). Il pourrait être un mauvais chemin dans un de vos .dossiers csproj. Vérifiez cela avant de restaurer le paquet.

avez-vous une erreur de compilation à propos des paquets manquants?

si vous avez déjà vérifié que les chemins dans votre .csproj fichiers sont corrects, alors vous avez deux options pour essayer. Si c'est le résultat de la mise à jour de votre code à partir du contrôle du code source, alors vous pouvez essayer de vérifier une copie propre et ensuite construire cela. Cela a fonctionné pour l'un de nos développeurs et je pense qu'il y a un artefact dans le .suo file ou quelque chose comme ça. L'autre option consiste à forcer manuellement la restauration d'un paquet en utilisant la ligne de commande dans le .nuget dossier de la solution en question:

nuget restore ..\YourSolution.sln