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:
- Cliquez avec le bouton droit sur le projet et sélectionnez Décharger le projet
- Cliquez avec le bouton droit sur le projet et sélectionnez Modifier votre-xxx.csproj
- 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.
- 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
$devant du chemin relatif. En outre, la réponse à votre question sur les fichiers NuGet.Config est ici . Il regarde d'abord dans .nuget, puis dans tous les répertoires parents, puis dans le fichier 'global' de votre AppData: puis les applique dans l'ordre REVERSE (quoi que cela signifie).