Erstellen eines Pakets mithilfe der nuget.exe CLI

Unabhängig davon, was Ihr Paket tut oder welchen Code es enthält, verwenden Sie eines der Befehlszeilenschnittstellentools (Command-Line Interface, nuget.exe CLI) oder dotnet.exe, um diese Funktionalität in eine Komponente zu packen, die für andere Entwickler freigegeben und verwendet werden kann. Informationen zum Installieren von NuGet CLI-Tools finden Sie unter Installieren von NuGet-Clienttools. Visual Studio enthält nicht automatisch ein CLI-Tool.

• Führen Sie die beschriebenen Schritte in diesem Artikel aus, um ein Paket zu erstellen, wenn es sich um Projekte im Nicht-SDK-Stil handelt, typischerweise .NET Framework-Projekte. Eine Schnellstartanleitung mit Schritt-für-Schritt-Anleitungen zur Verwendung von Visual Studio und der nuget.exe CLI finden Sie unter Quickstart: Erstellen und Veröffentlichen eines Pakets mithilfe von Visual Studio (.NET Framework, Windows).

• Informationen zu .NET Core- und .NET Standardprojekten, die das Format SDK-format und andere PROJEKTE im SDK-Stil verwenden, finden Sie unter Create a NuGet package with the dotnet CLI.

• Verwenden Sie für Projekte, die von packages.config zu PackageReference migriert wurden, den msbuild -t:pack-Befehl.

Technisch gesehen ist ein NuGet-Paket eine ZIP-Datei, die umbenannt wurde, um die Erweiterung .nupkg zu erhalten, und deren Inhalte bestimmten Konventionen entsprechen müssen. In diesem Artikel wird der detaillierte Prozess zum Erstellen eines Pakets beschrieben, das diesen Konventionen entspricht.

Das Verpacken beginnt mit dem kompilierten Code (Assemblys), Symbolen und anderen Dateien, die Sie als Paket bereitstellen möchten. Eine Übersicht über den Paketerstellungsprozess finden Sie im Paketerstellungsworkflow. Dieser Prozess ist unabhängig von der Kompilierung oder anderweitigen Generierung der Dateien, die in das Paket eingefügt werden. Sie können jedoch aus Informationen in einer Projektdatei ziehen, um die kompilierten Assemblys und Pakete synchron zu halten.

Entscheiden, welche Assemblys verpackt werden sollen

Die meisten allgemeinen Pakete enthalten eine oder mehrere Assemblys, die andere Entwickler in ihren eigenen Projekten verwenden können.

Im Allgemeinen empfiehlt es sich, eine Assembly pro NuGet-Paket zu verwenden, vorausgesetzt, jede Assembly ist unabhängig voneinander nützlich. Betrachten Sie beispielsweise die folgenden Fälle, in denen eine Assembly namens Utilities.dll einbezogen wird, die von einer Assembly mit dem Namen Parser.dllabhängt:

• Wenn Parser.dll eigenständig nützlich ist, erstellen Sie ein Paket für Utilities.dll und ein Paket für Parser.dll. Auf diese Weise können Entwickler Parser.dll unabhängig von Utilities.dllverwenden.

• Wenn Parser.dll Code enthält, der nur von Utilities.dllverwendet wird, ist es in Ordnung, Parser.dll im selben Paket beizubehalten. Wenn Ihre Bibliothek aus mehreren Assemblys besteht, die nicht unabhängig voneinander nützlich sind, ist es in Ordnung, sie in einem Paket zu kombinieren.

• Wenn Utilities.dll auch von Utilities.resources.dllabhängt und Utilities.resources.dll nicht allein nützlich ist, setzen Sie beide in das gleiche Paket.

Ressourcen, z. B. die Utilities.resources.dll Assembly im vorherigen Beispiel, sind ein Sonderfall. Wenn ein Paket in einem Projekt installiert wird, fügt NuGet automatisch Assemblyverweise zu den DLLs des Pakets hinzu, mit Ausnahme derjenigen, die .resources.dllgenannt werden, da davon ausgegangen wird, dass sie lokalisierte Satellitenassemblys sind. Weitere Informationen zu lokalisierten Versionen einer Bibliothek finden Sie unter Erstellen lokalisierter NuGet-Pakete. Vermeiden Sie aus diesem Grund die Verwendung von.resources.dll für Dateien, die wesentlichen Paketcode enthalten.

