Freigeben über

Packen einer Verteilung von .NET

Da .NET 5 (und .NET Core) und höhere Versionen auf mehr und mehr Plattformen verfügbar sind, ist es hilfreich zu erfahren, wie Sie Anwendungen und Bibliotheken, die diese verwenden, packen, benennen und mit einer Versionsnummer versehen. Auf diese Weise kann mithilfe von Paketverwaltern eine konsistente Benutzererfahrung sichergestellt werden, unabhängig davon, wo Benutzer .NET ausführen. Dieser Artikel ist für Benutzer hilfreich, die

  • versuchen, .NET von der Quelle aus zu erstellen.
  • Änderungen an der .NET-CLI vornehmen möchten, die sich auf das resultierende Layout oder die erzeugten Pakete auswirken könnten.

Datenträgerlayout

.NET besteht aus mehreren Komponenten, die im Dateisystem folgendermaßen angeordnet sind:

{dotnet_root}                    (0)              (*)
├── dotnet                       (1)
├── dnx                          (22)
├── LICENSE.txt                  (8)
├── ThirdPartyNotices.txt        (8)
├── host                                          (*)
│   └── fxr                                       (*)
│       └── <fxr version>        (2)
├── sdk                                           (*)
│   └── <sdk version>            (3)
├── sdk-manifests                (4)              (*)
│   └── <sdk feature band version>
├── library-packs                (21)             (*)
├── metadata                     (4)              (*)
│   └── workloads
│       └── <sdk feature band version>
├── template-packs               (4)              (*)
├── packs                                         (*)
│   ├── Microsoft.AspNetCore.App.Ref              (*)
│   │   └── <aspnetcore ref version>     (11)
│   ├── Microsoft.NETCore.App.Ref                 (*)
│   │   └── <netcore ref version>        (12)
│   ├── Microsoft.NETCore.App.Host.<rid>          (*)
│   │   └── <apphost version>            (13)
│   ├── Microsoft.WindowsDesktop.App.Ref          (*)
│   │   └── <desktop ref version>        (14)
│   ├── NETStandard.Library.Ref                   (*)
│   │   └── <netstandard version>        (15)
│   ├── Microsoft.NETCore.App.Runtime.<rid>       (*)
│   │   └── <runtime version>            (18)
│   ├── Microsoft.AspNetCore.App.Runtime.<rid>    (*)
│   │   └── <aspnetcore version>         (18)
│   ├── runtime.<rid>.Microsoft.DotNet.ILCompiler (*)
│   │   └── <runtime version>            (19)
│   └── Microsoft.NETCore.App.Runtime.NativeAOT.<rid> (*)
│       └── <runtime version>            (20)
├── shared                                        (*)
│   ├── Microsoft.NETCore.App                     (*)
│   │   └── <runtime version>     (5)
│   ├── Microsoft.AspNetCore.App                  (*)
│   │   └── <aspnetcore version>  (6)
│   ├── Microsoft.AspNetCore.All                  (*)
│   │   └── <aspnetcore version>  (6)
│   └── Microsoft.WindowsDesktop.App              (*)
│       └── <desktop app version> (7)
└── templates                                     (*)
│   └── <templates version>      (17)
/
├── etc/dotnet
│       └── install_location     (16)
├── usr/share/man/man1
│       └── dotnet.1.gz          (9)
└── usr/bin
        └── dotnet               (10)
        └── dnx                  (23)

  • (0) {dotnet_root} ist ein gemeinsam genutzter Stamm für alle Haupt- und Nebenversionen von .NET. Wenn mehrere Runtimes installiert sind, nutzen sie den {dotnet_root}-Ordner gemeinsam, z. B. {dotnet_root}/shared/Microsoft.NETCore.App/6.0.11 und {dotnet_root}/shared/Microsoft.NETCore.App/7.0.0. Der Name des {dotnet_root}-Ordners sollte versionsunabhängig sein, also einfach dotnet lauten.

  • (1) dotnet: Der Host (auch bekannt als „Muxer“) führt zwei unterschiedliche Rollen aus: das Aktivieren einer Runtime, um eine Anwendung zu starten, und das Aktivieren eines SDK, um Befehle an dieses weiterzuleiten. Der Host ist eine native ausführbare Datei (dotnet.exe).

  • (22) dnx Das dnx Skript ist ein ausführbares Shellskript, dessen Zweck es ist, Benutzerbefehle an den dotnet dnx Befehl innerhalb eines SDK weiterzuleiten. Diese Funktionalität besteht in erster Linie darin, verschiedene Arten von .NET-Anwendungen wie .NET Tools für Endbenutzer zu erwerben und zu starten. Stellen Sie sich dies ähnlich wie der npx Befehl von Node vor. Es ist versionsunabhängig, da die meisten der tatsächlichen Funktionen des dnx One-Shot-Ausführungsprozesses in der dotnet CLI-Implementierung im versionsgesteuerten SDK-Verzeichnis behandelt werden.

