Freigeben über

Unterstützen mehrerer .NET-Versionen

Viele Bibliotheken zielen auf eine bestimmte Version von .NET Framework ab. Beispielsweise verfügen Sie möglicherweise über eine Version Ihrer Bibliothek, die für UWP spezifisch ist, und eine andere Version, die Features in .NET Framework 4.6 nutzt. Um dies zu berücksichtigen, unterstützt NuGet das Einfügen mehrerer Versionen derselben Bibliothek in ein einzelnes Paket.

In diesem Artikel wird das Layout eines NuGet-Pakets beschrieben, unabhängig davon, wie das Paket oder die Assemblys erstellt werden (d. h., das Layout ist identisch, unabhängig davon, ob mehrere CSPROJ-Dateien im Nicht-SDK-Stil und eine benutzerdefinierte NUSPEC-Datei oder eine einzelne multiorientierte SDK-Formatvorlage .csproj verwendet werden). Für ein SDK-Formatprojekt wissen NuGet-Pack-Ziele , wie das Paket angeordnet werden muss, und automatisiert das Platzieren der Assemblys in den richtigen Lib-Ordnern und das Erstellen von Abhängigkeitsgruppen für jedes Zielframework (TFM). Ausführliche Anweisungen finden Sie unter Unterstützen mehrerer .NET Framework-Versionen in Ihrer Projektdatei.

Sie müssen das Paket manuell anordnen, wie in diesem Artikel beschrieben, wenn Sie die konventionsbasierte Arbeitsverzeichnismethode verwenden, die unter Erstellen eines Pakets beschrieben ist. Für ein SDK-Formatprojekt wird die automatisierte Methode empfohlen, Sie können das Paket jedoch auch manuell anordnen, wie in diesem Artikel beschrieben.

** Struktur der Framework-Versionsordner

Beim Erstellen eines Pakets, das entweder nur eine Version einer Bibliothek enthält oder darauf abzielt, mehrere Frameworks zu unterstützen, erstellen Sie stets Unterordner unter lib mit unterscheidbaren Framework-Namen, die auf Groß- und Kleinschreibung achten, gemäß der folgenden Konvention:

lib\{framework name}[{version}]

Eine vollständige Liste der unterstützten Namen finden Sie in der Target Frameworks-Referenz.

Sie sollten niemals über eine Version der Bibliothek verfügen, die nicht spezifisch für ein Framework ist und direkt im Stammordner lib platziert wird. (Diese Funktion wurde nur mit packages.config) unterstützt. Dies würde dazu führen, dass die Bibliothek mit jedem Zielframework kompatibel ist und sie überall installiert werden kann, was zu unerwarteten Laufzeitfehlern führt. Das Hinzufügen von Assemblys im Stammordner (wie lib\abc.dll) oder in Unterordnern (wie lib\abc\abc.dll) ist veraltet und wird ignoriert, wenn das "PackagesReference Format" verwendet wird.

Die folgende Ordnerstruktur unterstützt beispielsweise vier Versionen einer Assembly, die frameworkspezifisch sind:

\lib
    \net46
        \MyAssembly.dll
    \net461
        \MyAssembly.dll
    \uap
        \MyAssembly.dll
    \netcore
        \MyAssembly.dll

Um alle diese Dateien beim Erstellen des Pakets auf einfache Weise einzuschließen, verwenden Sie einen rekursiven ** Wildcard im <files> Abschnitt Ihrer .nuspec:

<files>
    <file src="lib\**" target="lib/{framework name}[{version}]" />
</files>

Architekturspezifische Ordner

Wenn Sie über architekturspezifische Assemblys verfügen, d. h. separate Assemblys, die auf ARM, x86 und x64 abzielen, müssen Sie diese in einem Ordner platzieren, der innerhalb von Unterordnern mit den Namen runtimes oder {platform}-{architecture}\lib\{framework} oder {platform}-{architecture}\native liegt. Die folgende Ordnerstruktur würde beispielsweise sowohl systemeigene als auch verwaltete DLLs für Windows 10 und das uap10.0 Framework berücksichtigen:

\runtimes
    \win10-arm
        \native
        \lib\uap10.0
    \win10-x86
        \native
        \lib\uap10.0
    \win10-x64
        \native
        \lib\uap10.0

Diese Assemblys sind nur zur Laufzeit verfügbar. Wenn Sie also die entsprechende Kompilierzeit-Assembly bereitstellen möchten, dann legen Sie die Assembly im AnyCPU-Ordner /ref/{tfm} ab.

Bitte beachten Sie, dass NuGet diese Kompilierungs- oder Laufzeitressourcen immer aus einem Ordner auswählt. Wenn also einige kompatible Ressourcen aus /ref vorhanden sind, werden /lib ignoriert, um Kompilierungszeitbibliotheken hinzuzufügen. Ebenso wird, wenn einige kompatible Assets von /runtimes vorhanden sind, auch /lib zur Laufzeit ignoriert.

Unter Erstellen von UWP-Paketen finden Sie ein Beispiel für den Verweis auf diese Dateien im .nuspec Manifest.

Weitere Informationen finden Sie unter Packen einer Komponente für Windows Store-Apps mit NuGet

Abgleich von Assembly-Versionen und dem Ziel-Framework in einem Projekt

Wenn NuGet ein Paket mit mehreren Assemblyversionen installiert, versucht es, den Frameworknamen der Assembly mit dem Zielframework des Projekts übereinzugleichen.

Wenn keine Übereinstimmung gefunden wird, kopiert NuGet die Assembly für die höchste Version, die kleiner oder gleich dem Zielframework des Projekts ist, falls verfügbar. Wenn keine kompatible Assembly gefunden wird, gibt NuGet eine entsprechende Fehlermeldung zurück.