Wenn Ihre Bibliothek Interopassemblys (COMPONENT Object Model, COM) enthält, befolgen Sie die zusätzlichen Richtlinien in "NuGet-Pakete erstellen", die COM-Interopassemblys enthalten.

Die Rolle und Struktur der NUSPEC-Datei

Wenn Sie wissen, welche Dateien Sie packen möchten, besteht der nächste Schritt darin, ein Paketmanifest in einer NUSPEC-XML-Datei zu erstellen.

Das Manifest:

• Beschreibt den Inhalt des Pakets und ist selbst im Paket enthalten.
• Steuert die Erstellung des Pakets und teilt NuGet mit, wie das Paket in einem Projekt installiert wird. Das Manifest identifiziert beispielsweise andere Paketabhängigkeiten, sodass NuGet diese Abhängigkeiten auch installieren kann, wenn das Hauptpaket installiert wird.
• Enthält sowohl erforderliche als auch optionale Eigenschaften, wie im restlichen Abschnitt beschrieben. Ausführliche Informationen, einschließlich anderer hier nicht erwähnter Eigenschaften, finden Sie unter .nuspec reference.

Die folgenden Eigenschaften sind im Manifest erforderlich:

• Der Paketbezeichner, der in der Galerie, in der das Paket gehostet wird, eindeutig sein muss.
• Eine bestimmte Versionsnummer im Format Major.Minor.Patch[-Suffix], wobei -SuffixVorabversionen identifiziert
• Der Pakettitel, wie er auf dem Host angezeigt werden soll (z. B. nuget.org)
• Autoreninformationen
• Eine lange Beschreibung des Pakets

Die folgenden Eigenschaften sind häufig optionale:

• Versionshinweise.
• Copyright-Informationen.
• Eine kurze Beschreibung für die benutzeroberfläche Paket-Manager in Visual Studio.
• Eine Gebietsschema-ID.
• Eine Projekt-URL.
• Eine Lizenz als Ausdruck oder Datei. Die licenseUrl Eigenschaft ist veraltet. Verwenden Sie stattdessen daslicense Nuspec-Metadatenelement.
• Readme-Datei.
• Eine Symboldatei. Die iconUrl Eigenschaft ist veraltet. Verwenden Sie stattdessen dasicon Nuspec-Metadatenelement.
• Listen von Abhängigkeiten und Verweisen.
• Tags, die bei Katalogsuchen helfen.

Der folgende Code ist eine typische (aber fiktive) Nuspec-Datei mit Kommentaren, die die Eigenschaften beschreiben:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
    <metadata>
        <!-- An identifier that must be unique within the hosting gallery -->
        <id>Contoso.Utility.UsefulStuff</id>

        <!-- A package version number that's used when resolving dependencies -->
        <version>1.8.3</version>

        <!-- A comma-separated list of package authors that sometimes appears directly on the gallery -->
        <authors>Dejana Tesic, Rajeev Dey</authors>

        <!-- A project URL that provides a link for the gallery -->
        <projectUrl>http://github.com/contoso/UsefulStuff</projectUrl>

        <!-- License information that's displayed on the gallery -->
        <license type="expression">Apache-2.0</license>
        
        <!-- The location of a read-me file that's displayed in the Visual Studio Package Manager UI -->
        <readme>readme.md</readme>

        <!-- An icon that's used in the Visual Studio Package Manager UI -->
        <icon>icon.png</icon>

        <!-- 
            A property that when true, prompts the user to accept the license when
            installing the package
        -->
        <requireLicenseAcceptance>false</requireLicenseAcceptance>

        <!-- Detailed information about a particular release -->
        <releaseNotes>Bug fixes and performance improvements</releaseNotes>

        <!-- 
            A description that can be used in the Package Manager UI. The
            nuget.org gallery uses information you add in the portal. 
        -->
        <description>Core utility functions for web applications</description>

        <!-- Copyright information -->
        <copyright>Copyright ©2026 Contoso Corporation</copyright>

        <!-- Tags that appear in the gallery and can be used for tag searches -->
        <tags>web utility http json url parsing</tags>

        <!-- Dependencies that are automatically installed when the package is installed -->
        <dependencies>
            <dependency id="Newtonsoft.Json" version="9.0" />
        </dependencies>
    </metadata>

    <!-- A read-me Markdown file that's displayed in the Package Manager UI -->
    <files>
        <file src="readme.md" target="" />
        <file src="icon.png" target="" />
    </files>