Es gibt nur einen Host, die meisten anderen Komponenten befinden sich jedoch in Verzeichnissen mit Versionsangabe (2, 3, 5, 6). Das bedeutet, dass auf dem System mehrere Versionen vorhanden sein können, da sie nebeneinander installiert werden können.

  • (2) host/fxr/<fxr version> enthält die vom Host verwendete Framework-Auflösungslogik. Der Host verwendet die neueste installierte hostfxr-Version. „hostfxr“ ist für die Auswahl der geeigneten Runtime beim Ausführen einer .NET-Anwendung zuständig. Eine Anwendung, die für .NET 7.0.0 erstellt wurde, verwendet beispielsweise die Runtime 7.0.5, wenn sie verfügbar ist. Ebenso wählt „hostfxr“ während der Entwicklung das geeignete SDK aus.

  • (3) sdk/<sdk version>: Das SDK (auch bekannt als „die Tools“) ist ein Satz verwalteter Tools, die zum Schreiben und Erstellen von .NET-Bibliotheken und -Anwendungen verwendet werden. Das SDK enthält die .NET-CLI, die verwalteten Sprachcompiler, MSBuild und zugehörige Buildtasks und -ziele, NuGet, neue Projektvorlagen usw.

  • (4) sdk-manifests/<sdk feature band version>: Die Namen und Versionen der Ressourcen, die für eine optionale Workloadinstallation erforderlich sind, werden in Workloadmanifesten verwaltet, die in diesem Ordner gespeichert sind. Der Ordnername ist die Featurebandversion des SDK. Für eine SDK-Version wie 7.0.102 würde dieser Ordner also weiterhin 7.0.100 heißen. Wenn eine Workload installiert ist, the following folders are created as needed für the workload's assets: metadata and template-packs. Eine Distribution kann eine leere /metadata/workloads/<sdkfeatureband>/userlocal-Datei erstellen, wenn die Workloads statt im dotnet-Ordner in einem Benutzerpfad installiert werden sollen. Weitere Informationen finden Sie im GitHub-Issue dotnet/installer#12104.

