Auf Englisch lesen

Freigeben über


Versionshinweise zu NuGet 2.5

Versionshinweise zur NuGet 2.2.1-Version von | NuGet 2.6

NuGet 2.5 wurde am 25. April 2013 veröffentlicht. Diese Version war so groß, dass wir uns gezwungen fühlten, die Versionen 2.3 und 2.4 zu überspringen! Bis heute ist dies die größte Veröffentlichung, die wir für NuGet hatten, mit über [160 work items](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.5&status=all) in der Veröffentlichung.

Danksagung

Wir bedanken uns bei den folgenden externen Mitwirkenden für ihre bedeutende Beiträge für NuGet 2.5:

  1. [Daniel Plaisted](https://www.codeplex.com/site/users/view/dsplaisted) (@dsplaisted)
    • [#2847](https://nuget.codeplex.com/workitem/2847) – Hinzufügen von MonoAndroid, MonoTouch und MonoMac zur Liste der bekannten Zielframework-IDs.
  2. [Andres G. Aragoneses](https://www.codeplex.com/site/users/view/knocte) (@knocte)
    • [#2865](https://nuget.codeplex.com/workitem/2865) – Korrigieren der Rechtschreibung für ein Betriebssystem mit Beachtung der NuGet.targets Groß-/Kleinschreibung
  3. [David Fowler](https://www.codeplex.com/site/users/view/dfowler) (@davidfowl)
    • Erstellen des Lösungsbuild auf Mono.
  4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
    • Beheben der Komponententests, die bei Mono fehlschlagen.
  5. [Olivier Dagenais](https://www.codeplex.com/site/users/view/OliIsCool) (@OliIsCool)
    • [#2920](https://nuget.codeplex.com/workitem/2920) – Der Befehl nuget.exe pack überträgt keine Eigenschaften an MSBuild
  6. [Miroslav Bajtos](https://www.codeplex.com/site/users/view/MiroslavBajtos) (@bajtos)
    • [#1511](https://nuget.codeplex.com/workitem/1511) – Geänderter XML-Verarbeitungscode zum Beibehalten der Formatierung.
  7. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • Erkannte Wörter zum Benutzerwörterbuch hinzugefügt, damit build.cmd erfolgreich ausgeführt werden kann.
  8. [Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
    • Beheben der Komponententests, wenn sie in lokalisiertem VS ausgeführt werden.
  9. [Gareth Evans](https://www.codeplex.com/site/users/view/garethevans)
    • Extrahierte Schnittstelle aus PackageService
  10. [Maxime Brugidou](https://www.codeplex.com/site/users/view/brugidou) (@brugidou)
    • [#936](https://nuget.codeplex.com/workitem/936) – Behandeln von Projektabhängigkeiten beim Packen
  11. [Xavier Decoster](https://www.codeplex.com/site/users/view/XavierDecoster) (@XavierDecoster)
    • [#2991](https://nuget.codeplex.com/workitem/2991), [#3164](https://nuget.codeplex.com/workitem/3164) – Unterstützung des Klartextkennworts beim Speichern von Paketquellanmeldeinformationen in nuget.cofig-Dateien.
  12. [James Manning](http://www.codeplex.com/site/users/view/jmanning) (@manningj)
    • [#3190](http://nuget.codeplex.com/workitem/3190), [#3191](https://nuget.codeplex.com/workitem/3191) – Beschreibung der Paket-abrufen-Hilfe beheben

Wir schätzen auch die folgenden Einzelpersonen für die Suche nach Fehlern mit NuGet 2.5 Beta/RC, die vor der endgültigen Version genehmigt und behoben wurden:

  1. [Tony Wall](https://www.codeplex.com/site/users/view/CodeChief) (@CodeChief)
    • [#3200](https://nuget.codeplex.com/workitem/3200) – MSTest funktioniert nicht mit den neuesten NuGet 2.4 und 2.5 Builds

Wichtige Features in der Version

Zulassen, dass Benutzer bereits vorhandene Inhaltsdateien überschreiben

Eines der am häufigsten angeforderten Features aller Zeiten war die Möglichkeit, Inhaltsdateien zu überschreiben, die bereits auf dem Datenträger vorhanden sind, wenn sie in einem NuGet-Paket enthalten sind. Ab NuGet 2.5 werden diese Konflikte identifiziert, und Sie werden aufgefordert, die Dateien zu überschreiben, während diese Dateien zuvor immer übersprungen wurden.

Overwrite content files

nuget.exe update und Paket-installieren haben jetzt beide eine neue Option -FileConflictAction, um einige Standardeinstellungen für Befehlszeilenszenarien festzulegen.

Legen Sie eine Standardaktion fest, wenn eine Datei aus einem Paket bereits im Zielprojekt vorhanden ist. Legen Sie „Überschreiben“ fest, um Dateien immer zu überschreiben. Legen Sie „Ignorieren“ fest, um Dateien zu überspringen. Wird dies nicht angegeben, wird nach jeder widersprüchlichen Datei gefragt.

Automatisches Importieren von MSBuild-Zielen und Props-Dateien

Auf der obersten Ebene des NuGet-Pakets wurde ein neuer herkömmlicher Ordner erstellt. Als Peer zu \lib, \contentund \tools, können Sie jetzt einen \build Ordner in Ihr Paket einschließen. Unter diesem Ordner können Sie zwei Dateien mit festen Namen {packageid}.targets oder {packageid}.props ablegen. Diese beiden Dateien können direkt unter build oder unter frameworkspezifischen Ordnern wie die anderen Ordner stehen. Die Regel für die Auswahl des am besten passenden Rahmenordners ist genau dieselbe wie in diesen.

Wenn NuGet ein Paket mit \build-Dateien installiert, wird ein MSBuild <Import> Element in die Projektdatei eingefügt, das auf die .targets und .props Dateien verweist. Die .props Datei wird oben hinzugefügt, während die .targets Datei unten hinzugefügt wird.

Angeben unterschiedlicher Verweise pro Plattform mithilfe von <References/> Element

Vor 2.5 kann der Benutzer in .nuspec der Datei nur die Referenzdateien angeben, die für alle Frameworks hinzugefügt werden sollen. Mit diesem neuen Feature in 2.5 kann der Benutzer das <reference/> Element für jede unterstützte Plattform erstellen, z. B.:

<references>
    <group targetFramework="net45">
        <reference file="a.dll" />
    </group>
    <group targetFramework="netcore45">
        <reference file="b.dll" />
    </group>
    <group>
        <reference file="c.dll" />
    </group>
</references>

Hier ist der Fluss zum Hinzufügen von NuGet-Verweisen auf Projekte basierend auf der .nuspec Datei:

  1. Suchen Sie den Ordner, der lib für das Zielframework geeignet ist, und rufen Sie die Liste der Assemblys aus diesem Ordner ab.
  2. Suchen Sie separat nach der Referenzgruppe, die für das Zielframework geeignet ist, und rufen Sie die Liste der Assemblys aus dieser Gruppe ab. Referenzgruppe ohne angegebenes Zielframework ist die Fallbackgruppe.
  3. Suchen Sie die Schnittmenge der beiden Listen, und verwenden Sie diese als die hinzuzufügenden Verweise.

Diese neue Funktion ermöglicht es Paketautoren, die Funktion Referenzen zu verwenden, um Teilmengen von Assemblies auf verschiedene Frameworks anzuwenden, wenn sie sonst doppelte Assembly in mehreren lib Ordnern mitführen müssten.

Hinweis: Sie müssen derzeit nuget.exe pack verwenden, um dieses Feature zu verwenden; NuGet-Paket-Explorer unterstützt es noch nicht.

Schaltfläche „Alle aktualisieren“, um alle Pakete gleichzeitig zu aktualisieren

Viele von Ihnen kennen das PowerShell-Cmdlet „Update-Package“, um alle Ihre Pakete zu aktualisieren; jetzt gibt es eine einfache Möglichkeit, dies auch über die Benutzeroberfläche zu tun.

So testen Sie diese Funktion:

  1. Erstellen einer neuen ASP.NET MVC-Anwendung
  2. Starten Sie den Dialog NuGet-Pakete verwalten.
  3. Wählen Sie „Aktualisierungen“ aus.
  4. Klicken Sie auf die Schaltfläche „Alles aktualisieren“.

Update All button in the dialog

Verbesserte Projektreferenzunterstützung für nuget.exe Paket

Jetzt verarbeitet der Packbefehl nuget.exe referenzierte Projekte mit den folgenden Regeln:

  1. Wenn das referenzierte Projekt eine entsprechende .nuspec Datei hat, z. B. eine proj1.nuspec Datei im gleichen Ordner wie proj1.csproj, dann wird dieses Projekt als Abhängigkeit zum Paket hinzugefügt, wobei die aus der .nuspec Datei gelesene ID und Version verwendet wird.
  2. Andernfalls werden die Dateien des referenzierten Projekts in das Paket gebündelt. Anschließend werden Projekte, auf die von diesem Projekt verwiesen wird, rekursiv mit den gleichen Regeln verarbeitet.
  3. Alle DLL, .pdb und .exe Dateien werden hinzugefügt.
  4. Alle anderen Inhaltsdateien werden hinzugefügt.
  5. Alle Abhängigkeiten werden zusammengeführt.

Dadurch kann ein referenziertes Projekt als Abhängigkeit behandelt werden, wenn eine .nuspec Datei vorhanden ist, andernfalls wird es Teil des Pakets.

Ausführlichere Informationen finden Sie hier: [http://nuget.codeplex.com/workitem/936](http://nuget.codeplex.com/workitem/936)

Hinzufügen einer „Minimum NuGet Version“-Eigenschaft zu Paketen

Ein neues Metadatenattribut namens minClientVersion kann jetzt die minimale NuGet-Clientversion angeben, die für die Nutzung eines Pakets erforderlich ist.

Dieses Feature hilft dem Paketautor, anzugeben, dass ein Paket nur nach einer bestimmten Version von NuGet funktioniert. Wenn neue .nuspec Features nach NuGet 2.5 hinzugefügt werden, können Pakete eine minimale NuGet-Version beanspruchen.

<metadata minClientVersion="2.6">

Wenn der Benutzer NuGet 2.5 installiert hat und ein Paket als 2.6 erforderlich identifiziert wird, werden dem Benutzer visuelle Hinweise übergeben, die angeben, dass das Paket nicht installiert werden kann. Der Benutzer wird dann angeleitet, um seine Version von NuGet zu aktualisieren.

Dadurch wird die vorhandene Oberfläche verbessert, bei der Pakete mit der Installation beginnen, aber dann fehlschlagen, wenn eine nicht erkannte Schemaversion identifiziert wurde.

Abhängigkeiten werden während der Paketinstallation nicht mehr unnötig aktualisiert.

Vor NuGet 2.5 wurde bei der Installation eines Pakets, das von einem bereits im Projekt installierten Paket abhing, die Abhängigkeit als Teil der neuen Installation aktualisiert, selbst wenn die vorhandene Version die Abhängigkeit erfüllte.

Ab NuGet 2.5 wird die Abhängigkeit bei anderen Paketinstallationen nicht mehr aktualisiert, wenn die Version einer Abhängigkeit bereits erfüllt ist.

Szenario:

  1. Das Quell-Repository enthält Paket B mit Version 1.0.0 und 1.0.2. Es enthält auch Paket A, das eine Abhängigkeit von B hat (>= 1.0.0).
  2. Gehen Sie davon aus, dass das aktuelle Projekt bereits Paket B Version 1.0.0 installiert hat. Nun möchten Sie Paket A installieren.

In NuGet 2.2 und älter:

  • Bei der Installation von Paket A aktualisiert NuGet B automatisch auf 1.0.2, obwohl die vorhandene Version 1.0.0 bereits die Abhängigkeitsversionseinschränkung erfüllt, was = 1.0.0 lautet >.

In NuGet 2.5 und höher:

  • NuGet aktualisiert B nicht mehr, da erkannt wird, dass die vorhandene Version 1.0.0 die Abhängigkeitsversionseinschränkung erfüllt.

Weitere Hintergrundinformationen zu dieser Änderung finden Sie im Detail [work item](https://nuget.codeplex.com/workitem/1681) sowie in den zugehörigen [discussion thread](https://nuget.codeplex.com/discussions/436712)Informationen.

nuget.exe gibt HTTP-Anforderungen mit detaillierter Ausführlichkeit aus.

Wenn Sie nuget.exe beheben oder nur neugierig sind, welche HTTP-Anforderungen während des Betriebs vorgenommen werden, gibt die Option -verbosity detailed jetzt alle HTTP-Anforderungen aus.

HTTP output from nuget.exe

nuget.exe push unterstützt jetzt UNC- und Ordnerquellen

Wenn Sie vor NuGet 2.5 versuchten, nuget.exe push zu einer Paketquelle auszuführen, die auf einem UNC-Pfad oder einem lokalen Ordner basierte, schlug der Push-Vorgang fehl. Mit dem kürzlich hinzugefügten hierarchischen Konfigurationsfeature war es üblich, dass nuget.exe entweder auf eine UNC/Folder-Quelle oder einen HTTP-basierten NuGet-Katalog abzielen muss.

Beginnend mit NuGet 2.5, wenn nuget.exe eine UNC/Ordner-Quelle identifiziert, wird die Datei in die Quelle kopiert.

Der folgende Befehl funktioniert jetzt:

nuget push -source \\mycompany\repo\ mypackage.1.0.0.nupkg

nuget.exe unterstützt explizit spezifizierte Config-Dateien

nuget.exe-Befehle, die auf die Konfiguration zugreifen (mit Ausnahme von spec und pack), unterstützen jetzt eine neue Option -ConfigFile, die erzwingt, dass eine bestimmte Konfigurationsdatei anstelle der Standardkonfigurationsdatei unter %AppData%\nuget\Nuget.Config verwendet wird.

Beispiel:

nuget sources add -name test -source http://test -ConfigFile C:\test\.nuget\Nuget.Config

Unterstützung von nativen Projekten.

Mit NuGet 2.5 ist das NuGet-Tool jetzt für native Projekte in Visual Studio verfügbar. Wir erwarten, dass die meisten nativen Pakete das obige MSBuild-Importfeature verwenden, indem ein tool verwendet wird, das vom CoApp-Projekt erstellt wurde. Weitere Informationen finden Sie in den Details zum Tool auf der coapp.org-Website.

Der Zielframeworkname „native“ wird eingeführt, damit Pakete Dateien in \build, \content und \tools einschließen, wenn das Paket in einem systemeigenen Projekt installiert wird. Der Ordner „lib“ wird nicht für systemeigene Projekte verwendet.