</package>

Ausführliche Informationen zum Deklarieren von Abhängigkeiten und angeben von Versionsnummern finden Sie unter packages.config und Paketversionsverwaltung. Sie können auch die Attribute include und exclude auf dem dependency-Element verwenden, um die Abhängigkeitsressourcen anzugeben, die Sie im Paket ein- oder ausschließen möchten. Weitere Informationen finden Sie unter ".nuspec Reference - Dependencies"-Element.

Da das Manifest im darin erstellten Paket enthalten ist, finden Sie Beispiele, indem Sie vorhandene Pakete untersuchen. Eine gute Quelle ist der Ordner "Globale Pakete" auf Ihrem Computer. Verwenden Sie den folgenden Befehl, um den Speicherort zu finden:

nuget locals -list global-packages

Nachdem Sie den Speicherort des Ordners "Globale Pakete " kennen, führen Sie die folgenden Schritte aus, um eine Manifestdatei zu finden:

1. Wechseln Sie zum Ordner "Globale Pakete" .
2. Wechseln Sie in diesem Ordner zum Unterordner für ein beliebiges Paket, und wechseln Sie dann zu einem Unterordner für eine beliebige Version dieses Pakets.
3. Erstellen Sie im Versionsunterordner eine Kopie der nupkg-Datei , und ändern Sie die Erweiterung der Kopie in ZIP.
4. Öffnen Sie die .zip Datei, und untersuchen Sie die NUSPEC-Datei darin.

Erstellen der NUSPEC-Datei

Das Erstellen eines vollständigen Manifests beginnt in der Regel mit einer einfachen NUSPEC-Datei , die über eine der folgenden Methoden generiert wird:

• Ein konventionsbasiertes Arbeitsverzeichnis
• Eine Assembly-DLL
• A Visual Studio Projekt
• Eine neue Datei mit Standardwerten

Anschließend bearbeiten Sie die Datei manuell, sodass sie den genauen Inhalt beschreibt, den Sie im endgültigen Paket benötigen.

Aus einem konventionsbasierten Arbeitsverzeichnis

Da es sich bei einem NuGet-Paket um eine ZIP-Datei handelt, die mit der Erweiterung nupkg umbenannt wurde, ist es häufig am einfachsten, die gewünschte Ordnerstruktur im lokalen Dateisystem zu erstellen und dann die NUSPEC-Datei direkt aus dieser Struktur zu erstellen. Der nuget pack Befehl fügt dann automatisch alle Dateien in dieser Ordnerstruktur hinzu, schließt jedoch alle Ordner aus, die mit einem Punkt beginnen, sodass Sie private Dateien in derselben Struktur beibehalten können.

Der Vorteil dieses Ansatzes besteht darin, dass Sie nicht im Manifest angeben müssen, welche Dateien sie in das Paket aufnehmen möchten, wie weiter unten in diesem Abschnitt erläutert. Stattdessen lassen Sie Ihren Buildprozess die genaue Ordnerstruktur erzeugen, die im Paket enthalten sein wird. Sie können auch problemlos andere Dateien einschließen, die möglicherweise nicht Teil eines Projekts sind, andernfalls:

• Inhalt und Quellcode, der in das Zielprojekt eingefügt werden soll
• PowerShell-Skripts
• Transformationen in vorhandene Konfigurations- und Quellcodedateien in einem Projekt

Die Ordner entsprechen den folgenden Konventionen:

Da Ihre Ordnerstruktur Assemblys für viele Zielframeworks enthalten kann, ist diese Methode erforderlich, wenn Sie Pakete erstellen, die mehrere Frameworks unterstützen.

