Einchecken von Paketen von NuGet in die Versionskontrolle?

87

Vor NuGet war es allgemein anerkannt, dass alle in einem Projekt verwendeten externen DLLs eingecheckt wurden. Normalerweise in einem Libsoder 3rdPartyVerzeichnis.

Soll ich bei der Arbeit mit NuGet das packagesVerzeichnis einchecken oder kann MSBuild die benötigten Pakete automatisch aus dem Nuget-Feed herunterladen?

version-control  msbuild  nuget 
— Scott Weinstein
quelle
2
Die Antwort darauf ist Ansichtssache. Das Camp "Ausschließen / Nein" behauptet, dass der bereitgestellte Funktionsumfang es während der Entwicklung und Erstellung einfach macht, ihn einfach aus dem Paket-Repository (z. B. nuget.org) abzurufen. Dies kann nur zur Erstellungszeit erfolgen. Das Camp "include / Yes" behauptet, dass der Code ohne die Pakete nicht erstellt werden würde, falls das externe Repository nicht mehr verfügbar sein sollte. Lesen Sie beide Seiten, bevor Sie eine Entscheidung treffen. Siehe auch: softwareengineering.stackexchange.com/questions/301547/…
— CJBS

Antworten:

67

Nein

Da diese Frage gestellt wurde, gibt es jetzt einen einfachen Workflow, um NuGet zu verwenden, ohne Pakete zur Quellcodeverwaltung zu verpflichten

Über Ihre Paketmanager-Konsole müssen Sie die 'NuGetPowerTools' installieren :

Install-Package NuGetPowerTools

Damit Ihre Projekte die Paketwiederherstellung unterstützen können, müssen Sie einen anderen Befehl ausführen:

Enable-PackageRestore

Jetzt können Sie Ihre Codebasis ohne den Paketordner festschreiben. Der vorherige Befehl hat Ihre Projektdateien so geändert, dass fehlende Pakete automatisch heruntergeladen und hinzugefügt werden.

Quelle

Verwenden von NuGet, ohne Pakete für die Quellcodeverwaltung festzulegen

— Edward Wilde
quelle
41
Ab NuGet-1.6 benötigen Sie dazu keine NuGetPowerTools mehr. Klicken Sie einfach mit der rechten Maustaste auf die Lösung im Projektmappen-Explorer und wählen Sie , Enable NuGet Package Restore. Siehe die Dokumente .
— Kaleb Pederson
3
Ja, Sie müssen den .nuget-Ordner und die darunter liegenden Dateien einchecken.
— Abwesenheit
11
@Edward - Warum sollten Sie NuGet-Pakete nicht in die Quellcodeverwaltung einbeziehen, da es sich um Abhängigkeiten handelt? Was in der Quellcodeverwaltung eingecheckt wird, sollte 100% des Codes sein, der für einen Build ausreicht. Wenn NuGet-Pakete nicht berücksichtigt werden, werden externe Abhängigkeiten erstellt, z. Was passiert, wenn sich der Speicherort für das Herunterladen des Pakets ändert oder aus irgendeinem Grund nicht mehr verfügbar ist? Oder eher, wenn sich das Paket, das später erneut heruntergeladen wird und den Build bricht, geringfügig ändert? Das wäre vermieden worden, wenn alles, was zum Erstellen des Projekts benötigt würde, in der Quellcodeverwaltung wäre.
— Howiecamp
5
@ Howiecamp Ich könnte nicht mehr zustimmen. Ich verstehe die Logik nicht. Ich möchte, dass die Quellcodeverwaltung ein vollständig eigenständiges System ist. Vor allem, wenn das Projekt etwas älter ist und eine Weile nicht mehr aufgerufen wird. Ich möchte zurückkommen und es ohne Änderungen funktionieren lassen. Nuget ist eine einzige Fehlerquelle, die ich nicht haben möchte.
— Telavian
2
@Howiecamp Unsere Lösung besteht darin, unseren eigenen Nuget-Server zu hosten - und alle internen wie externen Nuget-Pakete in GIT-LFS zu speichern. Dies beseitigt den einzelnen Fehlerpunkt und hält alles gut unter Versionskontrolle. Aber wir checken immer noch nicht den Paketordner ein - und wir verwenden immer noch die automatische Paketwiederherstellung
— Casper Leon Nielsen
31

Ja. Betrachten Sie das Verzeichnis "packages" als äquivalent zu Ihrem Verzeichnis "libs", das Sie in Ihrer Frage erwähnt haben. Dies ist der Ansatz, den ich persönlich bei meinen OSS-Projekten verfolge.

Wir untersuchen Funktionen, mit denen MSBuild die erforderlichen Pakete automatisch herunterladen kann, die jedoch nicht implementiert wurden (ab NuGet 1.1).

Ich denke, einige Leute haben solche Funktionen möglicherweise bereits selbst implementiert, aber wir planen, diese Funktion hoffentlich in NuGet 1.2 oder 1.3 zu integrieren.

