Archiver des packages depuis NuGet dans le contrôle de version?


87

Avant NuGet, il était communément admis de «meilleure pratique» d'archiver toutes les DLL externes utilisées sur un projet. Généralement dans un répertoire Libsou 3rdParty.

Lorsque je travaille avec NuGet, suis-je censé archiver le packagesrépertoire ou existe-t-il un moyen pour MSBuild de télécharger automatiquement les packages nécessaires à partir du flux nuget?


2
La réponse à cela est une question d'opinion. Le camp "exclude / No" maintient que, puisque l'ensemble de fonctionnalités fourni facilite le développement et la construction pour simplement extraire du dépôt de paquets (par exemple nuget.org), cela peut être fait juste au moment de la construction. Le camp "include / Yes" maintient que le code ne serait pas construit sans les packages si le référentiel externe devenait indisponible. Lisez les deux côtés avant de prendre une décision. Voir aussi: softwareengineering.stackexchange.com/questions/301547/…
CJBS

Réponses:


67

Non

Depuis que cette question a été posée, il existe maintenant un flux de travail facile pour utiliser NuGet sans valider les packages dans le contrôle de code source

À partir de la console de votre gestionnaire de packages, vous devez installer le 'NuGetPowerTools' :

Install-Package NuGetPowerTools

Ensuite, pour permettre à vos projets de prendre en charge la restauration du pack, vous devez exécuter une autre commande:

Enable-PackageRestore

Vous êtes maintenant prêt à valider votre base de code sans le dossier packages. La commande précédente a modifié les fichiers de votre projet afin que, si des packages manquent, ils soient automatiquement téléchargés et ajoutés.

La source

Utiliser NuGet sans valider les packages dans le contrôle de code source


41
À partir de NuGet-1.6, vous n'avez plus besoin de NuGetPowerTools pour ce faire. Il suffit de faire un clic droit sur la solution dans l' Explorateur de solutions et choisissez Enable NuGet Package Restore. Consultez la documentation .
Kaleb Pederson

3
Oui, vous devez archiver le dossier .nuget et les fichiers en dessous.
absynce

11
@Edward - Philosophiquement, pourquoi n'incluriez-vous pas les packages NuGet dans le contrôle de code source étant donné qu'il s'agit de dépendances? Ce qui est archivé dans le contrôle de code source doit représenter 100% du code suffisant pour une construction. En n'incluant pas les packages NuGet, des dépendances externes sont créées, par exemple. Que faire si l'emplacement de téléchargement du package change, ou pour une raison étrange, il n'est plus disponible, etc. Cela aurait été évité si tout le nécessaire pour générer le projet était sous contrôle de code source.
Howiecamp

5
@Howiecamp Je ne pourrais pas être plus d'accord. Je ne comprends pas la logique. Je veux que le contrôle de source soit un système entièrement autonome. Surtout si le projet est quelque peu hérité et n'a pas été consulté pendant un certain temps. Je veux revenir et le faire fonctionner sans modifications. Nuget est un point de défaillance unique que je ne veux pas avoir.
Telavian

2
@Howiecamp Notre solution est d'héberger notre propre serveur nuget - et de mettre tous les paquets nuget, internes comme externes, dans GIT-LFS. Cela supprime le point de défaillance unique et garde tout bien sous contrôle de version. Mais nous ne archivons toujours pas le dossier packages - et nous utilisons toujours la restauration automatique des packages
Casper Leon Nielsen

31

Oui. Considérez que le répertoire "packages" est équivalent à votre répertoire "libs" que vous avez mentionné dans votre question. C'est l'approche que j'adopte personnellement avec mes projets OSS.

Nous étudions des fonctionnalités qui permettraient à MSBuild de télécharger automatiquement les packages nécessaires, mais cela n'a pas été implémenté (à partir de NuGet 1.1).

Je pense que certaines personnes ont peut-être déjà implémenté de telles fonctionnalités par elles-mêmes, mais notre plan est de chercher à intégrer cette fonctionnalité à NuGet 1.2 ou 1.3, espérons-le.


10
J'aimerais vraiment voir cette fonctionnalité ajoutée. Ce serait bien de pouvoir avoir des packages extraits si nécessaire vers un serveur CI ou un PC de développement, afin d'éviter de gonfler le référentiel de contrôle de source avec des DLL tierces.
GiddyUpHorsey

2
Si le gestionnaire de packages de Visual Studio et l'outil de ligne de commande pouvaient tous deux "réparer des packages", ce serait génial.
Shaun Wilson

1
Peut-être qu'il serait bon de supprimer / modifier cette réponse maintenant qu'elle est obsolète
Lex

3
La réponse @Tim n'est pas actuelle à mon humble avis
Edward Wilde

4
Cette réponse est toujours d'actualité. Considérez les paquets qui ne sont pas dans le référentiel global (aucun moyen de les réparer / télécharger). À mon humble avis, il est recommandé de stocker les packages dans le système de gestion des versions.
Pavel Hodek

6

Malgré toutes les réponses ici, c'est toujours une solution horrible de ne pas avoir toutes vos dépendances sous "une sorte" de contrôle de version.

Pour GIT, cela signifierait GIT-LFS.