Wenn Sie die gewünschte Ordnerstruktur eingerichtet haben, führen Sie den folgenden Befehl in diesem Ordner aus, um die NUSPEC-Datei zu erstellen:

nuget spec

Die generierte NUSPEC-Datei enthält keine expliziten Verweise auf Dateien in der Ordnerstruktur. NuGet enthält automatisch alle Dateien, wenn das Paket erstellt wird. Sie müssen jedoch weiterhin Platzhalterwerte in anderen Teilen des Manifests bearbeiten.

Aus einer Assembly-DLL

Im Grundfall beim Erstellen eines Pakets aus einer Assembly können Sie mithilfe des folgenden Befehls eine NUSPEC-Datei aus den Metadaten in der Assembly generieren:

nuget spec <assembly-name>.dll

Wenn Sie dieses Formular verwenden, werden im Manifest einige Platzhalter durch bestimmte Werte aus der Assembly ersetzt. Beispielsweise wird die <id> Eigenschaft auf den Assemblynamen festgelegt und <version> auf die Assemblyversion festgelegt. Andere Eigenschaften im Manifest verfügen jedoch nicht über übereinstimmende Werte in der Assembly. Diese Eigenschaften enthalten weiterhin Platzhalter, nachdem Sie den Befehl ausgeführt haben.

Aus einem Visual Studio Projekt

Das Erstellen einer NUSPEC-Datei aus einer CSPROJ - oder VBPROJ-Datei ist praktisch, da andere Pakete, die im Projekt installiert sind, automatisch als Abhängigkeiten referenziert werden. Verwenden Sie zum Erstellen eines Manifests aus einer Projektdatei den folgenden Befehl im Ordner, der die Projektdatei enthält:

# Use in a folder that contains a project file, such as <project-name>.csproj or <project-name>.vbproj.
nuget spec

Die resultierende <Datei "project-name.nuspec>" enthält Token, die zur Verpackungszeit durch Werte aus dem Projekt ersetzt werden, einschließlich Verweise auf alle anderen Pakete, die bereits installiert wurden.

Wenn Sie Paketabhängigkeiten haben, die in die .nuspec eingeschlossen werden sollen, verwenden Sie nuget packstattdessen . Rufen Sie dann die NUSPEC-Datei aus der generierten nupkg-Datei ab. Verwenden Sie beispielsweise den folgenden Befehl:

# Use in a folder that contains a project file, such as <project-name>.csproj or <project-name>.vbproj.
nuget pack myproject.csproj

Ein Token wird durch $ Symbole auf beiden Seiten der Projekteigenschaften begrenzt. Beispielsweise sieht der Wert in einem Manifest, das <id> auf diese Weise generiert wird, in der Regel wie die folgende Zeile aus:

<id>$id$</id>

Dieses Token wird beim Packen durch den AssemblyName Wert aus der Projektdatei ersetzt. Die genaue Zuordnung von Projektwerten zu NUSPEC-Dateitoken finden Sie unter Ersetzungstoken.

Token entlasten Sie von der Notwendigkeit, wichtige Werte wie die Versionsnummer in der NUSPEC-Datei zu aktualisieren, während Sie das Projekt aktualisieren. Sie können die Token aber auch durch Literalwerte ersetzen.

Es stehen mehrere zusätzliche Paketierungsoptionen zur Verfügung, wenn Sie aus einem Visual Studio Projekt arbeiten, wie in Run nuget pack, um die .nupkg-Datei zu generieren später in diesem Artikel beschrieben.

Pakete auf Lösungsebene

Nur NuGet 2.x. In NuGet 3.0+ nicht verfügbar.

NuGet 2.x unterstützt das Konzept eines Pakets auf Lösungsebene, das Tools oder zusätzliche Befehle für die Paket-Manager Konsole installiert (den Inhalt der tools Ordner), fügt jedoch keine Verweise, Inhalte oder Buildanpassungen zu projekten in der Lösung hinzu. Solche Pakete enthalten keine Dateien in ihrer direkten Bibliothek, inhalten oder Buildordner , und keine ihrer Abhängigkeiten enthält Dateien in ihrer jeweiligen Lib, Inhalte oder Buildordner .

NuGet verfolgt installierte Pakete auf Lösungsebene in einer packages.config Datei im Nuget-Ordner und nicht in der packages.config-Datei des Projekts nach.