— Gehackt
quelle
10
Ich würde definitiv gerne sehen, dass diese Funktion hinzugefügt wird. Es wäre schön, wenn Pakete nach Bedarf auf einen CI-Server oder einen Entwicklungs-PC heruntergezogen werden könnten, damit Sie das Quellcodeverwaltungs-Repository nicht mit DLLs von Drittanbietern aufblähen können.
— GiddyUpHorsey
2
Wenn der Paketmanager in Visual Studio und das Befehlszeilentool beide "Pakete reparieren" könnten, wäre das fantastisch.
— Shaun Wilson
1
Vielleicht wäre es gut, diese Antwort zu entfernen / zu bearbeiten, jetzt ist sie veraltet
— Lex
3
@ Tim Antwort ist nicht aktuell imho
— Edward Wilde
4
Diese Antwort ist noch aktuell. Betrachten Sie Pakete, die sich nicht im globalen Repository befinden (keine Möglichkeit, sie zu reparieren / herunterzuladen). IMHO ist es eine gute Praxis, Pakete im Versionierungssystem zu speichern.
— Pavel Hodek
6

Trotz aller Antworten hier ist es immer noch eine schreckliche Lösung, nicht alle Ihre Abhängigkeiten unter "irgendeiner Art" Versionskontrolle zu haben.

Für GIT würde dies GIT-LFS bedeuten.

Die jüngste Episode mit NPM zeigt, warum: Wenn das Internet-Repository, von dem Sie abhängen, Pausen hat, nicht verfügbar ist usw., dann sind Sie nicht fertig?

Sie sind nicht mehr in der Lage, Ihre Sachen zu bauen - und daher nicht in der Lage zu liefern.

— Casper Leon Nielsen
quelle
1
Dies ist ein sehr guter Punkt. Können wir uns darauf verlassen, dass unser interner NuGet-Server während des Builds immer verfügbar ist, auch wenn wir ihn haben? Wie oft ändern sich unsere Pakete, sodass wir für jeden Build immer eine neue Kopie benötigen?
— Josh P
npmbrach, weil es keine Pakete auflistete, sondern sie tatsächlich löschte. NuGet macht das nicht; Wenn Sie zu irgendeinem Zeitpunkt nicht auf NuGet zugreifen können, stimmt etwas schrecklich nicht. Ich denke nicht, dass das Speichern eines Craptonne von Abhängigkeiten in Git eine gute Lösung ist: Sperren Sie einfach Ihre Abhängigkeiten auf eine bestimmte Version und haben Sie einen Spiegel zwischen Ihnen und im Internet, wenn dies für Sie wichtig ist.
— Dan Pantry
2
"NuGet macht das nicht". Nun, hudiluhu, Sie haben gerade Versprechen für die Zukunft einer Domain gemacht, die völlig außerhalb Ihrer Kontrolle liegt. In der realen Welt befinden sich Dinge außerhalb Ihres Kontrollbereichs und auch außerhalb Ihres Kontrollbereichs. Dies gilt sowohl für NuGet als auch für Npm. Darüber hinaus ist Ihre Vorstellung von einem "Spiegel" genau das, was ich hier vorschlage, aber in Ihrer Welt wird der "Spiegel" nicht durch irgendeine Art von versioniertem Schema unterstützt. Wieder haben Sie das Problem, das Sie sich vorgenommen haben, nicht gelöst.
— Casper Leon Nielsen
5

Seit ich die Frage gestellt habe, habe ich den folgenden Ansatz gewählt, damit ich nicht im Verzeichnis toplovel Packages einchecken muss .

In einer Datei build.msbuild auf oberster Ebene:

<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>

In jeder project.csproj-Datei

<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>
— Scott Weinstein
quelle
2
Dies funktioniert, aber heutzutage ist es am besten, nur die integrierte Wiederherstellung des Aktivierungspakets zu verwenden
— Scott Weinstein
4

Mir ist klar, dass die Realität anders war, als diese Frage ursprünglich gestellt und beantwortet wurde, aber zum Glück hat sich die Antwort ein wenig geändert. Mit NuGet können jetzt Abhängigkeiten mithilfe eines Pre-Build-Ereignisses über MSBuild heruntergeladen werden. Sie müssen den Paketordner nicht in Ihrem Code-Repository ablegen, alle Abhängigkeiten werden beim Erstellen heruntergeladen und / oder aktualisiert. Es mag eine Problemumgehung sein, aber es sieht anständig genug aus. Weitere Informationen finden Sie im folgenden Blog-Beitrag: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html

— Pawel Krakowiak
quelle
4
Ich war aufgeregt, bis ich mich daran erinnerte, dass der Build-Server dafür auf das NuGet-Repository zugreifen muss, und dies ist nicht der einzige Ort, an dem ich gearbeitet habe, an dem die Build-Server das Internet nicht sehen können. Ich gehe einfach zurück zum Überprüfen des
— Paketbaums
3

Dieser Beitrag ist sehr veraltet. Die Antwort lautet immer noch NEIN, aber die Lösung hat sich geändert. Ab NuGet 2.7+ können Sie die automatische Paketwiederherstellung aktivieren, ohne die Datei NuGet.exe in Ihre Quelle aufzunehmen (dies ist gelinde gesagt unerwünscht). Wenn Sie ein modernes DVCS verwenden, können Sie den Paketordner ignorieren. Wenn Sie spezielle Anpassungen benötigen, können Sie eine Datei nuget.config im Lösungsstamm erstellen.

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

Mit dem neuen csproj-Format können Sie auch die zusätzlichen Dateien nuget.config vermeiden, da diese jetzt integriert sind. Bitte lesen Sie diesen Beitrag, der das besser erklärt:

Sollte der Versionskontrolle ein .nuget-Ordner hinzugefügt werden?

— Jeremy
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.