Vérification dans les paquets de NuGet dans le contrôle de version?

Avant NuGet, il était commun accepté des "meilleures pratiques" pour le check-in externe de tous les Dll utilisées sur un projet. En général dans un Libs ou 3rdParty répertoire.

Lorsque l'on travaille avec NuGet, suis-je censé le check-in le packages répertoire, ou est-il un moyen pour MSBuild pour télécharger automatiquement les paquets nécessaires à partir de la nuget nourrir?

  • La réponse à cette question d'opinion. Les "exclure" ou " Non " camp soutient que, en raison de la condition de la fonctionnalité définir le rend facile au cours du développement et de construire afin de tirer juste à partir du dépôt de paquets (par ex. nuget.org), il peut seulement être fait au moment de la construction. "Include/camp du Oui maintient que le code ne serait pas construire sans les paquets si l'un dépôt externe deviennent indisponibles. Lire des deux côtés avant de prendre une décision. Voir aussi: softwareengineering.stackexchange.com/questions/301547/...
InformationsquelleAutor Scott Weinstein | 2011-02-12
  1. 67

    Pas

    Depuis que cette question a été posée il y a maintenant un flux de travail facile à utiliser NuGet sans commettre des forfaits à la source de contrôle

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

    Install-Package NuGetPowerTools

    Ensuite pour activer vos projets à l'appui de pack de restauration, vous devez exécuter une autre commande:

    Enable-PackageRestore

    Maintenant, vous êtes prêt à s'engager de votre base de code sans le dossier packages. La commande précédente changé les fichiers de votre projet, de sorte que si des paquets sont manquants, ils sont automatiquement téléchargés et ajoutés.

    Source

    À l'aide de NuGet sans commettre des paquets de contrôle de code source

    • Comme de NuGet-1.6, vous n'avez plus besoin NuGetPowerTools pour ce faire. Faites simplement un clic droit sur la Solution dans l'Explorateur de solutions et choisissez l', Enable NuGet Package Restore. Voir la doc.
    • OK, je comprends en suivant ces étapes, je n'ai pas à vérifier dans le packages dossier plus. Quel est le .nuget dossier cela crée? Dois-je vérifier que dans?
    • Oui, vous devez vérifier dans le .nuget dossier et les fichiers d'en-dessous.
    • Philosophiquement, pourquoi ne pas inclure des packages NuGet dans la source de contrôle, étant donné qu'ils sont des dépendances? Ce qui est vérifié dans le contrôle de la source doit être de 100% du code suffisante pour une de construire. En n'incluant pas les packages NuGet il y a des dépendances externes créés, par exemple. que faire si le téléchargement du package de modifications de l'emplacement, ou pour une raison étrange, il n'est plus disponible, etc. Ou, plus probablement, que si il ya une légère modification de l'emballage qui est plus tard re-téléchargé et il se casse la construire? Qui auraient pu être évités si tout ce qui est nécessaire pour construire le projet a été en contrôle de code source.
    • tout à fait d'accord avec vos points. C'est un risque que vous prenez. Toutefois, le remboursement est plus petit, plus rapide référentiels de contrôle de source, sans beaucoup de biens binaires
    • Je ne pouvais pas être plus d'accord. Je ne comprends pas la logique. Je veux contrôle de code source pour être entièrement autonome du système. En particulier si le projet est un peu l'héritage et ne pas accessible pendant un certain temps. Je veux revenir et de le faire travailler sans modifications. Nuget est un point de défaillance unique que je ne veux pas avoir.
    • J'ai aussi ne pouvais pas être plus d'accord. Avoir des dépendances externes afin de construire mon propre code? Il faudrait être fou. Ne peux pas croire que les gens sont en train de pousser comme c'est une bonne idée.
    • la raison en est que DVCS systèmes (ou peut-être juste git) ne peut pas gérer de gros fichiers binaires. docs.nuget.org/consume/package-restore/msbuild-integrated
    • J'ai trop d'accord. La vérification dans tous vos dépendances est une nécessité absolue si vous avez une exigence particulière que vous avez besoin pour être en mesure de tirer une version spécifique de contrôle de la source et être en mesure de construire une application qui se comporte exactement comme la version initialement publié.
    • Je suis aussi avec vous sur ce point. Avoir votre build critique de la dépendance sur un serveur sur internet semble être une mauvaise idée. Vous ne voulez pas être dans une position où vous ne pouvez pas créer une version parce que votre connexion internet est en panne ou votre CI s'appuie commencer à échouer parce que les référentiels de nuget sont hors ligne.
    • Notre solution est d'héberger nos propres nuget serveur et de mettre tous les packages nuget, interne comme externe, dans le dépôt GIT-EPA. Cela supprime le point de défaillance unique et maintient le tout joliment sous contrôle de version. Mais nous n'avons pas encore d'archivage du dossier packages - et nous continuons de l'utiliser automatique de paquet de restauration
    • Grande idée. Il y a évidemment des avantages et des inconvénients, mais je l'aime en général.

    InformationsquelleAutor Edward Wilde
  2. 30

    Oui. Envisager le répertoire "packages" pour être équivalent à celui de votre "libs" répertoire que vous avez mentionné dans votre question. C'est l'approche que j'ai personnellement prendre avec mes projets OSS.

    Nous étudions les caractéristiques qui permettraient de MSBuild pour télécharger automatiquement les paquets nécessaires, mais qui n'a pas été mis en œuvre (comme de NuGet 1.1).

    Je pense que certaines personnes peuvent avoir déjà mis en œuvre ces fonctionnalités sur leur propre, mais notre plan est de chercher à avoir cette fonctionnalité intégrée à NuGet 1.2 ou 1.3, espérons-le.

    • J'avais vraiment envie de voir cette fonctionnalité ajoutée. Il serait agréable d'être en mesure d'avoir des paquets tiré vers le bas que nécessaire pour un serveur CI ou dev PC, de sorte que vous pouvez éviter les ballonnements le référentiel de contrôle source avec des tiers Dll.
    • Dois-je vérifier dans tous les fichiers? Ou est-il suffisant de vérifier dans le dll et l'NuGet config (quelque chose comme ça).
    • Le plus sûr, pour archiver tous les fichiers. Si jamais vous avez besoin de désinstaller le paquet, nous avons besoin de l'emballage d'origine afin que nous puissions déterminer ce qui a changé. Aussi, lorsque nous faisons une mise à jour, c'est l'équivalent de désinstallation suivie par une installation de la version la plus récente.
    • Si le gestionnaire de paquets dans visual studio et l'outil de ligne de commande à la fois pourrait "réparer les Paquets" ce serait génial.
    • Est versioning la nupckg nécessaire? Pourquoi? merci
    • il n'est pas obligatoire, mais nous vous le recommandons pour l'instant, pour toutes les raisons déjà discuté.
    • Peut-être qu'il serait bon de supprimer ou de modifier cette réponse maintenant, il est obsolète
    • Est-ce la réponse toujours d'actualité?
    • la réponse n'est pas courant à mon humble avis
    • Cette réponse EST toujours d'actualité. Examiner les paquets qui ne sont pas dans le référentiel global (pas moyen de réparer/télécharger). À mon humble avis, il est de bonne pratique pour stocker les paquets dans le système de gestion de versions.
    • Tout ce qui est essentiel pour créer votre application dans le contrôle de source sonne comme une bonne idée pour moi. Les paquets sont exactement les mêmes que les libs, mais ils peuvent espérer être télécharger en ligne. Ils sont toujours à la critique de la dépendance.

    InformationsquelleAutor Haacked
  3. 6

    En dépit de toutes les réponses ici, c'est encore une plaine ole' horrible solution pour ne pas avoir tous vos dépendances, en vertu de "une sorte" de contrôle de version.

    Pour GIT, cela signifierait GIT-EPA.

    Le récent épisode avec NPM montre pourquoi: Si le dépôt internet dont vous dépendez des pauses, ne sont pas disponibles, etc., eh bien alors, vous êtes foutu aint vous?

    Vous n'êtes plus en mesure de construire vos trucs - et, par conséquent, pas en mesure de fournir.

    • C'est un TRÈS bon point. Même si nous avons notre propre serveur NuGet, pouvons-nous compter sur elle pour être toujours disponibles lors de la compilation? Aussi, combien de fois nos forfaits de changement que nous avons toujours besoin d'obtenir une nouvelle copie de chaque version?
    • npm cassé parce qu'il n'a pas unlist paquets, il en fait supprimés. NuGet ne pas le faire; si vous ne pouvez pas accéder NuGet quelque chose est terriblement erronée. Je ne pense pas que le stockage d'un craptonne de dépendances dans git est une bonne solution: il suffit de verrouiller vos dépendances à une version spécifique et un miroir entre vous et sur internet, si ce qui compte pour vous.
    • "NuGet ne pas le faire". Bien hudiluhu vous avez juste fait des promesses pour l'avenir d'un domaine qui est totalement hors de votre contrôle. Dans le monde réel des choses hors de votre zone de contrôle, bien qu'ils sont hors de votre zone de contrôle. Il en va ainsi pour NuGet, ainsi que Mnp. En outre, votre idée d'un "miroir", c'est exactement ce que je propose ici, mais dans votre monde, "le miroir" n'est pas étayée par aucune sorte de version contrôlée régime. Encore une fois, vous n'avez pas résolu le problème que vous vous êtes fixé.
    InformationsquelleAutor Casper Leon Nielsen
  4. 5

    Depuis posant la question, j'ai mis dans l'approche suivante de sorte que je n'ai pas à vérifier dans le toplovel Paquets répertoire.

    Dans un toplevel construire.msbuild fichier:

    <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 projet.fichier 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>
    • Cela fonctionne, mais ces jours-ci, donc préférable d'utiliser le haut-activer le package de restauration
    InformationsquelleAutor Scott Weinstein
  5. 4

    Je me rends compte de la réalité a été différente lorsque cette question a été posté et répondu, mais heureusement, la réponse a un peu changé. Il est maintenant possible d'utiliser NuGet pour télécharger les dépendances via MSBuild à l'aide d'un Pré-événement de construction. 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és et/ou mis à jour sur construire. Il peut une solution de contournement, mais il semble assez décent. Consultez le blog suivant pour plus de détails: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

    • J'ai été très heureux jusqu'à ce que je rappeler que ceci nécessite que le serveur de build pour accéder au référentiel de NuGet, et ce n'est pas le seul endroit où j'ai travaillé à l'endroit où les serveurs de build ne pouvez pas voir le internet. Je vais juste revenir à la vérification des paquets arbre...
    InformationsquelleAutor Pawel Krakowiak
  6. 3

    De 09/20/13, il ya quelque chose appelé "Nuget Restaurer". En fait vous n'avez pas à vérifier dans le dossier du package si vous le souhaitez. (Surtout si vous utilisez des DVCS)

    Découvrez ce: à l'Aide de NuGet Sans la validation des paquets de contrôle de code source
    http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages

    InformationsquelleAutor Matt W
  7. 3

    Ce post est devenu très désuet. La réponse est encore NON, mais la solution a changé.
    Comme de NuGet 2.7+, vous pouvez activer la commande automatique de paquet de la restauration sans y compris le NuGet.exe fichier dans votre code source (ce n'est pas souhaitable pour dire le moins) et si vous utiliser tous les DVCS vous pouvez ignorer le dossier packages. Si vous avez besoin de toute spéciale les personnalisations que vous pouvez créer un nuget.fichier de config à la solution de la racine.

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

    Aussi, avec la nouvelle csproj format que vous pouvez éviter les extra nuget.les fichiers de configuration ainsi puisque c'est intégré maintenant. S'il vous plaît consulter cet article qui explique que mieux:

    Le devrait .nuget dossier sera ajouté à la version de contrôle?

    InformationsquelleAutor Jeremy