Aus einer neuen Datei mit Standardwerten

Mit dem folgenden Befehl wird ein Standardmanifest mit Platzhaltern erstellt. Dadurch wird sichergestellt, dass Sie mit der richtigen Dateistruktur beginnen:

nuget spec [<package-name>]

Wenn Sie weglassen <package-name>, heißt die resultierende Datei "Package.nuspec". Wenn Sie einen Namen wie "Contoso.Utility.UsefulStuffContoso.Utility.UsefulStuff.nuspec" angeben, lautet die Datei "Contoso.Utility.UsefulStuff.nuspec".

Die resultierende NUSPEC-Datei enthält Platzhalter für Werte wie projectUrl. Bevor Sie die Datei zum Erstellen der endgültigen nupkg-Datei verwenden, ersetzen Sie die Platzhalter durch die entsprechenden Werte.

Wählen Sie einen eindeutigen Paketbezeichner aus, und legen Sie die Versionsnummer fest.

Der Paketbezeichner (<id> Element) und die Versionsnummer (<version> Element) sind die beiden wichtigsten Werte im Manifest, da sie den genauen Code eindeutig identifizieren, der im Paket enthalten ist.

Bewährte Methoden für den Paketbezeichner

• Eindeutigkeit: Der Bezeichner muss im Katalog eindeutig sein, in dem das Paket gehostet wird, z. B. nuget.org. Bevor Sie sich für einen Bezeichner entscheiden, durchsuchen Sie den entsprechenden Katalog, um zu überprüfen, ob der Name bereits verwendet wird. Um Konflikte zu vermeiden, ist es ratsam, den Firmennamen als ersten Teil des Bezeichners zu verwenden, z. B. Contoso.
• Namespace-like names: Folgen Sie einem Muster, das namespaces in .NET ähnelt, und verwenden Sie die Punktnotation anstelle von Bindestrichen. Verwenden Sie Contoso.Utility.UsefulStuff z. B. anstelle von Contoso-Utility-UsefulStuff oder Contoso_Utility_UsefulStuff. Verbraucher finden es auch hilfreich, wenn der Paketbezeichner den im Code verwendeten Namespaces entspricht.
• Beispielpakete: Wenn Sie ein Paket mit Beispielcode erstellen, der die Verwendung eines anderen Pakets veranschaulicht, fügen Sie .Sample als Suffix an den Bezeichner an, wie in .Contoso.Utility.UsefulStuff.Sample Ein Beispielpaket dieses Typs weist eine Abhängigkeit vom Paket auf, das die Verwendung veranschaulicht. Wenn Sie ein Beispielpaket erstellen, verwenden Sie die zuvor beschriebene konventionsbasierte Arbeitsverzeichnismethode. Ordnen Sie im Inhaltsordner den Beispielcode in einem Ordner mit dem Namen \Samples\<identifier> an, wie in \Samples\Contoso.Utility.UsefulStuff.Sample.

Bewährte Methoden für die Paketversion

• Legen Sie im Allgemeinen die Version des Pakets so fest, dass sie mit der Bibliothek übereinstimmt. Diese Anleitung wird empfohlen, aber nicht unbedingt erforderlich. Diese Vorgehensweise ist einfach, wenn Sie ein Paket auf eine einzelne Assembly beschränken, wie weiter oben in "Entscheiden, welche Assemblys verpackt werden sollen". Denken Sie im Allgemeinen daran, dass NuGet sich selbst mit Paketversionen befasst, wenn Abhängigkeiten aufgelöst werden, nicht assemblyversionen.
• Wenn Sie ein nicht standardmäßiges Versionsschema verwenden, sollten Sie die NuGet-Versionsverwaltungsregeln berücksichtigen, wie in der Paketversionsverwaltung erläutert.

Weitere Ressourcen, die für das Verständnis der Versionsverwaltung hilfreich sind, finden Sie in der folgenden Reihe von kurzen Blogbeiträgen:

• Teil 1: Übernehmen von DLL Hell
• Teil 2: Der Kernalgorithmus
• Teil 3: Vereinheitlichung über Bindungsumleitungen