Der Ordner shared enthält Frameworks. Ein gemeinsames (shared) Framework stellt einen Satz Bibliotheken an einem zentralen Speicherort bereit, sodass diese von verschiedenen Anwendungen verwendet werden können.

  • (5) shared/Microsoft.NETCore.App/<runtime version>: Dieses Framework enthält die .NET-Runtime und die unterstützenden verwalteten Bibliotheken.

  • (6) shared/Microsoft.AspNetCore.{App,All}/<aspnetcore version> enthält die ASP.NET Core-Bibliotheken. Die Bibliotheken unter Microsoft.AspNetCore.App werden im Rahmen des .NET-Projekts entwickelt und unterstützt. Die Bibliotheken unter Microsoft.AspNetCore.All sind ein übergeordnetes Set, das auch Drittanbieterbibliotheken enthält.

  • (7) shared/Microsoft.Desktop.App/<desktop app version> enthält die Windows-Desktopbibliotheken. Dies ist nur in Windows enthalten, und nicht in anderen Plattformen.

  • (8) LICENSE.txt,ThirdPartyNotices.txt: Dies sind die .NET-Lizenzen und die Lizenzen von Drittanbieterbibliotheken, die in .NET verwendet werden.

  • (9,10, 23) dotnet.1.gz, dotnetdotnet.1.gz ist die manuelle Dotnet-Seite. dotnet ist ein Symlink auf den dotnet-Host(1). dnx ist ein Symlink zum dnx Shellskript (22). Diese Dateien werden zur Systemintegration an bekannten Speicherorten installiert.

  • (11,12) Microsoft.NETCore.App.Ref,Microsoft.AspNetCore.App.Ref beschreibt jeweils die API einer x.y-Version von .NET und ASP.NET Core. Diese Pakete werden bei der Kompilierung für diese Zielversionen verwendet.

  • (13) Microsoft.NETCore.App.Host.<rid> enthält eine native Binärdatei für die Plattform rid. Diese Binärdatei ist eine Vorlage für das Kompilieren einer .NET-Anwendung in eine native Binärdatei für diese Plattform.

  • (14) Microsoft.WindowsDesktop.App.Ref beschreibt die API der x.y-Version von Windows-Desktopanwendungen. Diese Dateien werden beim Kompilieren für dieses Ziel verwendet. Dies wird nur unter Windows bereitgestellt, und nicht für andere Plattformen.

  • (15) NETStandard.Library.Ref beschreibt die NetStandard-API x.y. Diese Dateien werden beim Kompilieren für dieses Ziel verwendet.

  • (16) /etc/dotnet/install_location ist eine Datei, die den vollständigen Pfad für {dotnet_root} enthält. Der Pfad kann mit einem Zeilenvorschubzeichen enden. Es ist nicht erforderlich, diese Datei hinzuzufügen, wenn /usr/share/dotnet das Stammverzeichnis ist.

  • (17) templates enthält die Vorlagen, die vom SDK verwendet werden. Beispielsweise ermittelt dotnet new Projektvorlagen in diesem Ordner.

  • (18) Microsoft.NETCore.App.Runtime.<rid>/<runtime version,Microsoft.AspNetCore.App.Runtime>.<rid>/<aspnetcore Version> Diese Dateien ermöglichen das Erstellen eigenständiger Anwendungen. Diese Verzeichnisse enthalten symbolische Verknüpfungen zu Dateien in (2), (5) und (6).

  • (19) runZeit.<rid>.Microsoft.DotNet.ILCompiler/<runZeit version> These files enable building NativeAOT applications on the target Plattform. In .NET 9 können NativeAOT-Anwendungen auch für die Zielplattform erstellt werden. Kann in .NET 9 und höher vorhanden sein.

  • (20) Microsoft.NETCore.App.Runtime.NativeAOT.<Rid>/<Runtime-Version> Diese Dateien ermöglichen das Erstellen von NativeAOT-Anwendungen für die Zielplattform. Kann in .NET 10 und höher vorhanden sein.

  • (21) Bibliothekspakete enthalten NuGet-Paketdateien . Das SDK ist so konfiguriert, dass es diesen Ordner als NuGet-Quelle verwendet. Die Liste der NuGet-Pakete, die von einem .NET-Build bereitgestellt werden, ist unten beschrieben.

Die mit (*) markierten Ordner werden von mehreren Paketen verwendet. Einige Paketformate (z.B. rpm) erfordern eine besondere Verarbeitung solcher Ordner. Der Paketmaintainer muss dafür Sorge tragen.

Paketdateien, die zu library-packs (21) hinzugefügt wurden, können Pakete sein, die Microsoft nicht für die Zielplattform verteilt. Bei den Dateien kann es sich auch um Pakete handeln, die von Microsoft vertrieben werden und für die library-packs ein Paket bereitgestellt wird, das aus dem Quellcode erstellt wurde, um die Richtlinien für die Verteilung von Plattformpaketen zu erfüllen. distribution guidelines. Die folgenden Pakete sind in einem .NET-Build enthalten:

