Versionshinweise zu NuGet 2.1

NuGet 2.0 Versionshinweise | NuGet 2.2 Versionshinweise

NuGet 2.1 wurde am 4. Oktober 2012 veröffentlicht.

Hierarchische Nuget.Config

NuGet 2.1 bietet Ihnen mehr Flexibilität beim Steuern von NuGet-Einstellungen, indem Sie die Ordnerstruktur NuGet.Config rekursiv nach Dateien durchlaufen und dann die Konfiguration aus der Gruppe aller gefundenen Dateien erstellen. Betrachten Sie beispielsweise das Szenario, in dem ein Team über ein internes Paket-Repository für CI-Builds anderer interner Abhängigkeiten verfügt. Die Ordnerstruktur für ein Java-Projekt sieht wie folgt aus:

C:\
C:\myteam\
C:\myteam\solution1
C:\myteam\solution1\project1

Wenn die Paketwiederherstellung für die Lösung aktiviert ist, ist auch der folgende Ordner vorhanden:

C:\myteam\solution1\.nuget

Damit das interne Paket-Repository des Teams für alle Projekte verfügbar ist, an denen das Team arbeitet, ohne es für jedes Projekt auf dem Computer verfügbar zu machen, können wir eine neue Nuget.Config-Datei erstellen und im Ordner c:\myteam platzieren. Es gibt keine Möglichkeit, einen bestimmten Paketordner pro Projekt zu erstellen.

<configuration>
    <packageSources>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </packageSources>
    <disabledPackageSources />
    <activePackageSource>
    <add key="Official project team source" value="http://teamserver/api/v2/" />
    </activePackageSource>
</configuration>

Wir können nun sehen, dass die Quelle hinzugefügt wurde, indem Sie den Befehl nuget.exe sources aus einem beliebigen Ordner unter c:\myteam ausführen, wie unten gezeigt:

NuGet.Config Dateien werden in der folgenden Reihenfolge durchsucht:

1. .nuget\Nuget.Config
2. Rekursive Wanderung vom Projektordner zum Stammverzeichnis
3. Global Nuget.Config (%appdata%\NuGet\Nuget.Config)

Die Konfigurationen werden in umgekehrter Reihenfolge angewendet, d. h., dass basierend auf der obigen Reihenfolge zuerst die globale Nuget.Config angewendet wird, gefolgt von den ermittelten Nuget.Config-Dateien vom Stamm- in den Projektordner, gefolgt von .nuget\Nuget.Config. Dies ist besonders wichtig, wenn Sie das <clear/> Element verwenden, um eine Reihe von Elementen aus der Konfiguration zu entfernen.

Ordnerspeicherort Pakete angeben

In der Vergangenheit hat NuGet die Pakete einer Lösung aus einem bekannten Ordner Pakete unter dem Lösungsstammordner verwaltet. Für Entwicklungsteams mit vielen verschiedenen Lösungen, die NuGet-Pakete installiert haben, kann dies dazu führen, dass dasselbe Paket an vielen verschiedenen Stellen im Dateisystem installiert wird.

NuGet 2.1 bietet eine genauere Kontrolle über den Speicherort des Paketordners über das repositoryPath Element in der NuGet.Config Datei. Bei der Erstellung des vorherigen Beispiels der hierarchischen Unterstützung von Nuget.Config wird davon ausgegangen, dass alle Projekte unter C:\myteam\ denselben Paketordner gemeinsam nutzen möchten. Fügen Sie dazu einfach den folgenden Eintrag zu c:\myteam\Nuget.Config hinzu.

<configuration>
    <config>
    <add key="repositoryPath" value="C:\myteam\teampackages" />
    </config>
    ...
</configuration>

In diesem Beispiel gibt die freigegebene Nuget.Config Datei unabhängig von der Tiefe einen Ordner für freigegebene Pakete für jedes Projekt an, das unter C:\myteam erstellt wird. Beachten Sie, dass Sie, wenn Sie über einen vorhandenen Paketordner unterhalb des Lösungsstamms verfügen, diesen löschen müssen, bevor NuGet Pakete an dem neuen Speicherort platziert.