Fügen Sie eine Readme-Datei und andere Dateien hinzu

Verwenden Sie den <files> Knoten in der NUSPEC-Datei , um dateien direkt anzugeben, die in das Paket eingeschlossen werden sollen. Dies folgt dem <metadata> Tag:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
    <metadata>
        <!-- ... -->
    </metadata>
    <files>
        <!-- Add files from an arbitrary folder that's not necessarily in the project. -->
        <file src="..\..\SomeRoot\**\*.*" target="" />
    </files>
</package>

Um eine Read-Me-Datei in das Paket einzuschließen, verwenden Sie das readme Metadatenelement, um den Zielpfad zur Read-Me-Datei anzugeben. Verwenden Sie außerdem ein file Metadatenelement, um den Quellpfad und den Zielordner der Readme-Datei anzugeben. Weitere Informationen finden Sie unter readme.

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
    <metadata>
        <!-- ... -->
        <readme>docs\readme.md</readme>
        <!-- ... -->
    </metadata>
    <files>
        <!-- Add a read-me file. -->
        <file src="..\readme.md" target="docs\" />
    </files>
</package>

Visual Studio zeigt den Inhalt der Readme-Datei in der Package-Manager-Benutzeroberfläche an. Der folgende Screenshot zeigt beispielsweise die Lese-/Schreibzugriffsdatei für das HtmlAgilityPack Paket:

Einschließen von MSBuild-Props und Zielen in ein Paket

In einigen Fällen möchten Sie möglicherweise benutzerdefinierte Buildziele oder Eigenschaften zu Projekten hinzufügen, die Ihr Paket nutzen, z. B. das Ausführen eines benutzerdefinierten Tools oder Prozesses während des Builds. Weitere Informationen zu benutzerdefinierten Build-Zielen und Eigenschaften finden Sie unter MSBuild.props und .targets in einem MSBuild-Paket.

Erstellen Sie <package-id.targets>- oder <package-id.props>-Dateien, z. B. Contoso.Utility.UsefulStuff.targets, in den Build-Ordnern des Projekts.

Verweisen Sie dann in der NUSPEC-Datei auf diese Dateien im <files> Knoten:

<?xml version="1.0"?>
<package >
    <metadata minClientVersion="2.5">
    <!-- ... -->
    </metadata>
    <files>
        <!-- In the package build folder, include everything that's in the local build folder. -->
        <file src="build\**" target="build" />

        <!-- Other files -->
        <!-- ... -->
    </files>
</package>

Wenn Einem Projekt Pakete hinzugefügt werden, schließt NuGet diese Eigenschaften und Ziele automatisch ein.

Ausführen des Nuget-Pakets zum Generieren der NUPKG-Datei

Wenn Sie eine Assembly oder das konventionsbasierte Arbeitsverzeichnis verwenden, erstellen Sie ein Paket, indem Sie nuget packIhre .nuspec-Datei ausführen. Ersetzen Sie im folgenden Befehl <project-name> durch den Namen Ihres Projekts.

nuget pack <project-name>.nuspec

Wenn Sie ein Visual Studio Projekt verwenden, führen Sie nuget pack mit Ihrer Projektdatei aus. Mit diesem Befehl wird die NUSPEC-Datei des Projekts automatisch geladen und alle darin enthaltenen Token durch die entsprechenden Werte in der Projektdatei ersetzt:

nuget pack <project-name>.csproj

Schließt in allen Fällen Ordner aus, die mit einem Punkt beginnen, z. B. .git oder .hg.

NuGet gibt an, ob in der Nuspec-Datei Fehler vorhanden sind, die korrigiert werden müssen, z. B. Platzhalterwerte im Manifest, die aktualisiert werden müssen.

Nach dem nuget pack Erfolg verfügen Sie über eine .nupkg-Datei, die Sie in einem geeigneten Katalog veröffentlichen können, wie in Veröffentlichen von NuGet-Paketen beschrieben.

Zusätzliche Optionen

Sie können verschiedene Befehlszeilenoptionen nuget pack verwenden, um Dateien auszuschließen, die Versionsnummer im Manifest außer Kraft zu setzen und den Ausgabeordner unter anderem zu ändern. Eine vollständige Liste finden Sie unter Pack-Befehl (NuGet CLI).