Paketname Veröffentlicht von Microsoft Erforderlich für
Microsoft.DotNet.ILCompiler.<version>.nupkg
Microsoft.NET.ILLink.Tasks.<version>.nupkg		 ☑ NativeAOT

Die .NET-Versionsverwaltung basiert auf dem Versionsnummernmuster [major].[minor] der Runtimekomponente. Die SDK-Version verwendet das gleiche [major].[minor]-Muster und weist eine unabhängige [patch]-Zeichenfolge auf, die die Feature- und Patchsemantik für das SDK kombiniert. Beispiel: Die SDK-Version 7.0.302 ist das zweite Patchrelease des dritten Featurerelease des SDK, das die Runtimeversion 7.0 unterstützt. Weitere Informationen zur Funktionsweise der Versionsverwaltung finden Sie unter .NET-Versionskontrolle: Übersicht.

Einige Pakete enthalten einen Teil der Versionsnummer im Namen. Dies ermöglicht Ihnen, eine bestimmte Version zu installieren. Der Rest der Version ist im Versionsnamen nicht enthalten. Dies ermöglicht dem Paket-Manager des Betriebssystems, die Pakete zu aktualisieren (z.B. durch automatisches Installieren von Sicherheitsfixes). Unterstützte Paket-Manager sind Linux-spezifisch.

Im Folgenden werden die empfohlenen Pakete aufgeführt:

  • dotnet-sdk-[major].[minor] - Installiert das neueste SDK für eine bestimmte Laufzeit

    • Version:<SDK-Version>
    • Beispiel: dotnet-sdk-7.0
    • Enthält: (3),(4),(18);(21)
    • Abhängigkeiten:dotnet-runtime-[major].[minor], aspnetcore-runtime-[major].[minor], dotnet-targeting-pack-[major].[minor], aspnetcore-targeting-pack-[major].[minor], netstandard-targeting-pack-[netstandard_major].[netstandard_minor], dotnet-apphost-pack-[major].[minor], dotnet-templates-[major].[minor]

  • dotnet-sdk-aot-[major].[minor] - Installiert die SDK-Komponenten für die Plattform NativeAOT

    • Version:<SDK-Version>
    • Beispiel: dotnet-sdk-aot-9.0
    • Enthält: (19, 20)
    • Abhängigkeiten:dotnet-sdk-[major].[minor], compiler toolchain and developer packages für libraries that the .NET runZeit depends on

  • aspnetcore-runtime-[major].[minor] - Installiert eine bestimmte ASP.NET Core-Laufzeitumgebung

    • Version:<aspnetcore runZeit version>
    • Beispiel: aspnetcore-runZeit-7.0
    • Enthält: (6)
    • Abhängigkeiten:dotnet-runtime-[major].[minor]

  • dotnet-runtime-deps-[major].[minor] (Optional) - Installiert die Abhängigkeiten für die Ausführung von eigenständigen Anwendungen

    • Version:<runZeit version>
    • Beispiel: dotnet-runZeit-deps-7.0
    • Abhängigkeiten:distribution-specific dependencies

  • dotnet-runtime-[major].[minor] - Installiert eine bestimmte Laufzeitumgebung

    • Version:<runZeit version>
    • Beispiel: dotnet-runZeit-7.0
    • Enthält: (5)
    • Abhängigkeiten:dotnet-hostfxr-[major].[minor], dotnet-runtime-deps-[major].[minor]

  • dotnet-hostfxr-[major].[minor] - Abhängigkeit

    • Version:<runZeit version>
    • Beispiel: dotnet-hostfxr-7.0
    • Enthält: (2)
    • Abhängigkeiten:dotnet-host

  • dotnet-host - Abhängigkeit

    • Version:<runZeit version>
    • Beispiel: dotnet-host
    • Enthält: (1),(8);(9);(10);(16);(22);(23)

  • dotnet-apphost-pack-[major].[minor] - Abhängigkeit

    • Version:<runZeit version>
    • Enthält: (13)

  • dotnet-targeting-pack-[major].[minor] - Erlaubt die Ausrichtung auf eine nicht-aktuelle Laufzeit

    • Version:<runZeit version>
    • Enthält: (12)

  • aspnetcore-targeting-pack-[major].[minor] - Erlaubt die Ausrichtung auf eine nicht-aktuelle Laufzeit

    • Version:<aspnetcore runZeit version>
    • Enthält: (11)

  • netstandard-targeting-pack-[netstandard_major].[netstandard_minor] - Erlaubt die Ausrichtung auf eine Netzstandardversion

    • Version:<SDK-Version>
    • Enthält: (15)

  • dotnet-templates-[major].[minor]

    • Version:<SDK-Version>
    • Enthält: (17)