Unterstützung für portierbare Bibliotheken

Portable Bibliotheken sind ein Feature, das mit .NET 4 eingeführt wurde, mit dem Sie Assemblys erstellen können, die ohne Änderungen auf verschiedenen Microsoft-Plattformen funktionieren können, von Versionen von the.NET Framework bis Silverlight zu Windows Telefon und sogar Xbox 360 (NuGet unterstützt derzeit jedoch nicht das Ziel der portierbaren Xbox-Bibliothek). Durch die Erweiterung der Paketkonventionen für Frameworkversionen und Profile unterstützt NuGet 2.1 jetzt portierbare Bibliotheken, indem Sie Pakete erstellen können, die über Verbundframework- und Profilzielordner lib verfügen.

Betrachten Sie beispielsweise die verfügbaren Zielplattformen der folgenden portierbaren Klassenbibliothek.

Nachdem die Bibliothek erstellt wurde und der Befehl nuget.exe pack MyPortableProject.csproj ausgeführt wird, kann die neue Struktur des portierbaren Bibliothekspaketordners angezeigt werden, indem der Inhalt des generierten NuGet-Pakets untersucht wird.

Wie Sie sehen können, folgt die Namenskonvention für portierbare Bibliotheksordner dem Muster portable-{framework 1}+{framework n}, bei dem die Framework-Bezeichner den vorhandenen Frameworknamen und Versionskonventionen entsprechen. Eine Ausnahme zu den Namens- und Versionskonventionen finden Sie in der Framework-ID, die für Windows Telefon verwendet wird. Dieser Moniker sollte den Frameworknamen wp (wp7, wp71 oder wp8) verwenden. Die Verwendung von silverlight-wp7 führt zum Beispiel zu einem Fehler.

Beim Installieren des Pakets, das aus dieser Ordnerstruktur erstellt wird, kann NuGet nun sein Framework und seine Profilregeln auf mehrere Ziele anwenden, wie im Ordnernamen angegeben. Hinter NuGet-Vergleichsregeln liegt das Prinzip, dass spezifischere Ziele Vorrang vor weniger spezifischen Zielen haben. Dies bedeutet, dass Moniker, die auf eine bestimmte Plattform abzielen, immer gegenüber portierbaren Monikern bevorzugt werden, wenn beide mit einem Projekt kompatibel sind. Wenn mehrere tragbare Ziele mit einem Projekt kompatibel sind, bevorzugt NuGet außerdem die Gruppe, auf die der unterstützte Satz von Plattformen am nächsten mit dem Projekt verweist, das auf das Paket verweist.

Adressierung von Windows 8- und Windows Telefon 8-Projekten

NuGet 2.1 bietet neben der Unterstützung für die Zielbestimmung für portierbare Bibliotheksprojekte neue Framework-Moniker für Windows 8 Store- und Windows Telefon 8-Projekte sowie einige neue allgemeine Moniker für Windows Store- und Windows Telefon-Projekte, die für zukünftige Versionen der jeweiligen Plattformen einfacher zu verwalten sind.

Für Windows 8 Store-Anwendungen sehen die Bezeichner wie folgt aus:

NuGet 2.0 und früher	NuGet 2.1
winRT45, .NETCore45	Windows, Windows8, win, win8

Bei Windows Telefon-Projekten sehen die Bezeichner wie folgt aus:

Telefon Betriebssystem	NuGet 2.0 und früher	NuGet 2.1
Windows Phone 7	silverlight3-wp	wp, wp7, Windows-Telefon, Windows-Telefon 7
Windows-Telefon 7.5 (Mango)	silverlight4-wp71	wp71, Windows-Telefon 71
Windows Phone 8	(Nicht unterstützt)	wp8, Windows-Telefon 8

