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 dossier packages n'ait pas besoin d'être inclus dans le référentiel de code source. Bien.
Cependant, cette commande ajoute un nouveau .nuget dossier et il y a un binaire, NuGet.exe. Cela peut également être recréé automatiquement par Visual Studio et il n'est donc pas correct d'ajouter cela 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 packages NuGet au niveau de la solution. Depuis la version 2.7+, il existe une option dans la configuration 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 maintenant utiliser des références de package, réintroduisant ironiquement la dépendance de msbuild pour restaurer les packages, mais maintenant les packages sont un citoyen de première classe de msbuild. Le lien ci-dessus mentionne également le 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 package avec des projets csproj classiques, mais elles ne sont plus rétrocompatibles et il y a eu quelques problèmes avec restauration des sous-dépendances des 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 jeu suivant a la valeur true dans le nuget.targets fichier:
<!-- 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 télécharger automatiquement nuget.exe maintenant.
Selon ce fil , le dossier .nuget doit être contrôlé par la version.
Vous devez valider .nuget\nuget.targets, mais non nuget.exe. Les cibles téléchargeront l'exe s'il n'existe pas, tant que vous changez DownloadNuGetExe en true dans nuget.targets
Bien que je n'aime généralement pas l'idée d'ajouter des exes au contrôle de code source, je suggère que le contrôle de code source contienne 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 doit être sous contrôle de 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 aura été archivé.
Mise à jour: J'ai fait un peu plus de recherche à ce sujet car je n'ai 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.
En outre, vous devez placer dans le contrôle de code source le fichier de commandes requis pour préparer un poste de travail pour commencer à éditer le 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 des packages, nous l'examinons de plus près.
Nous utilisons Subversion pour le contrôle des sources, et mes premières réflexions sont que .nuget devrait être ajouté à notre référentiel, mais ajouté à l'aide de svn: externals afin qu'il pointe vers un seul emplacement.
De cette façon, nous pouvons envoyer automatiquement de nouvelles versions à tous les développeurs et projets. Pour les projets sur les branches de publication, plutôt que HEAD, nous pouvons spécifier la révision de la référence svn: externals si nous voulons laisser nuget seul.
Nous avons beaucoup de projets, donc cela signifie aussi de ne pas dupliquer nuget.exe plusieurs fois dans le référentiel.
Nous avons le nuget.config fichier dans le dossier, car il contient les références à notre serveur Nuget interne, en utilisant la zone Sources de 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.