La restauration automatique des packages NuGet ne fonctionne pas avec MSBuild

J'essaie de créer une solution avec du packagescontenu manquant (sauf à l' repositories.configintérieur) avec MSBuild 12.0. Je m'attends à ce qu'il restaure automatiquement tous les paquets manquants avant la construction, mais ce n'est pas le cas - MsBuild rapporte des tonnes d'erreurs:

"vous manque une directive using ou une référence d'assemblage?"

NuGet Manager est 2.7 (je vois cela dans Visual Studio 2013 à propos de la boîte). J'ai même essayé de passer le EnableNuGetPackageRestore=trueparamètre - pas de chance. Qu'est-ce que je rate?

MISE À JOUR avec la dernière documentation officielle NuGet à partir de la v3.3.0

Approches de restauration de package

NuGet propose trois approches pour utiliser la restauration de package .

La restauration automatique de packages est l'approche recommandée par l'équipe NuGet pour la restauration de packages dans Visual Studio, et elle a été introduite dans NuGet 2.7. À partir de NuGet 2.7, l'extension NuGet Visual Studio s'intègre aux événements de génération de Visual Studio et restaure les packages manquants au début d'une génération. Cette fonctionnalité est activée par défaut, mais les développeurs peuvent la désactiver s'ils le souhaitent.

Voici comment ça fonctionne:

1. Lors de la génération de projet ou de solution, Visual Studio déclenche un événement indiquant qu'une génération commence dans la solution.
2. NuGet répond à cet événement et recherche les fichiers packages.config inclus dans la solution.
3. Pour chaque fichier packages.config trouvé, ses packages sont énumérés et Vérifié existe dans le dossier packages de la solution.
4. Tous les packages manquants sont téléchargés à partir des sources de package configurées (et activées) de l'utilisateur, en respectant l'ordre des sources de package.
5. Au fur et à mesure que les packages sont téléchargés, ils sont décompressés dans le dossier packages de la solution.

Si vous avez installé Nuget 2.7+; il est important de choisir une méthode pour> gérer la restauration automatique des packages dans Visual Studio.

Deux méthodes sont disponibles:

1. (Nuget 2.7+): Visual Studio -> Outils -> Gestionnaire de package -> Paramètres du gestionnaire de package -> Activer la restauration automatique de package
2. (Nuget 2.6 et ci-dessous) Faites un clic droit sur une solution et cliquez sur "Activer la restauration de package pour cette solution".

La restauration de package en ligne de commande est requise lors de la création d'une solution à partir de la ligne de commande; il a été introduit dans les premières versions de NuGet, mais a été amélioré dans NuGet 2.7.

nuget.exe restore contoso.sln

L' approche de restauration de package intégrée à MSBuild est l'implémentation de restauration de package d'origine et bien qu'elle continue de fonctionner dans de nombreux scénarios, elle ne couvre pas l'ensemble complet des scénarios traités par les deux autres approches.

Si vous utilisez Visual Studio 2017 ou version ultérieure, livré avec MSBuild 15 ou version ultérieure, et que vos fichiers .csproj sont au nouveau PackageReferenceformat , la méthode la plus simple consiste à utiliser la nouvelle Restorecible MSBuild .

Personne n'a en fait répondu à la question initiale, qui est «comment faire restaurer automatiquement les packages NuGet lors de la création à partir de la ligne de commande avec MSBuild?» La réponse est: à moins que vous n'utilisiez l'option «Activer la restauration du package NuGet» (qui est désormais obsolète selon cette référence ), vous ne pouvez pas (mais voir ci-dessous). Si vous essayez de faire par exemple des builds automatisés sur un serveur CI, cela craint.

Cependant, il existe un moyen légèrement détourné pour obtenir le comportement souhaité:

1. Téléchargez le dernier exécutable NuGet à partir de https://dist.nuget.org/win-x86-commandline/latest/nuget.exe et placez-le quelque part dans votre PATH. (Vous pouvez le faire en tant qu'étape de pré-construction.)
2. Exécuter nuget restorequi téléchargera automatiquement tous les packages manquants.
3. Exécutez msbuildpour créer votre solution.

Mis à part: bien que la méthode nouvelle et recommandée pour effectuer la restauration automatique des packages implique moins d'encombrement dans votre contrôle de version, elle rend également la restauration de packages en ligne de commande impossible à moins que vous ne passiez par le cercle supplémentaire du téléchargement et de l'exécution nuget.exe. Le progrès?

La restauration automatique des packages de Nuget est une fonctionnalité de Visual Studio (à partir de 2013), et non de MSBuild. Vous devrez exécuter nuget.exe restoresi vous souhaitez restaurer des packages à partir de la ligne de commande.

Vous pouvez également utiliser la fonctionnalité Activer la restauration de packages Nuget, mais cela n'est plus recommandé par les utilisateurs de Nuget, car elle apporte des modifications intrusives aux fichiers de projet et peut causer des problèmes si vous générez ces projets dans une autre solution.

Il m'a fallu un certain temps pour comprendre l'image dans son ensemble et j'aimerais partager ici.

Visual Studio a deux approches pour utiliser la restauration de package: la restauration automatique de package et la restauration de package intégrée à MSBuild. La 'Restauration de package intégrée à MSBuild' restaure les packages PENDANT le processus de construction, ce qui peut entraîner des problèmes dans certains scénarios. La «restauration automatique des packages» est l'approche recommandée par l'équipe NuGet.

Il existe plusieurs étapes pour faire fonctionner la `` restauration automatique des packages '':

1. Dans Visual Studio, Outils -> Extensions et mises à jour, mettez à niveau NuGet s'il existe une version plus récente (version 2.7 ou ultérieure)

2. Si vous utilisez TFS, dans le dossier .nuget de votre solution, supprimez les fichiers NuGet.exe et NuGet.targes. Puis modifiez NuGet.Config pour ne pas archiver les packages NuGet:

   <configuration>  
     <solution>  
       <add key="disableSourceControlIntegration" value="true" />  
     </solution>  
   </configuration> 

   Si vous avez déjà archivé le dossier packages de la solution dans TFS, supprimez le dossier et vérifiez la suppression de la suppression du dossier package.

   Si vous n'utilisez pas TFS, supprimez le dossier .nuget.

3. Dans chaque fichier projet (.csproj ou .vbproj) de votre solution, supprimez la ligne qui fait référence au fichier NuGet.targets. La référence ressemble à ceci:

   <Import Project="$(SolutionDir)\.nuget\NuGet.targets" Condition="Exists('$(SolutionDir)\.nuget\NuGet.targets')" />

   Supprimez cette ligne dans chaque fichier de projet de votre solution.

4. Dans le menu Visual Studio, soit via

   Outils -> Options -> Gestionnaire de package -> Général ou Outils -> Gestionnaire de package NuGet -> Paramètres du gestionnaire de package

   veuillez activer les deux options suivantes 1) 'Autoriser NuGet à télécharger les packages manquants' 2) 'Rechercher automatiquement les packages manquants lors de la génération dans Visual Studio'

5. Testez la configuration de la restauration de votre package en suivant les étapes suivantes

   • Enregistrez votre solution et fermez Visual Studio
   • Supprimer le dossier packages de votre solution
   • Démarrez Visual Studio, ouvrez votre solution et reconstruisez-la.

MSBuild 15 a une option / t: restore qui fait cela. il est livré avec Visual Studio 2017.

Si vous souhaitez utiliser ceci, vous devez également utiliser le nouveau PackageReference , ce qui signifie remplacer le packages.configfichier par des éléments comme celui-ci (faites ceci dans * .csproj):

<ItemGroup>
  <!-- ... -->
  <PackageReference Include="Contoso.Utility.UsefulStuff" Version="3.6.0" />
  <!-- ... -->
