Configuration d'un dossier de packages nuget commun pour toutes les solutions lorsque certains projets sont inclus dans plusieurs solutions

J'utilise NuGet pour récupérer des packages à partir de sources de packages externes et internes, ce qui est très pratique. Mais j'ai réalisé que les packages sont par défaut stockés par solution, ce qui est très frustrant lorsque certains projets avec des références NuGet sont inclus dans plusieurs solutions. Ensuite, les références sont modifiées vers un autre dossier de package de solutions qui peut en fait être indisponible pour un autre développeur ou une machine de génération.

J'ai vu qu'il existe des moyens de signaler un emplacement de package commun (peut-être au niveau de la racine du projet, nous utilisons le contrôle de source TFS) avec la version 2.1 de NuGet, voir les notes de publication . J'utilise NuGet v2.7

Mais j'ai essayé d'ajouter des fichiers nuget.config sans voir aucun effet de cela. Les packages sont toujours stockés dans le dossier solution. Y a-t-il quelque chose que j'ai manqué? Il semble y avoir différentes structures du nœud xml à ajouter au fichier nuget.config, en fonction de la personne qui répond à cette question: Schwarzie suggère sur un autre thread Stackoverflow :

<settings>
  <repositoryPath>..\..\[relative or absolute path]</repositoryPath>
</settings>

Les notes de publication de NuGet 2.1 (voir le lien ci-dessus) suggèrent ce format:

<configuration>
  <config>
    <add key="repositoryPath" value="..\..\[relative or absolute path]" />
  </config>
</configuration>

Je ne sais pas lequel de ceux-ci, ou aucun, ou les deux fonctionnera à la fin. J'ai essayé les deux au niveau de la solution. Le fichier nuget.config peut-il être placé au niveau racine du projet TFS ou doit-il se trouver dans le répertoire solution? Il semble que NuGet lit et applique les paramètres de ces fichiers dans un certain ordre, pourquoi il serait judicieux de les ajouter à plusieurs niveaux, où un fichier nuget.config au niveau de la solution remplacerait celui au niveau de la racine du projet TFS. Cela peut-il être clarifié?

Dois-je supprimer tous les packages installés avant que ces références fonctionnent? J'adorerais que quelqu'un puisse fournir une instruction étape par étape pour passer de l'utilisation de nuget spécifique à une solution à un dossier de package commun où les projets appartenant à plusieurs solutions peuvent trouver les packages de nuget requis.

J'ai une situation similaire avec des sources de packages externes et internes avec des projets référencés dans plus d'une solution. Je viens de le faire fonctionner avec l'une de nos bases de code aujourd'hui et cela 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 devrait pas être difficile de s'adapter pour avoir le dossier des packages communs ailleurs).

