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.
Wir bedanken uns bei den folgenden externen Mitwirkenden für ihre bedeutende Beiträge für NuGet 2.5:
[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.
[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 derNuGet.targets
Groß-/Kleinschreibung
[David Fowler](https://www.codeplex.com/site/users/view/dfowler)
(@davidfowl)- Erstellen des Lösungsbuild auf Mono.
[Andrew Theken](https://www.codeplex.com/site/users/view/atheken)
(@atheken)- Beheben der Komponententests, die bei Mono fehlschlagen.
[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
[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.
[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.
[Bruno Roggeri](https://www.codeplex.com/site/users/view/broggeri)
- Beheben der Komponententests, wenn sie in lokalisiertem VS ausgeführt werden.
[Gareth Evans](https://www.codeplex.com/site/users/view/garethevans)
- Extrahierte Schnittstelle aus PackageService
[Maxime Brugidou](https://www.codeplex.com/site/users/view/brugidou)
(@brugidou)[#936](https://nuget.codeplex.com/workitem/936)
– Behandeln von Projektabhängigkeiten beim Packen
[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.
[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:
[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
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.
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.
Auf der obersten Ebene des NuGet-Pakets wurde ein neuer herkömmlicher Ordner erstellt. Als Peer zu \lib
, \content
und \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.
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:
- Suchen Sie den Ordner, der
lib
für das Zielframework geeignet ist, und rufen Sie die Liste der Assemblys aus diesem Ordner ab. - 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.
- 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.
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:
- Erstellen einer neuen ASP.NET MVC-Anwendung
- Starten Sie den Dialog NuGet-Pakete verwalten.
- Wählen Sie „Aktualisierungen“ aus.
- Klicken Sie auf die Schaltfläche „Alles aktualisieren“.
Jetzt verarbeitet der Packbefehl nuget.exe referenzierte Projekte mit den folgenden Regeln:
- Wenn das referenzierte Projekt eine entsprechende
.nuspec
Datei hat, z. B. eineproj1.nuspec
Datei im gleichen Ordner wieproj1.csproj
, dann wird dieses Projekt als Abhängigkeit zum Paket hinzugefügt, wobei die aus der.nuspec
Datei gelesene ID und Version verwendet wird. - 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.
- Alle DLL,
.pdb
und.exe
Dateien werden hinzugefügt. - Alle anderen Inhaltsdateien werden hinzugefügt.
- 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)
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.
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:
- 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).
- 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.
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.
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-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
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.