Le dossier .nuget doit-il être ajouté au contrôle de version?

Avec les versions plus récentes de NuGet, il est possible de configurer un projet pour restaurer automatiquement les packages NuGet afin que le packagesdossier n'ait pas besoin d'être inclus dans le référentiel de code source. Bien.

Cependant, cette commande ajoute un nouveau .nugetdossier et il existe un binaire, NuGet.exe. Cela peut également être recréé automatiquement par Visual Studio et il n'est donc pas correct de l'ajouter au contrôle de version. Cependant, sans ce dossier, Visual Studio ne chargera même pas la solution correctement.

Comment gérez-vous cela? Ajouter .nuget au contrôle de code source? Exécuter un script de ligne de commande avant d'ouvrir la solution?

Ce message est ancien, vous ne devriez plus utiliser la restauration de package NuGet au niveau de la solution. À partir de la version 2.7+, il existe une option dans le programme d'installation de NuGet pour restaurer automatiquement les packages lors de la construction. Ainsi, le dossier .nuget peut être supprimé et l'option supprimée de vos projets.

http://docs.nuget.org/docs/reference/package-restore

MISE À JOUR: Avec la sortie de NuGet 4.x et .NET Standard 2.0, lorsque vous utilisez le nouveau format csproj, vous pouvez désormais utiliser des références de package, réintroduisant ironiquement la dépendance sur msbuild pour restaurer des packages, mais maintenant les packages sont un citoyen de première classe de msbuild . Le lien ci-dessus fait également mention du PackageReference, mais l'annonce suivante le détaille mieux:

https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html

Et l'annonce NuGet 4.x RTM, qui ironiquement n'est pas aussi utile:

https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html

MISE À JOUR 2: Apparemment, avec VS2017, vous pouvez même utiliser des références de packages avec des projets csproj classiques, mais ils ne sont plus rétrocompatibles et il y a eu des problèmes avec la restauration des sous-dépendances de packages. Je suis sûr que tout sera résolu.

La réponse de @Richard Szalay est juste - vous n'avez pas besoin de valider nuget.exe. Si, pour certaines raisons, Visual Studio ne télécharge pas automatiquement le nuget.exe, assurez-vous que le paramètre suivant est défini sur true dans le nuget.targetsfichier:

<!-- Download NuGet.exe if it does not already exist --> 
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>

Fermez la solution VS, rouvrez-la et générez-la. Visual Studio devrait maintenant télécharger nuget.exe automatiquement.

Selon ce fil , le dossier .nuget doit être contrôlé par version.

Vous devez vous engager .nuget\nuget.targets, mais pas nuget.exe. Les cibles télécharger l'exe si elle n'existe pas, aussi longtemps que vous changez DownloadNuGetExed' trueen nuget.targets

Bien que je n'aime généralement pas l'idée d'ajouter des exe au contrôle de source, je suggérerais que le contrôle de source devrait contenir tout ce qui est nécessaire pour ouvrir, construire et exécuter le projet.

Dans ce cas, il semble que le dossier .nuget soit une dépendance requise. Par conséquent, il devrait être sous le contrôle de la source.

La seule question qui reste, que vous devez rechercher, est de savoir comment NuGet va réagir si ce dossier est marqué en lecture seule, ce que TFS fera une fois qu'il a été archivé.

Mise à jour: j'ai fait un peu plus de recherches à ce sujet car je n'avais jamais utilisé NuGet auparavant. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

Je dirais que ce que vous voulez probablement faire est de faire de NuGet une exigence qui doit être installée sur chaque poste de travail de développeur.

De plus, vous devez placer dans le contrôle de code source le fichier de commandes requis pour obtenir un poste de travail prêt à commencer l'édition du projet. Le fichier batch va exécuter les commandes nécessaires pour obtenir et installer les packages de dépendances.

Au-delà de cela, je dirais que vous voudrez peut-être contacter NuGet directement pour leur demander comment, exactement, cela est censé fonctionner.

Maintenant que nuget prend en charge la restauration de paquets, nous l'examinons de plus près.

Nous utilisons Subversion pour le contrôle de code source, et mes premières réflexions sont que cela .nugetdevrait être ajouté à notre référentiel, mais ajouté en utilisant svn: externals afin qu'il pointe vers un seul emplacement.

De cette façon, nous pouvons automatiquement proposer de nouvelles versions à tous les développeurs et projets. Pour les projets sur les branches de version, plutôt que sur HEAD, nous pouvons spécifier la révision de svn: externals reference si nous voulons laisser nuget seul.

Nous avons beaucoup de projets, donc cela signifie également ne pas dupliquer nuget.exeplusieurs fois dans le repo.

Nous avons le nuget.configfichier dans le dossier, car il contient les références à notre serveur Nuget interne, en utilisant la zone Sources du package: https://docs.nuget.org/consume/nuget-config-settings

En dehors de cette raison, vous devez laisser Visual Studio gérer le téléchargement des packages.