• Base de code
  • Projet A
  • Projet B
  • Projet C
  • Solutions
    • Solution 1
    • Solution 2
    • Solution 3
    • Packages (c'est le commun partagé par toutes les solutions)

Réponse mise à jour à partir de NuGet 3.5.0.1484 avec Visual Studio 2015 Update 3

Ce processus est un peu plus facile maintenant que lorsque je me suis attaqué à cela à l'origine et que je pensais qu'il était temps de le mettre à jour. En général, le processus est le même avec moins d'étapes. Le résultat est un processus qui résout ou fournit les éléments suivants:

• Tout ce qui doit être engagé dans le contrôle du code source est visible et suivi dans la solution
• L'installation de nouveaux packages ou la mise à jour de packages à l'aide du gestionnaire de packages dans Visual Studio utilisera le chemin du référentiel correct
• Après la configuration initiale, pas de piratage des fichiers .csproj
• Aucune modification de la station de travail du développeur (le code est prêt à la compilation)

Il y a quelques inconvénients potentiels à prendre en compte (je ne les ai pas encore expérimentés, YMMV). Voir la réponse et les commentaires de Benol ci-dessous.

Ajouter NuGet.Config

Vous souhaiterez créer un fichier NuGet.Config à la racine du dossier \ Solutions \. Assurez-vous qu'il s'agit d'un fichier codé UTF-8 que vous créez, si vous ne savez pas comment procéder, utilisez le menu Fichier-> Nouveau-> Fichier de Visual Studio, puis choisissez le modèle de fichier XML. Ajoutez à NuGet.Config ce qui suit:

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

Pour le paramètre repositoryPath, vous pouvez spécifier un chemin absolu ou un chemin relatif (recommandé) à l'aide du jeton $. Le jeton $ est basé sur l'emplacement de NuGet.Config (le jeton $ est en fait relatif à un niveau en dessous de l'emplacement de NuGet.Config). Donc, si j'ai \ Solutions \ NuGet.Config et que je veux \ Solutions \ Packages, je devrais spécifier $ \ .. \ Packages comme valeur.

Ensuite, vous voudrez ajouter un dossier de solution à votre solution appelé quelque chose comme "NuGet" (clic droit sur votre solution, Ajouter-> Nouveau dossier de solution). Les dossiers de solution sont des dossiers virtuels qui n'existent que dans la solution Visual Studio et ne créeront pas de dossier réel sur le lecteur (et vous pouvez référencer des fichiers de n'importe où). Cliquez avec le bouton droit sur votre dossier de solution «NuGet», puis sur Ajouter-> Élément existant et sélectionnez \ Solutions \ NuGet.Config.

La raison pour laquelle nous faisons cela est pour qu'il soit visible dans la solution et devrait aider à s'assurer qu'il est correctement engagé dans votre contrôle de code source. Vous souhaiterez peut-être effectuer cette étape pour chaque solution de votre base de code qui participe à vos projets partagés.

En plaçant le fichier NuGet.Config dans \ Solutions \ au-dessus de tout fichier .sln, nous tirons parti du fait que NuGet naviguera de manière récursive dans la structure des dossiers à partir du «répertoire de travail actuel» à la recherche d'un fichier NuGet.Config à utiliser. Le «répertoire de travail actuel» signifie deux choses différentes ici, l'une est le chemin d'exécution de NuGet.exe et l'autre est l'emplacement du fichier .sln.

Changer de dossier de packages

Tout d'abord, je vous recommande vivement de parcourir chacun de vos dossiers de solution et de supprimer tous les dossiers \ Packages \ existants (vous devrez d'abord fermer Visual Studio). Cela permet de voir plus facilement où NuGet place votre dossier \ Packages \ nouvellement configuré et garantit que tout lien vers un dossier \ Packages \ incorrect échouera et pourra ensuite être corrigé.

Ouvrez votre solution dans Visual Studio et lancez une reconstruction complète. Ignorez toutes les erreurs de génération que vous recevrez, cela est attendu à ce stade. Cela devrait toutefois lancer la fonctionnalité de restauration du package NuGet au début du processus de génération. Vérifiez que votre dossier \ Solutions \ Packages \ a été créé à l'emplacement souhaité. Si ce n'est pas le cas, vérifiez votre configuration.

Désormais, pour chaque projet de votre solution, vous souhaiterez:

1. Cliquez avec le bouton droit sur le projet et sélectionnez Décharger le projet
2. Cliquez avec le bouton droit sur le projet et sélectionnez Modifier votre-xxx.csproj
3. Recherchez toutes les références à \ packages \ et mettez-les à jour vers le nouvel emplacement.
   • La plupart d'entre eux seront des références <HintPath>, mais pas tous. Par exemple, WebGrease et Microsoft.Bcl.Build auront des paramètres de chemin distincts qui devront être mis à jour.
4. Enregistrez le .csproj, puis cliquez avec le bouton droit sur le projet et sélectionnez Recharger le projet

Une fois que tous vos fichiers .csproj ont été mis à jour, lancez un autre Rebuild All et vous ne devriez plus avoir d'erreurs de construction concernant les références manquantes. À ce stade, vous avez terminé et vous avez maintenant configuré NuGet pour utiliser un dossier Packages partagé.

À partir de NuGet 2.7.1 (2.7.40906.75) avec VStudio 2012

Tout d'abord, il convient de garder à l'esprit que nuget.config ne contrôle pas tous les paramètres de chemin dans le système de paquets nuget. C'était particulièrement difficile à comprendre. Plus précisément, le problème est que msbuild et Visual Studio (appelant msbuild) n'utilisent pas le chemin d'accès dans nuget.config, mais le remplacent plutôt dans le fichier nuget.targets.