</ItemGroup>

Il existe une migration automatisée vers ce format si vous cliquez avec le bouton droit sur `` Références '' (cela peut ne pas s'afficher si vous venez d'ouvrir Visual Studio, reconstruisez ou ouvrez la fenêtre `` Gérer les packages NuGet pour la solution '' et elle commencera à apparaître).

Ian Kemp a la réponse (ayez quelques points d'ailleurs ..), c'est simplement ajouter de la viande à l'une de ses étapes.

La raison pour laquelle je me suis retrouvé ici était que les machines de développement se construisaient bien, mais le serveur de compilation ne supprimait tout simplement pas les paquets requis (dossier de paquets vide) et donc la construction échouait. Cependant, la connexion au serveur de build et la création manuelle de la solution ont fonctionné.

Pour effectuer la deuxième des étapes en 3 points d' Ians (exécution de la restauration de nuget ), vous pouvez créer une cible MSBuild exécutant la commande exec pour exécuter la commande de restauration de nuget, comme ci-dessous (dans ce cas, nuget.exe se trouve dans le dossier .nuget, plutôt que sur le chemin), qui peut ensuite être exécuté dans une étape de build TeamCity (autre CI disponible ...) immédiatement avant de construire la solution

<Target Name="BeforeBuild">
  <Exec Command="..\.nuget\nuget restore ..\MySolution.sln"/>
</Target>

Pour mémoire, j'avais déjà essayé le type de coureur "nuget installer" mais cette étape était suspendue aux projets Web (fonctionnait pour les projets DLL et Windows)

Notez que si vous utilisez TeamCity comme serveur de génération, vous obtenez une étape «NuGet Installer» que vous pouvez utiliser pour restaurer tous les packages avant l'étape de génération.

Il existe un fichier packages.config avec le projet, il contient les détails du package.

Il existe également un dossier .nuget qui contient NuGet.exe et NuGet.targets . si l'un des fichiers est manquant, il ne restaurera pas le package manquant et provoquera "vous manque une directive using ou une référence d'assembly?" Erreur

Parfois, cela se produit lorsque vous avez le dossier du package que vous essayez de restaurer dans le dossier "packages" (c'est-à-dire "Packages / EntityFramework.6.0.0 /" ) mais que les "DLL" ne sont pas à l'intérieur (la plupart du contrôle de version les systèmes ignorent automatiquement les fichiers ".dll"). Cela se produit car avant que NuGet tente de restaurer chaque package, il vérifie si les dossiers existent déjà, donc s'il existe, NuGet suppose que la «dll» se trouve à l'intérieur. Donc, si c'est le problème pour vous, supprimez simplement le dossier que NuGet le restaurera correctement.

J'ai eu un problème avec les packages nuget qui n'étaient pas inclus dans une construction nocturne scriptée qui construit le fichier sln à l'aide de devenv.exe.

J'ai suivi les conseils de Microsoft et l'étape clé a été de mettre à jour la configuration NuGet %AppData%/NuGetpour qu'elle contienne:

<configuration>
    <packageRestore>
        <add key="automatic" value="True" />
    </packageRestore>
</configuration>

Dans Visual Studio 2017 - Lorsque vous compilez à l'aide de l'IDE - Il téléchargera tous les packages nuget manquants et les enregistrera dans le dossier "packages".

Mais sur la machine de construction, la compilation a été effectuée à l'aide de msbuild.exe. Dans ce cas, j'ai téléchargé nuget.exe et je suis resté dans le chemin.

Au cours de chaque processus de construction avant d'exécuter msbuild.exe. Il exécutera -> nuget.exe restaure NAME_OF_SLN_File (s'il n'y a qu'un seul fichier .SLN, vous pouvez ignorer ce paramètre)

Vous pouvez aussi utiliser

Update-Package -reinstall

pour restaurer les packages NuGet sur la console de gestion des packages dans Visual Studio.