Die folgenden beiden Metapakete sind optional. Sie sind hilfreich für Endbenutzer, da sie das Paket der obersten Ebene (dotnet-sdk) abstrahieren, wodurch die Installation des vollständigen Satzes an .NET-Paketen vereinfacht wird. Diese Metapakete verweisen auf eine bestimmte .NET SDK-Version.

  • dotnet[major] - Installiert die angegebene SDK-Version

    • Version:<SDK-Version>
    • Beispiel: dotnet7
    • Abhängigkeiten:dotnet-sdk-[major].[minor]

  • dotnet Installiert eine bestimmte SDK-Version, die von Distros als primäre Version festgelegt wurde – in der Regel die neueste verfügbare Version.

    • Version:<SDK-Version>
    • Beispiel: dotnet
    • Abhängigkeiten:dotnet-sdk-[major].[minor]

Für dotnet-runtime-deps-[major].[minor] ist ein Verständnis der distributionsspezifischen Abhängigkeiten erforderlich. Da das Buildsystem der Verteilung dies möglicherweise automatisch ableiten kann, ist das Paket optional. In diesem Falle werden diese Abhängigkeiten direkt zum dotnet-runtime-[major].[minor]-Paket hinzugefügt.

Wenn Paketinhalte sich in einem Ordner mit Versionsangabe befinden, stimmt der Paketname [major].[minor] mit der Ordnernamen mit Versionsangabe überein. Für alle Pakete (außer netstandard-targeting-pack-[netstandard_major].[netstandard_minor]) stimmt dieser auch mit der .NET-Version überein.

Abhängigkeiten zwischen Paketen sollten eine identische oder höhere erforderliche Version verwenden. dotnet-sdk-7.0:7.0.401 erfordert beispielsweise aspnetcore-runtime-7.0 >= 7.0.6. Dies ermöglicht es dem Benutzer, für seine Installation ein Upgrade mithilfe eines Stammpakets (z.B. dnf update dotnet-sdk-7.0) durchzuführen.

Für die meisten Verteilungen müssen alle Artefakte aus der Quelle erstellt werden. Dies wirkt sich auf die Pakete aus:

  • Die Drittanbieterbibliotheken unter shared/Microsoft.AspNetCore.All können nicht einfach aus der Quelle erstellt werden. Daher ist dieser Ordner im aspnetcore-runtime-Paket nicht enthalten.

  • Der NuGetFallbackFolder wird mithilfe von binären Artefakten aus nuget.org aufgefüllt. Der Ordner sollte leer bleiben.

Möglicherweise stellen mehrere dotnet-sdk-Pakete die gleichen Dateien für den NuGetFallbackFolder bereit. Um Probleme mit dem Paket-Manager zu vermeiden, sollten diese Dateien identisch sein (Prüfsumme, Änderungsdatum usw.).

Debugpakete

Debuginhalte sollten in Debug-benannte Paketen gepackt werden, die auf die .NET-Paketteilung folgen, die zuvor in diesem Artikel beschrieben wurde. Beispiel: Debuginhalt für das dotnet-sdk-[major].[minor]-Paket sollte in ein Paket mit dem Namen dotnet-sdk-dbg-[major].[minor] eingeschlossen werden. Sie sollten Debuginhalte an demselben Speicherort wie die Binärdateien installieren.