Die folgenden Optionen sind einige, die mit Visual Studio Projekten üblich sind:

• Referenzierte Projekte: Wenn das Projekt auf andere Projekte verweist, können Sie die referenzierten Projekte als Teil des Pakets oder als Abhängigkeiten mithilfe der -IncludeReferencedProjects Option hinzufügen:

  nuget pack MyProject.csproj -IncludeReferencedProjects
  

  Dieser Inklusionsprozess ist rekursiv. Wenn beispielsweise MyProject.csproj auf Projekte B und C verweist und diese Projekte auf D, E und F verweisen, werden Dateien aus B, C, D, D, E und F in das Paket einbezogen.

  Wenn ein referenziertes Projekt eine NUSPEC-Datei enthält, fügt NuGet stattdessen dieses Referenzprojekt als Abhängigkeit hinzu. Sie müssen das Projekt separat packen und veröffentlichen.

• Buildkonfiguration: Standardmäßig verwendet NuGet die Standardbuildkonfiguration, die in der Projektdatei festgelegt ist, in der Regel Debug. Verwenden Sie zum Packen von Dateien aus einer anderen Buildkonfiguration, wie Release, die -properties-Option mit der Konfiguration:

  nuget pack MyProject.csproj -properties Configuration=Release
  

• Symbole: Um Symbole einzuschließen, die es Verbrauchern ermöglichen, den Paketcode im Debugger durchzugehen, verwenden Sie die Optionen -Symbols und -SymbolPackageFormat. Geben Sie das Format snupkg für die -SymbolPackageFormat-Option an.

  nuget pack MyProject.csproj -symbols -SymbolPackageFormat snupkg
  

Testen der Paketinstallation

Bevor Sie ein Paket veröffentlichen, möchten Sie in der Regel den Prozess der Installation des Pakets in einem Projekt testen. Ein Test hilft sicherzustellen, dass alle erforderlichen Dateien an der richtigen Stelle im Projekt landen.

Sie können Installationen manuell in Visual Studio oder in der Befehlszeile testen, indem Sie die standardinstallationsschritte package verwenden.

Für automatisierte Tests können Sie den folgenden grundlegenden Prozess verwenden:

1. Kopieren Sie die NUPKG-Datei in einen lokalen Ordner.
2. Fügen Sie den Ordner mithilfe des nuget sources add -name <name> -source <path> Befehls zu Ihren Paketquellen hinzu. Weitere Informationen finden Sie unter "Sources"-Befehl (NuGet CLI). Sie müssen diese lokale Quelle nur einmal auf einem bestimmten Computer festlegen.
3. Installieren Sie das Paket von dieser Quelle mit nuget install <package-ID> -source <name>. In diesem Befehl sollte <name> mit dem Namen der Quelle übereinstimmen, den Sie im nuget sources-Befehl verwenden. Wenn Sie die Quelle angeben, wird NuGet aufgefordert, das Paket allein aus dieser Quelle zu installieren.
4. Überprüfen Sie das Dateisystem, um zu überprüfen, ob Dateien ordnungsgemäß installiert sind.

Verwandte Inhalte

Nachdem Sie ein Paket erstellt haben, bei dem es sich um eine nupkg-Datei handelt, können Sie es im Katalog Ihrer Wahl veröffentlichen. Weitere Informationen finden Sie unter Veröffentlichen von NuGet-Paketen.

Sie können auch die Funktionen Ihres Pakets erweitern oder andere Szenarien unterstützen. Weitere Informationen finden Sie in den folgenden Artikeln:

• Paketversionsverwaltung
• Unterstützung mehrerer .NET-Versionen
• Transformieren von Quellcode- und Konfigurationsdateien
• Erstellen lokalisierter NuGet-Pakete
• Erstellen von Vorabpaketen
• Festlegen eines NuGet-Pakettyps
• NuGet-Pakete erstellen, die COM-Interop-Assemblys enthalten

Weitere Zu beachtende Pakettypen finden Sie in den folgenden Artikeln:

• Erstellen systemeigener Pakete
• Erstellen von Symbolpaketen (.snupkg)