web-dev-qa-db-fra.com

Restauration de tous les packages Nuget dans une solution Visual Studio 2015

J'ai lu de nombreuses réponses sur SO et NuGet (et Internet en général, vraiment), mais je ne parviens pas à résoudre le problème rencontré avec la restauration du package NuGet dans Visual Studio 2015. I avoir les scénarios suivants. 

Solution A Structure

--Projet A

Si j'ouvre et crée la solution A, la boîte de dialogue indiquant la progression de la restauration du paquet de nugets s'affiche et la solution est générée avec succès.

Solution B Structure

--Projet A

--Projet B

Cependant, en supposant que je n’ai jamais construit la solution A (c’est-à-dire une nouvelle extraction de TFS), si j’ouvre et construisais la solution B, la boîte de dialogue indiquant la progression de la restauration du paquet de nugets apparaît, mais la construction échoue car le projet A échoue. 

Ce qui semble se produire est que NuGet est en train de restaurer les paquetages pour le projet B, mais pas pour le projet A, ce qui entraîne l'échec de la construction. Si je regarde les références du projet B, toutes les références de NuGet ont été résolues, mais les références du projet A sont toujours brisées. 

Quelques points:

  • J'ai désactivé l'intégration du contrôle de source pour NuGet et je ne contrôle donc pas le dossier Packages.
  • Chaque projet a son propre fichier packages.config
  • L'ordre de génération dans la solution B est le projet A, puis le projet B

Des pensées seraient grandement appréciées. 

c#visual-studiotfsnugetnuget-package-restore
4
dparsons

Par défaut, NuGet crée le dossier packages de la solution dans la racine de la solution et chaque projet référence ses DLL de package à ce dossier de packages "local". Dans votre exemple, si vous ouvrez le fichier .csproj pour le projet A, vous verrez probablement que le chemin de référence est quelque chose comme ..\packages\[package name]\[etc].

Ainsi, lorsque vous effectuez une nouvelle extraction à partir de TFS et que vous générez la solution B, le projet A ne peut pas trouver ses DLL car c:\workspace\Solution A\packages n'existe pas encore (ou quel que soit le chemin absolu sur votre ordinateur). 

Pour corriger cela, utilisez un dossier de paquet partagé, créé à c:\workspace\packages. Pour ce faire, vous devez ajouter un nœud supplémentaire au NuGet.config dans chaque solution (voir https://docs.nuget.org/consume/nuget-config-file pour plus de détails; je suppose également que vous avoir un dossier NuGet à c:\workspace\Solution A\.nuget):

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

J'ai utilisé un chemin relatif ici, mais vous pouvez également utiliser un chemin absolu, et la documentation indique que vous pouvez également utiliser %HOME%.

Faites cela, puis redémarrez Visual Studio. La prochaine fois que vous ouvrirez le gestionnaire de paquets, il vous demandera si vous souhaitez restaurer les paquets manquants. Si vous cliquez sur Oui, les nouveaux emplacements seront placés. La dernière étape consiste à modifier le fichier .csproj et à remplacer toutes les instances de ..\packages par ..\..\packages (ou vous pouvez désinstaller et réinstaller le paquet, mais je trouve que l'édition du fichier .csproj est beaucoup plus rapide).

5
howcheng

Pour restaurer les paquets Nuget, procédez comme suit:

  • Changer le cadre cible dans les propriétés du projet
  • Projet propre
  • Définir le cadre cible précédent
  • Reconstruire le projet

J'espère que cela aidera.

2
B.Kosmowski

Tiré de la question des PO

La réponse de howcheng est généralement correcte avec certaines mises en garde. Après avoir mis en œuvre les modifications suggérées par howcheng, j'ai pu construire toutes mes solutions localement en utilisant un dossier central de «packages» que tous les projets examinent, quelle que soit la solution. Le problème que j’ai rencontré cependant, c’est que, lorsque j’ai vérifié ces modifications dans TFS, ma version de CI a démarré et a échoué!

My CI Build Definition construit à la fois les solutions A et B dans le modèle de processus XAML par défaut, et non dans un fichier .proj. Les erreurs que je voyais semblaient indiquer que la solution A était en train de restaurer ses packages, mais que la solution B ne l’était pas. Si je me suis connecté au serveur de build et que j'ai ouvert la solution B dans VS 2015, tout a bien fonctionné. Après avoir googlé pendant quelques heures, je suis tombé sur ce article qui m’a finalement conduit à ma réponse.

Je développe dans Visual Studio 2015, mais j'utilise TFS 2013 pour le contrôle de code source et les générations. Malgré le fait que Visual Studio 2015 soit installé sur le serveur de génération, MSBuild fait toujours référence à la version de NuGet fournie avec TFS 2013 et NON à la version fournie avec VS 2015. Une fois que j'ai exécuté nuget update -self à partir du répertoire Outils TFS, ma génération a fonctionné correctement. . 

0
Liam