Hier sind einige binäre Beispiele:

Im {dotnet_root}/sdk/<sdk version>-Verzeichnis werden die folgenden beiden Dateien erwartet:

  • dotnet.dll - installiert mit dotnet-sdk-[major].[minor] package
  • dotnet.pdb - installiert mit dotnet-sdk-dbg-[major].[minor] package

Im {dotnet_root}/shared/Microsoft.NETCore.App/<runtime version>-Verzeichnis werden die folgenden beiden Dateien erwartet:

  • System.Text.Json.dll - installiert mit dotnet-runtime-[major].[minor] package
  • System.Text.Json.pdb - installiert mit dotnet-runtime-dbg-[major].[minor] package

Im {dotnet_root/shared/Microsoft.AspNetCore.App/<aspnetcore version>-Verzeichnis werden die folgenden beiden Dateien erwartet:

  • Microsoft.AspNetCore.Routing.dll - installiert mit aspnetcore-runtime-[major].[minor] packages
  • Microsoft.AspNetCore.Routing.pdb - installiert mit aspnetcore-runtime-dbg-[major].[minor] packages

Ab .NET 8.0 sind alle .NET-Debuginhalte (PDB-Dateien), die von Source-Build erstellt werden, in einem Tarball mit dem Namen dotnet-symbols-sdk-<version>-<rid>.tar.gz verfügbar. Dieses Archiv enthält PDBs in Unterverzeichnissen, die der Verzeichnisstruktur des .NET SDK Tarball dotnet-sdk-<version>-<rid>.tar.gz entsprechen.

Während alle Debuginhalte im Debug-Tarball verfügbar sind, sind nicht alle Debuginhalte gleichermaßen wichtig. Endbenutzer interessieren sich hauptsächlich für den Inhalt der shared/Microsoft.AspNetCore.App/<aspnetcore version>- und shared/Microsoft.NETCore.App/<runtime version>-Verzeichnisse.

Der folgende SDK-Inhalt unter sdk/<sdk version> eignet sich zum Debuggen von .NET SDK-Toolsets.

Die folgenden Pakete sind die empfohlenen Debugpakete:

  • aspnetcore-runtime-dbg-[major].[minor] - Installiert Debug-Inhalte für eine bestimmte ASP.NET Core-Laufzeit

    • Version:<aspnetcore runZeit version>
    • Beispiel: aspnetcore-runZeit-dbg-8.0
    • Enthält: debug content für (6)
    • Abhängigkeiten:aspnetcore-runtime-[major].[minor]

  • dotnet-runtime-dbg-[major].[minor] - Installiert Debug-Inhalte für eine bestimmte Laufzeit

    • Version:<runZeit version>
    • Beispiel: dotnet-runZeit-dbg-8.0
    • Enthält: debug content für (5)
    • Abhängigkeiten:dotnet-runtime-[major].[minor]

Das folgende Debugpaket ist optional:

  • dotnet-sdk-dbg-[major].[minor] - Installiert Debug-Inhalte für eine bestimmte SDK-Version
    • Version:<SDK-Version>
    • Beispiel: dotnet-sdk-dbg-8.0
    • Enthält: debug content für (3),(4),(18)
    • Abhängigkeiten:dotnet-sdk-[major].[minor]

Der Debug-Tarball enthält auch einige Debuginhalte unter packs, die Kopien von Inhalten unter shared darstellen. Im .NET-Layout wird das packs-Verzeichnis zum Erstellen von .NET-Anwendungen verwendet. Es gibt keine Debugszenarien, daher sollten Sie den Debuginhalt nicht unter packs in dem Debug-Tarball verpacken.

Erstellen von Paketen

Das Repository dotnet/source-build stellt Anweisungen zum Erstellen eines Quell-Tarballs des .NET SDK und aller zugehörigen Komponenten bereit. Die Ausgabe des source-build-Repositorys entspricht der Anordnung, die im ersten Abschnitt dieses Artikels beschrieben wurde.