Préparation de l'environnement

Tout d'abord, je passerais par le dossier de votre solution et supprimerais tous les dossiers \ packages \ existants. Cela aidera à garantir que tous les packages s'installent visiblement dans le bon dossier et à découvrir les références de chemin erronées dans vos solutions. Ensuite, je m'assurerais que la dernière extension nuget Visual Studio est installée. Je voudrais également m'assurer que vous avez le dernier nuget.exe installé dans chaque solution. Ouvrez une invite de commande et accédez à chaque dossier $ (SolutionDir) \ .nuget \ et exécutez la commande suivante:

nuget update -self

Définition du chemin d'accès au dossier de package commun pour NuGet

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

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

Remarque: vous pouvez utiliser un chemin absolu ou un chemin relatif. Gardez à l'esprit que si vous utilisez un chemin relatif avec $, il est relatif à un niveau en dessous de l'emplacement de NuGet.Config (croyez qu'il s'agit d'un bogue).

Définition du chemin d'accès au dossier de package commun pour MSBuild et Visual Studio

Ouvrez chaque $ (SolutionDir) \ .nuget \ NuGet.targets et modifiez la section suivante (notez que pour les non-Windows, il y a une autre section en dessous):

<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>

Mettre à jour PackagesDir pour être

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

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

Restauration de tous les packages nuget dans un dossier commun

Ouvrez une invite de commande et accédez à chaque $ (SolutionDir) \ .nuget et exécutez la commande suivante:

nuget restore ..\YourSolution.sln

À ce stade, vous devez avoir un seul dossier \ packages \ dans votre emplacement commun et aucun dans l'un de vos dossiers de solution. Sinon, vérifiez vos chemins.

Correction des références de projet

Ouvrez chaque fichier .csproj dans un éditeur de texte et recherchez toutes les références à \ packages et mettez-les à jour avec le chemin correct. La plupart d'entre eux seront des références <HintPath>, mais pas tous. Par exemple, WebGrease et Microsoft.Bcl.Build auront des paramètres de chemin distincts qui devront être mis à jour.

Construisez votre solution

Ouvrez votre solution dans Visual Studio et lancez une build. S'il se plaint de paquets manquants qui doivent être restaurés, ne supposez pas que le paquet est manquant et doit être restauré (l'erreur peut être trompeuse). Il peut s'agir d'un mauvais chemin dans l'un de vos fichiers .csproj. Vérifiez cela avant de restaurer le package.

Vous avez une erreur de construction concernant les packages manquants?

Si vous avez déjà vérifié que les chemins dans vos fichiers .csproj sont corrects, vous avez deux options à essayer. Si cela est le résultat de la mise à jour de votre code à partir du contrôle de code source, vous pouvez essayer d'extraire une copie propre, puis de la créer. Cela a fonctionné pour l'un de nos développeurs et je pense qu'il y avait un artefact dans le fichier .suo ou quelque chose de similaire. L'autre option consiste à forcer manuellement la restauration d'un package à l'aide de la ligne de commande dans le dossier .nuget de la solution en question:

nuget restore ..\YourSolution.sln

Au lieu de définir un emplacement de package commun pour tous les projets, il est également possible de modifier HintPath dans le projet comme suit:

<HintPath>$(SolutionDir)\packages\EntityFramework.6.1.0\lib\net40\EntityFramework.dll</HintPath>

Dans la plupart des cas, il n'y aura que quelques packages dans un projet partagé, vous pouvez donc le changer facilement.

Je pense que c'est une meilleure solution, lorsque vous branchez du code, lors de la définition d'un référentiel commun, vous devez changer le chemin relatif, dans cette solution, vous n'avez pas besoin de le faire.

Mon expérience en essayant ceci avec la dernière version de NuGet (2.7) et VS2012:

• Supprimer le dossier .nuget (sur le disque et dans la solution)
• Placer un fichier NuGet.Config dans un dossier parent commun de toutes les solutions
• Supprimer tous les dossiers de packages existants
• Parcourez tous les fichiers csproj et modifiez HintPaths pour pointer vers le nouvel emplacement
• Profit

