2017-08-26 2 views
8

Ich habe ein asp.net Kernprojekt, das ordnungsgemäß mit VS erstellt, aber nicht unter Msbuild erstellt.Dotnet Restore vs Nuget Restore mit Teamcity

Es findet nicht alle gängigen Libs (System, usw.)

ich Teamcity und ein Teil des Build-Prozesses verwendet, wird ein nuget wiederherzustellen.

Ich habe versucht, die gleichen Schritte wie Teamcity, aber manuell mit Msbuild zu tun, und es ist fehlgeschlagen, nicht die libs zu finden.

Ich habe einen Dotnet Restore-Schritt hinzugefügt und dann hat es funktioniert.

Also, was ist der Unterschied zwischen einem nuget wiederherzustellen und ein Dotnet wiederherstellen?

+0

ich vermute, da Dotnet gearbeitet restore aber nuget tat es nicht, dass nuget auf Team-Stadt ist eine ältere Version, die nicht der Fall ist PackageReferences verstehen. NuGet müsste mindestens Version 4.0 sein. –

+0

Wir haben das gleiche Problem, wo Dotnet-Wiederherstellung funktioniert, aber Nuget-Wiederherstellung nicht. Und für uns passiert das sowohl auf TeamCity als auch lokal. – r12

Antwort

13

Sowohl nuget restore als auch dotnet restore sind ungefähr gleich: Sie führen einen Nuget-Restore-Vorgang durch.

Der einzige Unterschied: dotnet restore ist ein Convenience-Wrapper zum Aufrufen von dotnet msbuild /t:Restore, die eine Msbuild-integrierte Wiederherstellung aufruft. Dies funktioniert nur bei MSbuild-Distributionen, die NuGet enthalten, wie VS 2017 (vollständige VS, Build-Tools) oder Mono 5.2+ (=>msbuild /t:Restore) und dem .NET Core Sdk, der diesen Komfortbefehl bietet.

Im Moment gibt es zwei Möglichkeiten, wie NuGet Pakete können in Projekten verwendet werden (3s tatsächlich aber sie ignoriert project.json auf UWP für den Moment):

  • packages.config: Die „klassische“ Art und Weise der Referenzierung NuGet-Pakete. Dies setzt voraus, dass NuGet ein separates Tool ist und msbuild nichts über NuGet weiß. Ein NuGet-Client wie nuget.exe oder VS-integrierte Werkzeuge sieht die Datei packages.config und lädt die referenzierten Pakete in einen lokalen Ordner bei der Wiederherstellung. Bei einer Paketinstallation wird das Projekt so geändert, dass Objekte aus diesem lokalen Ordner referenziert werden. Eine Wiederherstellung für ein packages.config Projekt lädt nur die Dateien.
  • PackageReference: Das Projekt enthält MSBuild-Elemente, die auf ein NuGet-Paket verweisen. Im Gegensatz zu packages.config werden nur die direkten Abhängigkeiten aufgeführt und die Projektdatei verweist nicht direkt auf Assets (DLL-Dateien, Inhaltsdateien) aus Paketen. Bei der Wiederherstellung ermittelt NuGet das Abhängigkeitsdiagramm durch Auswertung der direkten und transitiven Abhängigkeiten, stellt sicher, dass alle Pakete in den globalen Paketcache des Benutzers heruntergeladen werden (nicht lösungslokal, so dass es nur einmal heruntergeladen wird) und schreibt eine Datei in den Ordner obj Diese enthält eine Liste aller Pakete und Assets, die das Projekt verwendet, sowie zusätzliche msbuild-Ziele, wenn ein Paket Build-Logik enthält, die einem Projekt hinzugefügt werden muss.Daher kann eine Nuget-Wiederherstellung Pakete herunterladen, wenn sie nicht bereits im globalen Cache vorhanden sind, und diese Assets-Datei erstellen. Zusätzlich zu den Paketverweisen kann das Projekt auch auf CLI-Tools verweisen, bei denen es sich um NuGet-Pakete mit zusätzlichen Befehlen handelt, die für das Verzeichnis dotnet im Projektverzeichnis verfügbar sind.

Die msbuild integrierte Wiederherstellung funktioniert nur für PackageReference Typ Projekte (.NET Standard .NET-Core standardmäßig aber sind Opt-in für alle .NET-Projekt) und nicht für packages.config Projekte. Wenn Sie eine neue Version von nuget.exe (z. B. 4.3.0) verwenden, können beide Projekttypen wiederhergestellt werden.

Ihr Fehler über fehlende Typen ist ein bisschen interessanter: Die "Referenz-Assemblies" (Bibliotheken, die als Eingabe an den Compiler übergeben werden) sind nicht auf dem System installiert, sondern kommen über NuGet-Pakete. Solange die NuGet-Pakete nicht im globalen Paket-Cache vorhanden sind oder die obj/project.assets.json-Datei nicht von einer Wiederherstellungsoperation generiert wurde, stehen dem Compiler keine grundlegenden Typen wie System.Object zur Verfügung.

+0

Dies verdeutlicht die Dinge sehr! Danke! Gibt es in diesem Licht einen Grund, den Mechanismus package.config zu verwenden? – Thomas

+1

Das 'content'-Feature (Kopieren von Dateien in die Quelle des konsumierenden Projekts) wurde entfernt und durch eine 'contentFiles'-Funktion ersetzt. Außerdem funktioniert 'PackageReference' nur in VS 2017+ (NuGet 4. *, MSBuild 15+) –

-1

Die Nuget-Wiederherstellung stellt sicher, dass alle Ihre Nuget-Abhängigkeiten heruntergeladen und für Ihr Projekt verfügbar sind. Während dotnet restore eine vollständige Wiederherstellung aller einzelnen Abhängigkeiten sowie Referenzen und projektspezifischer Werkzeuge ist. Das heißt, wenn Sie nuget restore ausführen, sind Sie nur NUget-Pakete wiederherstellen.

Nach docs.microsoft.com: Dotnet Restore

Das Dotnet Befehl restore verwendet NuGet Abhängigkeiten sowie projektspezifische Tools wiederherstellen, die in der Projektdatei angegeben sind ...

+0

'nuget.exe restore' macht dasselbe wie' dotnet restore' für 'PackageReference' Projekte. –

0

Ich hatte ähnliche Probleme mit einem .net-Core 2-Projekt, das auf meiner Workstation gut funktionieren würde - sowohl in Visual Studio 2017 als auch in Msbuild - aber nicht in TeamCity. Die Fehlernachricht ist:

C:\Program Files\dotnet\sdk\2.1.4\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(327, 5): 
Assets file 'D:\TeamCity\buildAgent\work\596486b1d4e7a8e7\Source\Integrations\SomeAPI\obj\project.assets.json' not found. 
Run a NuGet package restore to generate this file. 

In meiner Build-Konfiguration hatte ich bereits ein NuGet Schritt vor der Installation des Build-Schritt:

  • NuGetversion: 3.4.4
  • Wiederherstellungsmodus: Installieren

Es stellte sich heraus, ich musste verwenden:

  • NuGet Version: 4.0.0 oder höher
  • Wiederherstellungsmodus: Wiederherstellung (Benötigt NuGet 2.7+)
Verwandte Themen