Auf Englisch lesen

Freigeben über


Versionshinweise zu NuGet 2.7

NuGet 2.6.1 für WebMatrix Versionshinweise | NuGet 2.7.1 Versionshinweise

NuGet 2.7 wurde am 22. August 2013 veröffentlicht.

Danksagung

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

  1. [Mike Roth](http://www.codeplex.com/site/users/view/mxrss) (@mxrss)
    • Lizenz-URL anzeigen, wenn das Auflisten von Paketen und Ausführlichkeit detailliert ist.
  2. [Adam Ralph](http://www.codeplex.com/site/users/view/adamralph) (@adamralph)
    • [#1956](http://nuget.codeplex.com/workitem/1956) - Fügen Sie packages.config das Attribut DevelopmentDependency hinzu und verwenden Sie es im Paket-Befehl, um nur Laufzeitpakete einzuschließen.
  3. [Rafael Nicoletti](http://www.codeplex.com/site/users/view/tkrafael) (@tkrafael)
    • Vermeiden Sie den doppelten Eigenschaftenschlüssel im Befehl nuget.exe pack.
  4. [Ben Phegan](http://www.codeplex.com/site/users/view/benphegan) (@BenPhegan)
    • [#2610](http://nuget.codeplex.com/workitem/2610) - Erhöhen Sie die Größe des Computercaches auf 200.
  5. [Slava Trenogin](http://www.codeplex.com/site/users/view/derigel) (@derigel)
    • [#3217](http://nuget.codeplex.com/workitem/3217) - NuGet-Dialogfeld beheben, in dem Updates auf der falschen Registerkarte angezeigt werden
    • Fix Project.TargetFramework kann in ProjectManager null sein
    • [#3248](http://nuget.codeplex.com/workitem/3248) - Fix SharedPackageRepository FindPackage/FindPackagesById schlägt bei nicht vorhandener packageId fehl
  6. [Kevin Boyle](http://www.codeplex.com/site/users/view/KevinBoyleRG) (@kevfromireland)
    • [#3234](http://nuget.codeplex.com/workitem/3234) - Unterstützung für Nomad-Projekt aktivieren
  7. [Corin Blaikie](http://www.codeplex.com/site/users/view/corinblaikie) (@corinblaikie)
    • [#3252](http://nuget.codeplex.com/workitem/3252) – Fehler beim Beheben des Pushbefehls mit Exitcode 0, wenn die Datei nicht vorhanden ist.
  8. [Martin Veselý](http://www.codeplex.com/site/users/view/veselkamartin)
    • [#3226](http://nuget.codeplex.com/workitem/3226) – Behebung eines Fehlers mit dem Befehl Add-BindingRedirect, wenn ein Projekt auf ein Datenbankprojekt verweist.
  9. [Miroslav Bajtos](http://www.codeplex.com/site/users/view/miroslavbajtos) (@bajtos)
    • [#2891](http://nuget.codeplex.com/workitem/2891)- Fehler beim Analysieren von nuget.pack Platzhalter im Attribut exclude falsch beheben.
  10. [Justin Dearing](http://www.codeplex.com/site/users/view/zippy1981) (@zippy1981)
    • [#3307](http://nuget.codeplex.com/workitem/3307) - Bug beheben NuGet.targets wird $(Platform) nicht an nuget.exe übergeben, wenn Pakete wiederhergestellt werden.
  11. [Brian Federici](http://www.codeplex.com/site/users/view/benerdin)
    • [#3294](http://nuget.codeplex.com/workitem/3294) - Bug beheben in nuget.exe Paket-Befehl, der das Hinzufügen von Dateien mit gleichem Namen, aber unterschiedlicher Schreibweise ermöglichte, was zur Ausnahme Element existiert bereits führte.
  12. [Daniel Cazzulino](http://www.codeplex.com/site/users/view/dcazzulino) (@kzu)
    • [#2990](http://nuget.codeplex.com/workitem/2990) - Hinzufügen der Version-Eigenschaft zur NetPortableProfile-Klasse.
  13. [David Simner](https://www.codeplex.com/site/users/view/DavidSimner)
    • [#3460](https://nuget.codeplex.com/workitem/3460) - Fehler NullReferenceException beheben, wenn requireApiKey = true, aber der Header X-NUGET-APIKEY nicht vorhanden ist
  14. [Michael Friis](https://www.codeplex.com/site/users/view/friism) (@friism)
    • [#3278](https://nuget.codeplex.com/workitem/3278) - Behebt die Datei NuGet.Build als Zieldatei, sodass sie auf MonoDevelop ordnungsgemäß funktioniert
  15. [Pranav Krishnamoorthy](https://www.codeplex.com/site/users/view/pranavkm) (@pranav_km)
    • Verbessern der Leistung des Wiederherstellen-Befehls durch Erhöhen der Parallelisierung

Wichtige Features in der Version

NuGet 2.7 führt einen neuen Ansatz für die Paketwiederherstellung ein und überwindet auch eine große Hürde: Die Zustimmung zur Paketwiederherstellung ist jetzt standardmäßig aktiviert! Die Kombination aus dem neuen Ansatz und der impliziten Zustimmung vereinfacht die Paketwiederherstellungsszenarien erheblich.

Mit den NuGet-Versionen 2.0, 2.1, 2.2, 2.5 und 2.6 mussten Benutzer NuGet explizit erlauben, fehlende Pakete während des Builds herunterzuladen. Wenn diese Zustimmung nicht explizit erteilt wurde, konnten Lösungen, die die Paketwiederherstellung aktiviert hatten, erst erstellt werden, wenn der Benutzer die Zustimmung erteilt hatte.

Ab NuGet 2.7 ist die Zustimmung zur Paketwiederherstellung standardmäßig aktiviert, während Benutzer die Paketwiederherstellung bei Bedarf explizit deaktivieren können, indem Sie das Kontrollkästchen in den NuGet-Einstellungen in Visual Studio verwenden. Diese Änderung für die implizite Zustimmung wirkt sich auf NuGet in den folgenden Umgebungen aus:

  • Visual Studio 2013 Preview
  • Visual Studio 2012
  • Visual Studio 2010
  • nuget.exe Befehlszeilen-Hilfsprogramme

Automatisches Wiederherstellen von Paketen mit Visual Studio

Ab NuGet 2.7 lädt NuGet automatisch fehlende Pakete während des Builds in Visual Studio herunter, auch wenn die Paketwiederherstellung für die Lösung nicht explizit aktiviert wurde. Diese automatische Paketwiederherstellung erfolgt in Visual Studio, wenn Sie ein Projekt oder die Projektmappe erstellen, aber bevor MSBuild aufgerufen wird. Dies führt zu einigen erheblichen Vorteilen:

  1. Sie müssen die Geste NuGet-Paketwiederherstellung aktivieren für Ihre Lösung nicht weiter verwenden.
  2. Projekte müssen nicht geändert werden, und NuGet nimmt keine Änderungen am Projekt vor, um sicherzustellen, dass die Paketwiederherstellung aktiviert ist.
  3. Alle NuGet-Pakete, einschließlich derjenigen, die MSBuild-Importe für Props/Ziele-Dateien enthalten, werden wiederhergestellt , bevor MSBuild aufgerufen wird, um sicherzustellen, dass diese Props/Ziele während des Builds ordnungsgemäß erkannt werden.

Um die automatische Paketwiederherstellung in Visual Studio zu verwenden, müssen Sie nur eine (in)Aktion ausführen:

  1. Checken Sie nicht Ihren packages Ordner ein

Es gibt mehrere Möglichkeiten, den packages Ordner aus der Quellcodeverwaltung auszulassen. Weitere Informationen finden Sie im Thema Pakete und Quellcodeverwaltung .

Während alle Benutzer implizit die Zustimmung zur automatischen Paketwiederherstellung aktiviert haben, können Sie die Paket-Manager Einstellungen in Visual Studio ganz einfach deaktivieren.

Package Manager Settings

Vereinfachte Wiederherstellung von Paketen aus der Befehlszeile

NuGet 2.7 führt ein neues Feature für nuget.exe ein: nuget.exe restore

Mit diesem neuen Befehl Wiederherstellen können Sie alle Pakete für eine Lösung mit einem einzigen Befehl problemlos wiederherstellen, indem Sie eine Lösungsdatei oder einen Ordner als Argument akzeptieren. Darüber hinaus wird dieses Argument impliziert, wenn nur eine einzige Lösung im aktuellen Ordner vorhanden ist. Das bedeutet, dass alle folgenden Arbeiten aus einem Ordner mit einer einzigen Lösungsdatei (MySolution.sln) ausgeführt werden:

  1. nuget.exe restore MySolution.sln
  2. nuget.exe restore.
  3. nuget.exe restore

Der Befehl Wiederherstellen öffnet die Projektmappendatei und sucht alle Projekte in der Projektmappe. Von dort aus finden Sie die packages.config Dateien für jedes der Projekte und stellen alle gefundenen Pakete wieder her. Außerdem werden Pakete auf Lösungsebene wiederhergestellt, die in der .nuget\packages.config Datei enthalten sind. Weitere Informationen zum neuen Befehl Wiederherstellen finden Sie in der Befehlszeilenreferenz.

Der Workflow für die neue Paketwiederherstellung

Wir freuen uns über diese Änderungen an der Paketwiederherstellung, da ein neuer Workflow eingeführt wird. Wenn Sie Ihre Pakete aus der Quellcodeverwaltung weglassen möchten, übernehmen Sie einfach keinen Commit für den packages Ordner. Visual Studio-Benutzer, die die Lösung öffnen und erstellen, sehen die Pakete automatisch wiederhergestellt. Rufen Sie bei Befehlszeilenbuilds einfach nuget.exe restore vor dem Aufrufen von msbuild auf. Sie müssen sich nicht mehr daran erinnern, die Geste NuGet-Paketwiederherstellung aktivieren für Ihre Lösung zu verwenden, und wir müssen Ihre Projekte nicht mehr ändern, um den Build zu ändern. Und dies führt auch zu einer deutlich verbesserten Erfahrung für Pakete, die MSBuild-Importe enthalten, insbesondere für Importe, die über NuGets kürzlich hinzugefügte Feature zum automatischen Importieren von Props/Zieldateien aus dem Ordner "\build" hinzugefügt wurden.

Neben der Arbeit, die wir selbst erledigt haben, arbeiten wir auch mit einigen wichtigen Partnern zusammen, um diesen neuen Ansatz zu runden. Wir haben noch keine konkreten Zeitleiste für eines dieser, aber jeder Partner ist so begeistert, wie wir über den neuen Ansatz sind.

  • Team Foundation-Dienst – Sie arbeiten daran, den Aufruf in die Standardbuildszenarien zu nuget.exe restore integrieren.
  • Windows Azure-Websites – Sie arbeiten daran, Ihr Projekt an Azure zu übertragen und nuget.exe restore aufgerufen zu haben, bevor Ihre Website erstellt wird.
  • TeamCity – Sie aktualisieren ihr NuGet Installer-Plug-In für TeamCity 8.x
  • AppHarbor – Sie arbeiten daran, Ihr Repository an AppHarbor zu übertragen und nuget.exe restore aufgerufen zu haben, bevor Ihre Lösung erstellt wird.

Mit jedem der oben genannten Partner würden sie ihre eigene Kopie von nuget.exe verwenden und Sie müssten nuget.exe nicht in Ihrer Lösung tragen.

Bekannte Probleme

Es gab zwei bekannte Probleme mit der Nuget.exe-Wiederherstellung mit der ersten Version 2.7, aber sie wurden am 9.6.2013 mit einem Update auf das NuGet.CommandLine-Paket behoben. Dieses Update ist auch auf CodePlex [NuGet 2.7 download page](https://nuget.codeplex.com/releases/view/107605) verfügbar. Wenn nuget.exe update -self ausgeführt wird, wird auf die neueste Version aktualisiert.

Das Problem wurde behoben:

  1. [New package restore doesn't work on Mono when using SLN file](https://nuget.codeplex.com/workitem/3596)
  2. [New package restore doesn't work with Wix projects](https://nuget.codeplex.com/workitem/3598)

Es gibt auch ein bekanntes Problem mit dem neuen Paketwiederherstellungsworkflow, wobei [Automatic Package Restore does not work for projects under a solution folder](https://nuget.codeplex.com/workitem/3625). Dieses Problem wurde in NuGet 2.7.1 behoben.

Project Retargeting and Upgrade Build Errors/Warnings

Viele Male nach dem Retargeting oder Upgrade Ihres Projekts stellen Sie fest, dass einige NuGet-Pakete nicht ordnungsgemäß funktionieren. Leider gibt es keinen Hinweis darauf, und dann gibt es keine Anleitungen dazu, wie man es angehen kann. Mit NuGet 2.7 verwenden wir nun einige Visual Studio-Ereignisse, um zu erkennen, wann Sie Ihr Projekt neu ausgerichtet oder aktualisiert haben, um die installierten NuGet-Pakete zu beeinflussen.

Wenn wir feststellen, dass eines Ihrer Pakete durch das Retargeting oder Upgrade betroffen war, werden wir sofortige Buildfehler erstellen, um Sie darüber zu informieren. Zusätzlich zum unmittelbaren Buildfehler speichern wir auch ein requireReinstallation="true" Flag in Ihrer packages.config Datei für alle Pakete, die von der Neuauswertung betroffen waren, und jeder nachfolgende Build in Visual Studio löst Buildwarnungen für diese Pakete aus.

Obwohl NuGet keine automatischen Maßnahmen ergreifen kann, um betroffene Pakete neu zu installieren, hoffen wir, dass diese Angabe und Warnung Ihnen helfen wird, zu ermitteln, wann Sie Pakete neu installieren müssen. Wir arbeiten auch an der Dokumentation zur Paketreinstallation, in der sie von diesen Fehlermeldungen geleitet werden.

NuGet-Konfigurationsstandardwerte

Viele Unternehmen verwenden NuGet intern, hatten aber eine harte Zeit, ihre Entwickler zu leiten, interne Paketquellen anstelle von nuget.org zu verwenden. NuGet 2.7 führt ein Konfigurationsstandardfeature ein, mit dem computerweite Standardwerte angegeben werden können für:

  1. Aktivierte Paketquellen
  2. Registrierte, aber deaktivierte Paketquellen
  3. Die standardmäßige Nuget.exe Pushquelle

Jedes dieser Elemente kann jetzt in einer Datei konfiguriert werden, die sich in einer Datei in %ProgramData%\NuGet\NuGetDefaults.Config befindet. Wenn diese Konfigurationsdatei Paketquellen angibt, wird die Standardmäßige nuget.org Paketquelle nicht automatisch registriert, und die NuGetDefaults.Config in werden stattdessen registriert.

Obwohl diese Funktion nicht verwendet werden muss, erwarten wir, dass Unternehmen NuGetDefaults.Config Dateien mithilfe von Gruppenrichtlinien bereitstellen.

Beachten Sie, dass dieses Feature niemals dazu führt, dass eine Paketquelle aus den NuGet-Einstellungen eines Entwicklers entfernt wird. Wenn der Entwickler also bereits NuGet verwendet und deshalb eine Paketquelle von nuget.org registriert, wird diese nach der Erstellung der NuGetDefaults.Config-Datei nicht entfernt.

Weitere Informationen zu diesem Feature finden Sie unter NuGet Konfigurationsstandard.

Umbenennen der Standardpaketquelle

NuGet hat immer eine Standardpaketquelle namens NuGet offizielle Paketquelle registriert, die auf nuget.org verweist. Dieser Name war ausführlich und es hat auch nicht angegeben, wo er tatsächlich zeigt. Um diese beiden Probleme zu beheben, haben wir diese Paketquelle in einfach nuget.org in der Benutzeroberfläche umbenannt. Die URL für die Paketquelle wurde ebenfalls geändert, um das Präfix "www" einzuschließen. Nachdem Sie NuGet 2.7 verwendet haben, wird Ihre vorhandene "NuGet offizielle Paketquelle" automatisch als Name und https://www.nuget.org/api/v2/ als URL auf nuget.org aktualisiert.

Leistungsverbesserungen

Wir haben in 2.7 einige Leistungsverbesserungen vorgenommen, die einen geringeren Speicherbedarf, weniger Datenträgerauslastung und schnellere Paketinstallationen erzielen. Außerdem haben wir intelligentere Abfragen an OData-basierte Feeds vorgenommen, wodurch die Gesamtnutzlast reduziert wird.

Neue Erweiterbarkeits-APIs

Wir haben unseren Erweiterungsdiensten einige neue APIs hinzugefügt, um die Lücke fehlender Funktionen in früheren Versionen zu füllen.

IVsPackageInstallerServices

// Checks if a NuGet package with the specified Id and version is installed in the specified project.
bool IsPackageInstalledEx(Project project, string id, string versionString);

// Get the list of NuGet packages installed in the specified project.
IEnumerable<IVsPackageMetadata> GetInstalledPackages(Project project);

IVsPackageInstaller

// Installs one or more packages that exist on disk in a folder defined in the registry.
void InstallPackagesFromRegistryRepository(string keyName, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);

// Installs one or more packages that are embedded in a Visual Studio Extension Package.
void InstallPackagesFromVSExtensionRepository(string extensionId, bool isPreUnzipped, bool skipAssemblyReferences, Project project, IDictionary<string, string> packageVersions);

Entwicklungsabhängigkeiten:

Dieses Feature wurde von Adam Ralph beigetragen und ermöglicht es Paketautoren, Abhängigkeiten zu deklarieren, die nur zur Entwicklungszeit verwendet wurden und keine Paketabhängigkeiten erfordern. Durch das Hinzufügen eines developmentDependency="true" Attributs zu einem Paket in packages.config, wird dieses Paket nicht mehr als Abhängigkeit nuget.exe pack einbezogen.

Unterstützung für Visual Studio 2010 Express für Windows-Telefon wurde entfernt

Das neue Paketwiederherstellungsmodell in 2.7 wird durch ein neues VSPackage implementiert, das sich von der Standard NuGet VSPackage unterscheidet. Aufgrund eines technischen Problems funktioniert dieses neue VSPackage in Visual Studio 2010 Express für Windows-Telefon SKU nicht ordnungsgemäß, da wir dieselbe Codebasis für andere unterstützte Visual Studio-SKUs verwenden. Daher wird ab NuGet 2.7 die Unterstützung für Visual Studio 2010 Express für Windows Telefon aus der veröffentlichten Erweiterung entfernt. Die Unterstützung für Visual Studio 2010 Express for Web ist weiterhin in der primären Erweiterung enthalten, die im Visual Studio-Erweiterungskatalog veröffentlicht wurde.

Da wir uns nicht sicher sind, wie viele Entwickler NuGet in dieser Version/Edition von Visual Studio verwenden, veröffentlichen wir eine separate Visual Studio-Erweiterung speziell für diese Benutzer und veröffentlichen sie auf CodePlex (anstelle des Visual Studio-Erweiterungskatalogs). Wir haben nicht vor, diese Erweiterung weiterhin zu pflegen, aber wenn Sie davon betroffen sind, lassen Sie es uns bitte wissen, indem Sie einen Fehler auf CodePlex melden.

Um die NuGet-Paket-Manager (für Visual Studio 2010 Express für Windows Telefon) herunterzuladen, besuchen Sie die [NuGet 2.7 Downloads](https://nuget.codeplex.com/releases/view/107605) Seite.

Fehlerkorrekturen

Zusätzlich zu diesen Features enthält diese Version von NuGet auch viele andere Fehlerbehebungen. In der Version wurden insgesamt 97 Probleme behoben. Eine vollständige Liste der in NuGet 2.7 behobenen Arbeitselemente finden Sie in der [NuGet Issue Tracker for this release](https://nuget.codeplex.com/workitem/list/advanced?release=NuGet%202.7&status=all)Ansicht .