Freigeben über

NuGet 2.5 – Versionshinweise

NuGet 2.2.1 Versionshinweise | NuGet 2.6 Versionshinweise

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

Danksagung

Wir danken den folgenden externen Mitwirkenden für ihre bedeutenden Beiträge zu NuGet 2.5:

  1. [Daniel Plaisted](https://www.codeplex.com/site/users/view/dsplaisted) (@dsplaisted)
    • [#2847](https://nuget.codeplex.com/workitem/2847) - Fügen Sie MonoAndroid, MonoTouch und MonoMac zur Liste der bekannten Zielframework-IDs hinzu.
  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 Sie die Lösung unter Mono.
  4. [Andrew Theken](https://www.codeplex.com/site/users/view/atheken) (@atheken)
    • Beheben sie Komponententests, die bei Mono fehlschlagen.
  5. [Olivier Dagenais](https://www.codeplex.com/site/users/view/OliIsCool) (@OliIsCool)
    • [#2920](https://nuget.codeplex.com/workitem/2920) - nuget.exe Pack-Befehl verteilt 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 Sie Unit-Tests, 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) - Projektabhängigkeiten beim Packen verwalten
  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ützen Sie beim Speichern von Paketquellanmeldeinformationen in nuget.cofig-Dateien das Klartextkennwort.
  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) - Korrigieren der Get-Package-Hilfebeschreibung

Wir schätzen auch die folgenden Personen für das Auffinden von Fehlern bei NuGet 2.5 Beta/RC, die genehmigt und vor der endgültigen Veröffentlichung 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.

Überschreiben von Inhaltsdateien

'nuget.exe Update' und 'Install-Package' verfügen jetzt über 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 auf "Überschreiben" fest, um Dateien immer zu überschreiben. Legen Sie auf "Ignorieren" fest, um Dateien zu überspringen. Falls nicht angegeben, wird es für jede in Konflikt stehende Datei eine Eingabeaufforderung geben.

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. In diesem Ordner können Sie zwei Dateien mit festgelegten 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 zum Auswählen des am besten übereinstimmenden Frameworkordners entspricht genau denen.

Wenn NuGet ein Paket mit \build-Dateien installiert, wird ein MSBuild-Element <Import> in der Projektdatei hinzugefügt, das auf die .targets Dateien .props 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 Ablauf zum Hinzufügen von Verweisen in Projekten 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 Verweise zum Hinzufügen.

Mit diesem neuen Feature können Paketautoren das Feature "Verweise" verwenden, um Assembly-Untergruppen auf unterschiedliche Frameworks anzuwenden, anstatt doppelte Assemblys in mehreren lib Ordnern verwalten zu müssen.

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 wissen über 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 erledigen.

So probieren Sie dieses Feature aus:

  1. Erstellen einer neuen ASP.NET MVC-Anwendung
  2. Starten des Dialogfelds "NuGet-Pakete verwalten"
  3. Wählen Sie "Updates" aus.
  4. Klicken Sie auf die Schaltfläche "Alle aktualisieren".

Schaltfläche

Verbesserte Projektreferenzunterstützung für nuget.exe Pack

Jetzt verarbeitet der Befehl "nuget.exe pack" referenzierte Projekte mit den folgenden Regeln:

  1. Wenn das referenzierte Projekt über eine passende .nuspec Datei verfügt, z. B. gibt es eine Datei namens proj1.nuspec im gleichen Ordner wie proj1.csproj, wird dieses Projekt als Abhängigkeit des Pakets hinzugefügt, wobei die ID und Version aus der .nuspec Datei gelesen werden.
  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-Dateien, .pdb und .exe 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.

Weitere Details 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 geführt, um seine Version von NuGet zu aktualisieren.

Dadurch wird das vorhandene Erlebnis verbessert, bei dem Pakete mit der Installation beginnen, aber dann fehlschlagen, weil eine nicht erkannte Schemaversion festgestellt wurde.

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

Bevor NuGet 2.5 installiert wurde, wenn ein Paket installiert wurde, das von einem Paket abhängt, das bereits im Projekt installiert ist, würde die Abhängigkeit als Teil der neuen Installation aktualisiert, auch wenn die vorhandene Version die Abhängigkeit erfüllt hat.

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

Das 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. Jetzt möchten Sie Paket A installieren.

In NuGet 2.2 und älter:

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

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 detaillierte Hintergrundinformationen zu dieser Änderung finden Sie in [work item](https://nuget.codeplex.com/workitem/1681) sowie in den zugehörigen [discussion thread](https://nuget.codeplex.com/discussions/436712).

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

Wenn Sie eine Problembehandlung mit nuget.exe durchführen oder nur neugierig sind, welche HTTP-Anforderungen während des Vorgangs gemacht werden, gibt die Option "-verbosity ausführlich" nun alle HTTP-Anforderungen aus.

HTTP-Ausgabe von nuget.exe

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

Wenn Sie vor NuGet 2.5 versucht haben, 'nuget.exe Push' auf eine Paketquelle basierend auf einem UNC-Pfad oder lokalen Ordner auszuführen, schlägt der Push fehl. Mit dem kürzlich hinzugefügten hierarchischen Konfigurationsfeature war es üblich, dass nuget.exe entweder auf eine UNC-/Ordnerquelle oder eine HTTP-basierte NuGet-Galerie abzielen kann.

Ab NuGet 2.5, wenn nuget.exe eine UNC-/Ordnerquelle identifiziert, wird die Datei zum Quelle kopiert.

Der folgende Befehl funktioniert nun:

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

nuget.exe unterstützt explizit angegebene Konfigurationsdateien

nuget.exe Befehle, die auf die Konfiguration zugreifen (außer 'spec' und 'pack'), unterstützen jetzt eine neue Option "-ConfigFile", die erzwingt, dass eine bestimmte Konfigurationsdatei anstelle der Standardkonfigurationsdatei bei %AppData%\nuget\Nuget.Config verwendet wird.

Beispiel:

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

Unterstützung für native Projekte

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.

  • Last updated on