In allen oben genannten Änderungen werden die alten Frameworknamen weiterhin vollständig von NuGet 2.1 unterstützt. In Zukunft sollten die neuen Namen verwendet werden, da sie in zukünftigen Versionen der jeweiligen Plattformen stabiler sein werden. Die neuen Namen werden *nicht* in Versionen von NuGet vor 2.1 unterstützt. Planen Sie daher entsprechend, wann Sie den Umstieg vornehmen.

Verbesserte Suche im Dialogfeld Paket-Manager

In den letzten Iterationen wurden Änderungen im NuGet-Katalog eingeführt, die die Geschwindigkeit und Relevanz von Paketsuchen erheblich verbessert haben. Diese Verbesserungen waren jedoch auf die nuget.org Website beschränkt. NuGet 2.1 macht die verbesserte Sucherfahrung über das NuGet-Paket-Manager-Dialogfeld verfügbar. Stellen Sie sich als Beispiel vor, dass Sie das Windows Azure Caching Vorschau-Paket finden wollten. Eine angemessene Suchabfrage für dieses Paket kann „Azure Cache“ sein. In früheren Versionen des Dialogfelds Paket-Manager würde das gewünschte Paket nicht einmal auf der ersten Seite der Ergebnisse aufgeführt. In NuGet 2.1 wird das gewünschte Paket jetzt jedoch oben in den Suchergebnissen angezeigt.

Paketupdate erzwingen

Vor NuGet 2.1 würde NuGet das Aktualisieren eines Pakets überspringen, wenn keine hohe Versionsnummer vorhanden war. Dies führte zu Reibungen für bestimmte Szenarien – insbesondere bei Build- oder CI-Szenarien, in denen das Team die Paketversionsnummer bei jedem Build nicht erhöhen wollte. Das gewünschte Verhalten bestand in der Erzwingung einer Aktualisierung unabhängig davon. NuGet 2.1 behebt dies mit dem Flag „neu installieren“. Beispielsweise würden frühere Versionen von NuGet folgendes ergeben, wenn sie versuchen, ein Paket zu aktualisieren, das nicht über eine neuere Paketversion verfügte:

PM> Update-Package Moq
No updates available for 'Moq' in project 'MySolution.MyConsole'.

Bei der Erneutinstallationskennzeichnung wird das Paket unabhängig davon aktualisiert, ob eine neuere Version vorhanden ist.

PM> Update-Package Moq -Reinstall
Successfully removed 'Moq 4.0.10827' from MySolution.MyConsole.
Successfully uninstalled 'Moq 4.0.10827'.
Successfully installed 'Moq 4.0.10827'.
Successfully added 'Moq 4.0.10827' to MySolution.MyConsole.

Ein weiteres Szenario, in dem sich das Neuinstallations-Flag als vorteilhaft erweist, ist die Neuausrichtung des Frameworks. Beim Ändern des Zielframeworks eines Projekts (z. B. von .NET 4 auf .NET 4.5) kann Update-Package -Reinstall Verweise auf die richtigen Assemblys für alle im Projekt installierten NuGet-Pakete aktualisieren.

Bearbeiten von Paketquellen in Visual Studio

In früheren Versionen von NuGet erforderte das Aktualisieren einer Paketquelle aus dem Dialogfeld Visual Studio-Optionen das Löschen und erneute Hinzufügen der Paketquelle. NuGet 2.1 verbessert diesen Arbeitsablauf, indem es die Aktualisierung als eine erstklassige Funktion der Konfigurationsbenutzeroberfläche unterstützt.

Fehlerkorrekturen

NuGet 2.1 enthält viele Programmfehlerbehebungen. Eine vollständige Liste der Arbeitselemente, die in NuGet 2.0 behoben wurden, sehen Sie hier [NuGet Issue Tracker for this release](http://nuget.codeplex.com/workitem/list/advanced?keyword=&status=Fixed&type=All&priority=All&release=NuGet%202.1&assignedTo=All&component=All&sortField=LastUpdatedDate&sortDirection=Descending&page=0).