Faut-il inclure le dossier Nuget PACKAGE dans le contrôle de version?

J'aimerais savoir

Dans le projet C # ou VB.NET, nous devons inclure le dossier PACKAGE (dossier du paquet nugget créé à la racine de mon projet contenant les fichiers nupkg et autre contenu) dans notre référentiel de contrôle de source (Git par exemple).

c# version-control git vb.net

— Bastien Vandamme
source

Absolument Oui , car ces fichiers font partie de votre code et votre projet ne pourra pas être construit sans eux.

— Sharky

J'ai posé une question similaire sur SO il y a longtemps. Vous pouvez également y chercher des réponses: stackoverflow.com/questions/1710027/… :)

— cwap 10/02/2017

Je me demande pourquoi personne dans Maven ne demande "Devrions-nous inclure les bibliothèques tierces dans le contrôle de version". Trouvez un contre-argument solide pour NE PAS commettre de bibliothèques, bien que cela ne soit pas très convaincant.

— Hoàng Long

Réponses:

Beaucoup de temps a passé et NuGet a changé, alors voici une nouvelle réponse.

NuGet ne crée plus de dossier de packages dans votre structure source. Au lieu de cela, il existe un répertoire dans votre répertoire utilisateur ( %HOME%\.nuget\packagespour être spécifique) dans lequel tous les packages téléchargés sont téléchargés, et les projets ne font que les référencer.

Donc, la réponse simple de nos jours est non, vous ne devriez pas. Si vous craignez des paquets dont vous avez besoin de disparaître, vous devez créer un miroir NuGet local que vous sauvegardez séparément.

— Sebastian Redl
source

Je suis sur VS2015 (considérez que VS2017 a été publié juste 3 jours avant que vous écriviez cette réponse) et que le dossier du paquet est présent dans la racine de ma solution. Je suis curieux de savoir comment et quand NuGet a changé.

— Teejay

NuGet a changé avec la version 3, qui a été publiée hors du groupe au cours de la période VS2015.

— Sebastian Redl

Je viens de vérifier sur mon ordinateur de travail et les paquets sont ceux que vous avez mentionnés. Mais sur mon ordinateur personnel, ils se trouvent dans le répertoire du projet. Les deux sont sur VS2015 (professional @ work, community @ home) et la version home est une installation très récente ... C'est étrange.

— Teejay

Vient d’installer VS 2017 la semaine dernière, créé un nouveau projet hier et mon projet contient un répertoire de packages.

— Jeremy

Que faites-vous pour CI? le faites-vous Téléchargez tous les paquets de nuget encore et encore? (TBH: Je ne suis moi-même pas très clair de mon opinion)

— Tomer W

Ça dépend.

Consultez la réponse de Bart van Ingen Schenau pour déterminer s'il est possible d'ignorer le packagesdossier.

En gros: oui, NuGet est conçu pour que vous puissiez ignorer le packagesdossier et que NuGet extraira tout ce qui se trouve sur Internet s'il manque.

Mais devriez-vous l'ignorer? Je dis: ça dépend.
OMI c'est une question de "pouvons-nous continuer à travailler au cas où le référentiel de paquets ne serait pas disponible" (que ce soit temporairement ou de façon permanente)

Pour mes projets personnels OSS, le packagesdossier est ignoré dans chacun d’eux.
Lorsque nuget.org est hors ligne, je vais attendre et continuer un autre jour.

Mais c'est quelque chose de différent au travail.
Bien sûr, vous avez probablement toujours les paquets localement sur certaines machines, mais économiser de l’espace en vaut la peine lorsque vos builds se cassent parce que votre serveur de build ne peut pas atteindre nuget.org?

Nous avons décidé que l'espace est bon marché et que nous ne voulons pas de problèmes, c'est pourquoi nous nous sommes engagés packagesà contrôler le code source.

— Christian Specht
source

À quelle fréquence nuget.org est-il indisponible?

— Bartosz

Probablement pas très souvent. Mais j'aurais peut-être dû dire «inaccessible» au lieu de «hors ligne». Il y a quelques années, nous avons eu un incident au travail où une excavatrice a accidentellement coupé le câble Internet de notre immeuble. A pris plus d'une journée à réparer. Si nous avions utilisé nuget.org, nous n'aurions pas pu construire nos projets. (Oui, je sais, de nos jours, NuGet met les paquets en cache localement ... mais pas à l'époque)

— Christian Specht

Je dirai que les temps de construction sont beaucoup plus longs lorsque vous n'archivez pas le dossier packages car il passe la majeure partie du temps à générer les packages lors de la restauration des packages.

— AaronLS

La règle de base pour ce qui entre dans un référentiel de contrôle de code source est que vous stockez ici tout ce qui est lié à un projet pour pouvoir construire, tester, déployer et exécuter le projet et qui ne peut pas être généré à partir d'éléments déjà présents dans le référentiel. .

En d’autres termes, si vous pouvez jeter le dossier PACKAGE et son contenu sans affecter votre capacité à continuer à travailler sur le projet (la construction peut prendre plus de temps, mais vous n’aurez pas à chercher ni installer vous-même), le dossier peut alors être laissé en sécurité hors du référentiel.
Si le dossier contient des packages tiers dont le téléchargement peut prendre beaucoup de temps ou qui pourraient devenir indisponibles, il peut être utile de les ajouter à votre référentiel.

— Bart van Ingen Schenau
source

J'ajoute que vous devez conserver une version de tout code tiers utilisé dans le projet dans le projet en toute sécurité, au cas où le projet tiers serait supprimé, son site hébergé, etc. Un bon endroit pour le faire est dans votre référentiel de contrôle de version . Cela vous donne également la possibilité de revenir à une version précédente de ce code, si nécessaire.

— Bent