Dans mon cas, je voulais mettre tous les packages .packages, donc mon NuGet.Config ressemblait à ci-dessous.

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <config>
     <add key="repositorypath" value=".packages" />
   </config>
 </configuration>

Notez qu'il y a quelques choses `` étranges '' qui peuvent arriver, mais je pense qu'elles sont supportables:

• Si vous «mettez à jour» un package à partir d'une solution, il supprimera rapidement l'ancienne version de votre dossier packages (il ne peut pas savoir si vous avez une autre solution qui pointe là). Cela ne me dérange pas beaucoup, car l'autre solution ne sera restaurée que si nécessaire.
• Si vous essayez d'ajouter un package à partir d'une solution de clic droit, si le package est déjà présent dans une autre solution, il verra qu'il est là et vous montrera la «coche verte» au lieu du bouton «installer». J'installe généralement à partir d'un clic droit sur le projet, donc cela ne me dérange pas du tout.

Avertissement : je viens d'essayer ceci aujourd'hui, je n'ai aucune expérience à long terme pour le sauvegarder!

J'ai la version 2.8.50926 de NuGet avec VS 2013. Vous n'avez pas besoin d'utiliser plusieurs fichiers nuget.config ou d'utiliser des structures de répertoires complexes. Modifiez simplement le fichier par défaut situé ici:

%APPDATA%\Roaming\NuGet\NuGet.Config

Voici le contenu de mon dossier:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\Projects\nugetpackages" />
  </config>
  <activePackageSource>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </activePackageSource>
</configuration>

Ainsi, tous les packages vont dans le dossier "C: \ Projects \ nugetpackages", quelle que soit la solution.

Dans toutes vos solutions, supprimez simplement les dossiers "packages" existants. Générez ensuite votre solution et NuGet restaurera automatiquement les packages manquants dans le nouveau répertoire centralisé que vous avez spécifié.

Il n'est déjà pas nécessaire de modifier nuget.targets. Il a été corrigé dans nuget 2.8 ( http://nuget.codeplex.com/workitem/2921 ). Il vous suffit de définir repositorypath.

À partir de Visual Studio 2013 Update 4 et Nugget Package Manager version> 2.8.5 ...

Créez le fichier nuget.config à la racine du référentiel.

contenu du fichier:

<configuration>
  <config>
    <add key="repositoryPath" value="packages" />
  </config>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

Cela entraînera que tous les packages iront dans le dossier packages au niveau du fichier nuget.config de votre.

Vous pouvez maintenant accéder à chaque console nuget .sln avec la commande 'update-package -reinstall'

Si vous avez plusieurs référentiels au même niveau et que partager le même dossier de package entre eux, essayez d'utiliser le moyen de remonter d'un dossier.

 <add key="repositoryPath" value="..\packages" />

Mais de cette façon, vous faites en sorte que la référence des packages nuget csproj pointe vers un dossier en dehors du chemin de vos référentiels.

J'ai concocté un package NuGet qui convertit de manière transparente toutes les références NuGet d'un projet dans un format relatif $ (SolutionDir). Il le fait en utilisant la transformation XSLT au moment de la construction, vous n'avez donc pas besoin de pirater votre fichier de projet à la main. Vous pouvez mettre à jour vos packages librement, cela ne cassera rien.

https://www.nuget.org/packages/NugetRelativeRefs

Ou vous si vous utilisez Visual Studio 2015 Update 3, vous pouvez simplement migrer vos références de package vers le project.jsonformulaire comme décrit ici: https://oren.codes/2016/02/08/project-json-all-the-things

Mettre à jour mon expérience avec nuget 2.8.3. C'était relativement simple. Tout ce qui a été fait a été la restauration de package activée à partir d'une solution de clic droit. Edité NuGet.Config et ajouté ces lignes:

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

Ensuite, reconstruit la solution, il télécharge tous les packages dans le dossier souhaité et met à jour les références automatiquement. J'ai fait la même chose pour tous mes autres projets, où seuls les packages incrémentiels étaient téléchargés et les packages existants référencés. D'où un référentiel de packages commun pour tous les projets tel qu'il a été défini.

Voici une procédure étape par étape pour activer la restauration du package.

http://blogs.4ward.it/enable-nuget-package-restore-in-visual-studio-and-tfs-2012-rc-to-building-windows-8-metro-apps/