Betrachten Sie beispielsweise die folgende Ordnerstruktur in einem Paket:

\lib
    \net45
        \MyAssembly.dll
    \net461
        \MyAssembly.dll

Beim Installieren dieses Pakets in einem Projekt, das auf .NET Framework 4.6 ausgerichtet ist, installiert NuGet die Assembly im net45 Ordner, da dies die höchste verfügbare Version ist, die kleiner oder gleich 4.6 ist.

Wenn das Projekt auf .NET Framework 4.6.1 ausgerichtet ist, installiert NuGet die Assembly hingegen im net461 Ordner.

Wenn das Projekt auf .NET Framework 4.0 und früher ausgerichtet ist, löst NuGet eine entsprechende Fehlermeldung aus, um die kompatible Assembly nicht zu finden.

Gruppieren von Assemblys nach Frameworkversion

NuGet kopiert Assemblys nur aus einem einzigen Bibliotheksordner im Paket. Angenommen, ein Paket weist die folgende Ordnerstruktur auf:

\lib
    \net40
        \MyAssembly.dll (v1.0)
        \MyAssembly.Core.dll (v1.0)
    \net45
        \MyAssembly.dll (v2.0)

Wenn das Paket in einem Projekt installiert wird, das auf .NET Framework 4.5 ausgerichtet ist( MyAssembly.dll v2.0), ist die einzige Assembly installiert. MyAssembly.Core.dll (v1.0) ist nicht installiert, da sie nicht im net45 Ordner aufgeführt ist. NuGet verhält sich auf diese Weise, weil MyAssembly.Core.dll vielleicht in die Version 2.0 von MyAssembly.dll eingeflossen ist.

Wenn Sie möchten, dass MyAssembly.Core.dll für das .NET Framework 4.5 installiert wird, platzieren Sie eine Kopie im net45 Ordner.

Gruppieren von Assemblys nach Frameworkprofil

NuGet unterstützt auch das Ausrichten eines bestimmten Frameworkprofils, indem ein Gedankenstrich und der Profilname am Ende des Ordners angefügt werden.

lib{framework name}-{profile}

Die unterstützten Profile sind wie folgt:

  • client: Clientprofil
  • full: Vollständiges Profil
  • wp:Windows Phone
  • cf: Compact Framework

Deklarieren von Abhängigkeiten (Erweitert)

Beim Packen einer Projektdatei versucht NuGet, die Abhängigkeiten aus dem Projekt automatisch zu generieren. Die Informationen in diesem Abschnitt zur Verwendung einer NUSPEC-Datei zum Deklarieren von Abhängigkeiten sind in der Regel nur für erweiterte Szenarien erforderlich.

(Version 2.0+) Sie können Paketabhängigkeiten in der Nuspec deklarieren, die dem Zielframework des Zielprojekts entsprechen, indem <group> Sie Elemente innerhalb des <dependencies> Elements verwenden. Weitere Informationen finden Sie unter Abhängigkeiten-Element.

Jede Gruppe hat ein Attribut namens targetFramework und enthält null oder mehr <dependency> Elemente. Diese Abhängigkeiten werden zusammen installiert, wenn das Zielframework mit dem Frameworkprofil des Projekts kompatibel ist. Sehen Sie Zielframeworks für die genauen Framework-Bezeichner.

Wir empfehlen die Verwendung einer Gruppe pro Target Framework Moniker (TFM) für Dateien in den lib/ und ref/ folders.

Das folgende Beispiel zeigt unterschiedliche Variationen des <group> Elements:

<dependencies>

    <group targetFramework="net472">
        <dependency id="jQuery" version="1.10.2" />
        <dependency id="WebActivatorEx" version="2.2.0" />
    </group>

    <group targetFramework="net20">
    </group>

</dependencies>

Bestimmen des zu verwendenden NuGet-Ziels

Beim Packen von Bibliotheken, die auf die portable Klassenbibliothek abzielen, kann es schwierig sein, zu bestimmen, welches NuGet-Ziel Sie in Ihren Ordnernamen und .nuspec -dateien verwenden sollten, insbesondere, wenn nur eine Teilmenge der PCL verwendet werden soll. Die folgenden externen Ressourcen helfen Ihnen dabei:

Inhaltsdateien und PowerShell-Skripts

Warnung

Änderbare Inhaltsdateien und Skriptausführung sind nur im packages.config Format verfügbar. Sie sind mit allen anderen Formaten veraltet und sollten nicht für neue Pakete verwendet werden.

Mit packages.config, Inhaltsdateien und PowerShell-Skripts können nach Zielframework gruppiert werden, indem sie dieselbe Ordnerkonvention innerhalb der content Ordner und tools Ordner verwenden. Beispiel:

\content
    \net46
        \MyContent.txt
    \net461
        \MyContent461.txt
    \uap
        \MyUWPContent.html
    \netcore
\tools
    init.ps1
    \net46
        install.ps1
        uninstall.ps1
    \uap
        install.ps1
        uninstall.ps1

Wenn ein Frameworkordner leer bleibt, fügt NuGet keine Assemblyverweise oder Inhaltsdateien hinzu und führt auch keine PowerShell-Skripte für dieses Framework aus.

Hinweis

Da init.ps1 auf Lösungsebene ausgeführt wird und nicht vom Projekt abhängig ist, muss sie direkt unter dem tools Ordner platziert werden. Sie wird ignoriert, wenn sie unter einem Frameworkordner platziert wird.

  • Last updated on