L'épisode récent avec NPM montre pourquoi: si le référentiel Internet dont vous dépendez tombe en panne, n'est pas disponible, etc., alors vous êtes foutu n'est-ce pas?

Vous n'êtes plus en mesure de créer votre contenu - et donc pas en mesure de livrer.


1
C'est un très bon point. Même si nous avons notre propre serveur NuGet interne, pouvons-nous compter sur lui pour qu'il soit toujours disponible pendant la construction? Aussi, à quelle fréquence nos packages changent-ils dont nous aurions toujours besoin pour obtenir une nouvelle copie pour chaque build?
Josh P

npmcassé car il n'a pas désélectionné les paquets, il les a en fait supprimés. NuGet ne fait pas cela; si à un moment donné vous ne pouvez pas accéder à NuGet, quelque chose ne va vraiment pas. Je ne pense pas que stocker une craptonne de dépendances dans git soit une bonne solution: verrouillez simplement vos dépendances à une version spécifique et ayez un miroir entre vous et sur Internet si cela vous intéresse.
Dan Pantry

2
"NuGet ne fait pas ça". Eh bien, hudiluhu, vous venez de faire des promesses pour l'avenir d'un domaine qui est complètement hors de votre contrôle. Dans le monde réel, les choses sont hors de votre zone de contrôle, eh bien, elles sont hors de votre zone de contrôle. Cela vaut pour NuGet, ainsi que pour Npm. De plus, votre idée d'un «miroir» est exactement ce que je propose ici, mais dans votre monde, le «miroir» n'est soutenu par aucun type de schéma contrôlé par version. Encore une fois, vous n’avez pas résolu le problème auquel vous vous êtes attelé.
Casper Leon Nielsen

5

Depuis que j'ai posé la question, j'ai mis en place l'approche suivante pour ne pas avoir à vérifier dans le répertoire toplovel Packages .

Dans un fichier build.msbuild de niveau supérieur:

<Target Name="NuGet">
    <ItemGroup>
       <NuGetPackage Include="*\packages.config" />
    </ItemGroup>
    <Exec Command='libs\NuGet.exe install "%(NuGetPackage.FullPath)" -o Packages'  />

    <!-- optional for project that has JavaScript content -->
    <CreateItem Include="Packages\*\Content\Scripts\*">
       <Output TaskParameter="Include" ItemName="NuGetJSFiles"/>
    </CreateItem>
    <Copy SourceFiles="@(NuGetJSFiles)" DestinationFolder="MainProj\Scripts\" OverwriteReadOnlyFiles="true" SkipUnchngedFiles="true" />
    <Delete Files="MainProj\Scripts\.gitignore" />
    <WriteLinesToFile File="MainProj\Scripts\.gitignore" Lines="%(NuGetJSFiles.Filename)%(NuGetJSFiles.Extension)" /
    <Delete Files="@(PostNuGetFiles)" />
</Target>

Dans chaque fichier project.csproj

<Target Name="BeforeBuild">
    <Error Condition="!Exists('..\Packages\')" Text="You must run &gt; msbuild build.msbuild to download required NuGet
Packages" />

    <!-- optional for project that has JavaScript content -->
   <ReadLinesFromFile File="Scripts\.gitignore">
     <Output TaskParameter="Lines" ItemName="ReqJSFiles" />
   </ReadLinesFromFile>
   <Message Text="@(ReqJSFiles)" />
   <Error Condition="!Exists('Scripts\%(ReqJSFiles.Identity)')" Text="You must run &gt; msbuild build.msbuild to download required NuGet JS Package - Scripts\%(ReqJSFiles.Identity)" />
 </Target>

2
Cela fonctionne, mais de nos jours, il est préférable d'utiliser simplement la restauration du package d'activation intégrée
Scott Weinstein

4

Je me rends compte que la réalité était différente lorsque cette question a été initialement publiée et répondue, mais heureusement, la réponse a un peu changé. Il est désormais possible d'utiliser NuGet pour télécharger des dépendances via MSBuild à l'aide d'un événement Pre-Build. Vous n'avez pas besoin de mettre le dossier packages dans votre référentiel de code, toutes les dépendances seront téléchargées et / ou mises à jour lors de la construction. C'est peut-être une solution de contournement, mais cela semble assez décent. Consultez l'article de blog suivant pour plus de détails: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html


4
J'étais excité jusqu'à ce que je me souvienne que cela nécessite que le serveur de build accède au référentiel NuGet, et ce n'est pas le seul endroit où j'ai travaillé où les serveurs de build ne peuvent pas voir Internet. Je vais juste revenir à la vérification de l'arborescence des paquets dans ...
piers7


3

Ce message est devenu très obsolète. La réponse est toujours NON, mais la solution a changé. À partir de NuGet 2.7+, vous pouvez activer la restauration automatique des packages sans inclure le fichier NuGet.exe dans votre source (ce n'est pas souhaitable pour le moins) et si vous utilisez un DVCS moderne, vous pouvez ignorer le dossier packages. Si vous avez besoin de personnalisations spéciales, vous pouvez créer un fichier nuget.config dans la racine de la solution.

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

De plus, avec le nouveau format csproj, vous pouvez également éviter les fichiers nuget.config supplémentaires, car ils sont désormais intégrés. Veuillez consulter cet article qui explique mieux cela:

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.