Juste hardlink / packages vers l'emplacement partagé souhaité. Ensuite, votre projet ne sera pas interrompu pour les autres utilisateurs, qui n'ont pas d'emplacement de packages spécial.

Ouvrez une invite de commande en tant qu'administrateur et utilisez

mklink /prefix link_path Target_file/folder_path

Pour toute solution significative, les réponses ci-dessus seront insuffisantes. Tout simplement, une structure d'espace de travail TFS complexe avec des chemins relatifs différents, des ramifications, des projets partagés, etc., rend un référentiel central unique impossible.

Utiliser ($ SolutionDir) est un pas dans la bonne direction, mais le codage manuel du fichier csproj avec ($ SolutionDir) deviendrait assez fastidieux dans une base de code avec des centaines de packages mis à jour régulièrement (à chaque mise à jour, le HintPath est écrasé par un nouveau chemin relatif). Que se passe-t-il si vous devez exécuter Update-Package -Reinstall.

Il existe une excellente solution appelée NugetReferenceHintPathRewrite . Il automatise l'injection de ($ SolutionDir) dans les HintPaths juste avant la construction (sans modifier réellement le fichier csproj). J'imagine qu'il pourrait facilement être intégré dans des systèmes de construction automatisés

Un bref résumé pour ceux sur VS 2013 Professional avec la version NuGet : 2.8.60318.667

Voici comment diriger les packages vers un chemin relatif au dossier .nuget:

<configuration>
  <config>
    <add key="repositoryPath" value="../Dependencies" />
  </config>
</configuration>

Par exemple, si votre solution (fichier .sln) réside dans C: \ Projects \ MySolution, lorsque vous activez la restauration du package NuGet, le dossier .nuget est créé comme suit: C: \ Projects \ MySolution.nuget et les packages seront téléchargés dans un répertoire comme celui-ci: C: \ Projects \ MySolution \ Dependencies

REMARQUE: pour une raison (inconnue), chaque fois que je mets à jour le "repositoryPath", je dois fermer et rouvrir la solution pour que les modifications prennent effet

pour ceux qui utilisent paket comme gestionnaire de paquets, il existe une option de lien symbolique automatique pour votre fichier de dépendances:

storage: symlink

btw: paket exploite nuget

référence: https://fsprojects.github.io/Paket/dependencies-file.html

Si vous voulez modifier le moins possible, vous pouvez simplement nettoyer périodiquement les sous-répertoires avec un script. c'est à dire. Le comportement par défaut de Nuget est de copier des fichiers d'un emplacement global vers un dossier de packages local, supprimez donc ces fichiers par la suite.

J'utilise simplement des jonctions NTFS pour rendre tous les dossiers de packages directement dans un seul dossier au-dessus des racines du référentiel. Fonctionne très bien. Aucun problème avec la restauration de packages parallèles sur plusieurs solutions. Un avantage à cela est que vous n'avez rien à reconfigurer dans votre code source, comme les centaines de chemins d'indices relatifs dans vos fichiers .csproj. Cela fonctionne simplement en laissant le système de fichiers gérer la redirection et la simulation d'un seul dossier de packages.

Faites juste attention aux problèmes de «git». Bien que «git status» via la ligne de commande ne montre aucune modification non mise en scène, j'ai remarqué que GitKraken voit la jonction de «package» comme un fichier non mis en scène . Il affiche même des erreurs telles que «le fichier est un répertoire» lorsque vous cliquez dessus. GitKraken essaiera également de cacher ce «fichier» si vous rebasez, détruisez la jonction et restaurez-le en tant que fichier réel contenant du texte avec le chemin du fichier d'origine. Comportement très étrange. Peut-être pourrez-vous contourner ce problème en vous assurant que le fichier de packages est ajouté à votre .gitignore.

Voici les instructions de NuGet 2.1: http://docs.nuget.org/docs/release-notes/nuget-2.1

Pas besoin de modifier les fichiers au niveau de la solution.

Fonctionne avec Visual Studio 2013 et trois projets de partage de solutions.

N'oubliez pas de mettre à jour NuGet au niveau de la solution (chaque nuget.exe dans les dossiers .nuget).