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 CLI-Tools, entweder nuget.exe oder dotnet.exe, um diese Funktionalität in eine Komponente zu packen, die von einer beliebigen Anzahl anderer Entwickler gemeinsam genutzt und verwendet werden kann. Informationen zum Installieren von NuGet CLI-Tools finden Sie unter Installieren von NuGet-Clienttools. Beachten Sie, dass Visual Studio kein CLI-Tool automatisch enthält.

• Für Projekte im Nicht-SDK-Stil führen Sie in der Regel .NET Framework-Projekte die in diesem Artikel beschriebenen Schritte aus, um ein Paket zu erstellen. Schrittweise Anleitungen mithilfe von Visual Studio und der nuget.exe CLI finden Sie unter Erstellen und Veröffentlichen eines .NET Framework-Pakets.

• Für .NET Core- und .NET Standard-Projekte, die das SDK-Stil-Format verwenden, sowie andere Projekte im SDK-Stil, siehe "Erstellen Sie ein NuGet-Paket mit der dotnet CLI".

• Verwenden Sie für Projekte, die von packages.configPackageReference migriert wurden, msbuild -t:pack.

Technisch gesehen ist ein NuGet-Paket nur eine ZIP-Datei, die mit der .nupkg Erweiterung umbenannt wurde und deren Inhalt bestimmten Konventionen entspricht. In diesem Thema wird der detaillierte Prozess zum Erstellen eines Pakets beschrieben, das diese Konventionen erfüllt.

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

Von Bedeutung

Dieses Thema bezieht sich auf Projekte im Nicht-SDK-Stil, die in der Regel andere Projekte als .NET Core- und .NET Standard-Projekte mit Visual Studio 2017 und höheren Versionen und NuGet 4.0+ verwenden.

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. Wenn Sie z. B. über ein Utilities.dll verfügen, das von Parser.dll abhängt, und Parser.dll an sich nützlich ist, erstellen Sie jeweils ein Paket. Auf diese Weise können Entwickler Parser.dll unabhängig von Utilities.dll nutzen.

• 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 Sie das vorherige Beispiel verwenden und Parser.dll Code enthält, der nur von Utilities.dll verwendet wird, dann ist es in Ordnung, Parser.dll im selben Paket zu belassen.

• In ähnlicher Weise, wenn Utilities.dll von Utilities.resources.dll abhängig ist, wo das Letztere für sich genommen nicht nützlich ist, dann sollten beide in das gleiche Paket gelegt werden.

Ressourcen sind in der Tat 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 benannt .resources.dll werden, da sie als lokalisierte Satellitenassemblys angenommen werden (siehe Erstellen lokalisierter Pakete). Aus diesem Grund vermeiden Sie die Verwendung .resources.dll für Dateien, die andernfalls wesentlichen Paketcode enthalten.

Wenn Ihre Bibliothek COM-Interopassemblys enthält, befolgen Sie zusätzliche Richtlinien in " Pakete mit COM-Interopassemblys erstellen".

Die Rolle und Struktur der NUSPEC-Datei

Sobald Sie wissen, welche Dateien Sie packen möchten, wird im nächsten Schritt ein Paketmanifest in einer .nuspec XML-Datei erstellt.

Das Manifest:

1. Beschreibt den Inhalt des Pakets und ist selbst im Paket enthalten.
2. Steuert die Erstellung des Pakets und weist NuGet an, 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.
3. Enthält sowohl erforderliche als auch optionale Eigenschaften, wie unten beschrieben. Genaue Details, einschließlich anderer hier nicht erwähnter Eigenschaften, finden Sie in der Nuspec-Referenz.

Erforderliche Eigenschaften:

• Der Paketbezeichner, der in der Galerie, die das Paket hostet, 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)
• Autoren- und Besitzerinformationen.
• Eine lange Beschreibung des Pakets.

Allgemeine optionale Eigenschaften:

• Versionshinweise
• Copyright-Informationen
• Eine kurze Beschreibung für die Benutzeroberfläche des Paket-Managers in Visual Studio
• Gebietsschema-ID
• Projekt-URL
• Lizenz als Ausdruck oder Datei (licenseUrl ist veraltet, nuspec-Metadatenelement stattdessen verwendenlicense)
• Eine Symboldatei (iconUrl ist veraltet, verwenden Sie stattdessen das icon nuspec-Metadatenelement)
• Listen von Abhängigkeiten und Verweisen
• Tags, die bei Katalogsuchen helfen

Es folgt eine typische (aber fiktive) .nuspec Datei mit Kommentaren, die die Eigenschaften beschreiben:

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

        <!-- Package version number that is used when resolving dependencies -->
        <version>1.8.3</version>

        <!-- Authors contain text that appears directly on the gallery -->
        <authors>Dejana Tesic, Rajeev Dey</authors>

        <!-- 
            Owners are typically nuget.org identities that allow gallery
            users to easily find other packages by the same owners.  
        -->
        <owners>dejanatc, rjdey</owners>
        
         <!-- Project URL provides a link for the gallery -->
        <projectUrl>http://github.com/contoso/UsefulStuff</projectUrl>

         <!-- License information is displayed on the gallery -->
        <license type="expression">Apache-2.0</license>
        

        <!-- Icon is used in Visual Studio's package manager UI -->
        <icon>icon.png</icon>

        <!-- 
            If true, this value prompts the user to accept the license when
            installing the package. 
        -->
        <requireLicenseAcceptance>false</requireLicenseAcceptance>

        <!-- Any details about this particular release -->
        <releaseNotes>Bug fixes and performance improvements</releaseNotes>

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

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

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

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

    <!-- A readme.txt to display when the package is installed -->
    <files>
        <file src="readme.txt" 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. Es ist auch möglich, Assets aus Abhängigkeiten direkt im Paket mithilfe der include und exclude Attribute auf dem dependency Element anzuzeigen. Siehe die .nuspec-Referenz - Abhängigkeiten.

Da das Manifest im darin erstellten Paket enthalten ist, finden Sie eine beliebige Anzahl zusätzlicher Beispiele, indem Sie vorhandene Pakete untersuchen. Eine gute Quelle ist der Ordner "Globale Pakete " auf Ihrem Computer, dessen Speicherort durch den folgenden Befehl zurückgegeben wird:

nuget locals -list global-packages

Wechseln Sie in einen beliebigen Ordner "package\version ", kopieren Sie die .nupkg Datei in eine .zip Datei, öffnen Sie diese .zip Datei, und untersuchen Sie die .nuspec Datei darin.

Hinweis

Beim Erstellen eines .nuspec aus einem Visual Studio-Projekt enthält das Manifest Token, die beim Erstellen des Pakets durch Informationen aus dem Projekt ersetzt werden. Siehe Erstellen der .nuspec aus einem Visual Studio-Projekt.

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
• Ein Visual Studio-Projekt
• 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.

Von Bedeutung

Generierte .nuspec Dateien enthalten Platzhalter, die vor dem Erstellen des Pakets mit dem nuget pack Befehl geändert werden müssen. Dieser Befehl schlägt fehl, wenn die .nuspec Platzhalter enthält.

Aus einem konventionsbasierten Arbeitsverzeichnis

Da ein NuGet-Paket nur eine ZIP-Datei ist, die mit der .nupkg Erweiterung umbenannt wurde, ist es häufig am einfachsten, die gewünschte Ordnerstruktur in Ihrem lokalen Dateisystem zu erstellen, und dann die Datei direkt aus dieser .nuspec Struktur zu erstellen. Der nuget pack Befehl fügt dann automatisch alle Dateien in dieser Ordnerstruktur hinzu (mit Ausnahme aller Ordner, die 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 Thema erläutert). Sie können einfach die genaue Ordnerstruktur erstellen lassen, die in das Paket eingeht, und Sie können ganz einfach 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 Ordnerkonventionen sind wie folgt:

Ordner	Description	Aktion bei der Paketinstallation
(Stamm)	Speicherort für readme.txt	Visual Studio zeigt eine readme.txt Datei im Paketstamm an, wenn das Paket installiert ist.
lib/{tfm}	Assemblydateien (.dll), Dokumentationsdateien (.xml) und Symboldateien (.pdb) für den angegebenen Target-Framework-Bezeichner (TFM)	Assemblies werden sowohl für die Kompilierung als auch für die Laufzeit als Verweise hinzugefügt; .xml und .pdb werden in Projektordner kopiert. Siehe Unterstützen mehrerer Zielframeworks zum Erstellen von Frameworkzielspezifischen Unterordnern.
ref/{tfm}	Assemblydateien (.dll) und Symboldateien (.pdb) für das angegebene Target Framework Moniker (TFM)	Assemblies werden nur zur Kompilierungszeit als Verweise hinzugefügt, daher wird nichts in den Projekt-Bin-Ordner kopiert.
runtimes	Architekturspezifische Assemblydateien (.dll), Symboldateien (.pdb) und systemeigene Ressourcendateien (.pri)	Assemblys werden nur zur Laufzeit als Verweise hinzugefügt. andere Dateien werden in Projektordner kopiert. Es sollte immer eine spezifische TFM AnyCPU Assembly im /ref/{tfm} Ordner vorhanden sein, um die entsprechende Kompilierungszeit-Assembly bereitzustellen. Siehe Unterstützen mehrerer Zielframeworks.
Inhalt	Beliebige Dateien	Der Inhalt wird in den Projektstamm kopiert. Stellen Sie sich den Inhaltsordner als Stamm der Zielanwendung vor, die das Paket letztendlich nutzt. Wenn das Paket ein Bild im Ordner "/images " der Anwendung hinzufügen soll, platzieren Sie es im Ordner "content/images " des Pakets.
Bauen	(3.x+) MSBuild .targets und .props Dateien	Automatisch in das Projekt eingefügt.
buildMultiTargeting	(4,0+) MSBuild .targets und .props Dateien für plattformübergreifendes Targeting	Automatisch in das Projekt eingefügt.
buildTransitive	(5,0+) MSBuild .targets- und .props-Dateien, die transitiv zu jedem konsumierenden Projekt weitergeleitet werden. Weitere Informationen finden Sie auf der Seite Feature.	Automatisch in das Projekt eingefügt.
Werkzeuge	PowerShell-Skripts und -Programme, auf die über die Paket-Manager-Konsole zugegriffen werden kann	Der tools-Ordner wird nur der PATH-Umgebungsvariable für die Paket-Manager-Konsole hinzugefügt (nicht der PATH-Umgebungsvariable, die für MSBuild beim Erstellen des Projekts gesetzt ist).

Da ihre Ordnerstruktur eine beliebige Anzahl von Assemblys für eine beliebige Anzahl von Zielframeworks enthalten kann, ist diese Methode erforderlich, wenn Pakete erstellt werden, die mehrere Frameworks unterstützen.

Führen Sie in jedem Fall nach der gewünschten Ordnerstruktur den folgenden Befehl in diesem Ordner aus, um die .nuspec Datei zu erstellen:

nuget spec

Auch hier enthält die generierte .nuspec Datei 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 einfachen Fall der Erstellung eines Pakets aus einer Assembly können Sie eine .nuspec Datei aus den Metadaten in der Assembly mithilfe des folgenden Befehls 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 und enthalten daher weiterhin Platzhalter.

Aus einem Visual Studio-Projekt

Das Erstellen einer .nuspec Datei aus einer .csproj- oder .vbproj-Datei ist praktisch, da andere Pakete, die in das Projekt installiert wurden, automatisch als Abhängigkeiten referenziert werden. Verwenden Sie einfach den folgenden Befehl im selben Ordner wie die Projektdatei:

# Use in a folder containing a project file <project-name>.csproj or <project-name>.vbproj
nuget spec

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

Wenn Sie Paketabhängigkeiten in die .nuspec einschließen möchten, verwenden Sie stattdessen nuget pack, und extrahieren Sie die .nuspec-Datei aus der generierten .nupkg-Datei. Verwenden Sie beispielsweise den folgenden Befehl.

# Use in a folder containing a project file <project-name>.csproj or <project-name>.vbproj
nuget pack myproject.csproj

Ein Token wird durch $ Symbole auf beiden Seiten der Projekteigenschaften begrenzt. Beispielsweise erscheint der <id> Wert in einem Manifest, das auf diese Weise generiert wurde, typischerweise wie folgt:

<id>$id$</id>

Dieses Token wird beim Packen durch den AssemblyName Wert aus der Projektdatei ersetzt. Die genaue Zuordnung von Projektwerten zu .nuspec-Token finden Sie in der Referenz zu Platzhalter-Token.

Token entlasten Sie von der Notwendigkeit, wichtige Werte wie die Versionsnummer beim .nuspec Aktualisieren des Projekts zu aktualisieren. (Sie können die Token bei Bedarf immer durch Literalwerte ersetzen).

Beachten Sie, dass beim Arbeiten aus einem Visual Studio-Projekt mehrere zusätzliche Verpackungsoptionen verfügbar sind, wie in "Running nuget pack" beschrieben, um die nupkg-Datei später zu generieren .

Pakete auf Lösungsebene

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

NuGet 2.x unterstützte den Begriff eines Pakets auf Lösungsebene, das Tools oder zusätzliche Befehle für die Paket-Manager-Konsole (den Inhalt des tools Ordners) installiert, aber keine Verweise, Inhalte oder Buildanpassungen zu projekten in der Lösung hinzu fügt. Solche Pakete enthalten keine Dateien in ihren direkten lib, contentoder build Ordnern, und keine der Abhängigkeiten enthält Dateien in ihren jeweiligen lib, , contentoder build Ordnern.

NuGet verfolgt installierte Pakete auf Lösungsebene in einer packages.config Datei im .nuget Ordner und nicht in der Projektdatei packages.config nach.

Neue Datei mit Standardwerten

Mit dem folgenden Befehl wird ein Standardmanifest mit Platzhaltern erstellt, das sicherstellt, dass Sie mit der richtigen Dateistruktur beginnen:

nuget spec [<package-name>]

Wenn Sie den Paketnamen< weglassen>, lautet Package.nuspecdie resultierende Datei . Wenn Sie einen Namen wie z. B. Contoso.Utility.UsefulStuff angeben, lautet die Datei Contoso.Utility.UsefulStuff.nuspec.

Das Ergebnis .nuspec enthält Platzhalter für Werte wie die projectUrl. Achten Sie darauf, die Datei zu bearbeiten, bevor Sie sie zum Erstellen der endgültigen .nupkg Datei verwenden.

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 über nuget.org oder jede Galerie, die das Paket hostet, eindeutig sein. 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ähnliche Namen: 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, das veranschaulicht, wie ein anderes Paket verwendet wird, fügen Sie .Sample als Suffix an den Bezeichner an, wie in Contoso.Utility.UsefulStuff.Sample. (Das Beispielpaket hätte natürlich eine Abhängigkeit vom anderen Paket.) Verwenden Sie beim Erstellen eines Beispielpakets die zuvor beschriebene konventionsbasierte Arbeitsverzeichnismethode. Ordnen Sie den Beispielcode im content Ordner in einem neuen Ordner \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, obwohl dies nicht unbedingt erforderlich ist. Dies ist eine einfache Angelegenheit, wenn Sie ein Paket auf eine einzelne Assembly beschränken, wie weiter oben in der Entscheidung, welche Assemblys verpackt werden sollen. Denken Sie insgesamt daran, dass NuGet sich selbst mit Paketversionen befasst, wenn Abhängigkeiten aufgelöst werden, nicht Assemblyversionen.
• Achten Sie bei der Verwendung eines nicht standardmäßigen Versionsschemas darauf, die NuGet-Versionsverwaltungsregeln zu berücksichtigen, wie in der Paketversionsverwaltung erläutert.

Die folgende Reihe von kurzen Blogbeiträgen ist auch hilfreich, um die Versionsverwaltung zu verstehen:

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

Füge eine README-Datei und andere Dateien hinzu

Wenn Sie Dateien, die in das Paket eingeschlossen werden sollen, direkt angeben möchten, verwenden Sie den <files> Knoten in der .nuspec Datei, der auf das <metadata> Tag folgt:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
    <metadata>
    <!-- ... -->
    </metadata>
    <files>
        <!-- Add a readme -->
        <file src="readme.txt" target="" />

        <!-- Add files from an arbitrary folder that's not necessarily in the project -->
        <file src="..\..\SomeRoot\**\*.*" target="" />
    </files>
</package>

Tipp

Wenn Sie den konventionsbasierten Arbeitsverzeichnisansatz verwenden, können Sie die readme.txt im Paketstamm und anderen Inhalten im content Ordner platzieren. Im Manifest sind keine <file> Elemente erforderlich.

Wenn Sie eine Datei mit dem Namen readme.txt im Paketstamm einschließen, zeigt Visual Studio den Inhalt dieser Datei unmittelbar nach der Installation des Pakets direkt als Nur-Text an. (Readme-Dateien werden nicht für Pakete angezeigt, die als Abhängigkeiten installiert sind). Hier erfahren Sie beispielsweise, wie die Readme-Datei für das HtmlAgilityPack-Paket aussieht.

Hinweis

Wenn Sie einen leeren <files> Knoten in die .nuspec Datei einfügen, enthält NuGet keinen anderen Inhalt im Paket als das, was sich im lib Ordner befindet.

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

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

Erstellen Sie <package_id>.targets oder <package_id>.props (z.B. Contoso.Utility.UsefulStuff.targets) in den Build-Ordnern des Projekts.

Stellen Sie dann in der .nuspec Datei sicher, dass Sie auf diese Dateien im <files> Knoten verweisen:

<?xml version="1.0"?>
<package >
    <metadata minClientVersion="2.5">
    <!-- ... -->
    </metadata>
    <files>
        <!-- Include everything in \build -->
        <file src="build\**" target="build" />

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

Wenn Einem Projekt Pakete hinzugefügt werden, enthält NuGet automatisch diese Props und Ziele.

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

Wenn Sie eine Assembly oder ein konventionsbasiertes Arbeitsverzeichnis verwenden, erstellen Sie ein Paket, indem Sie nuget pack mit Ihrer .nuspec-Datei ausführen und <project-name> durch Ihren spezifischen Dateinamen ersetzen:

nuget pack <project-name>.nuspec

Wenn Sie ein Visual Studio-Projekt verwenden, führen Sie nuget pack mit Ihrer Projektdatei aus, was die Datei .nuspec automatisch lädt und darin enthaltene Tokens durch Werte aus der Projektdatei ersetzt:

nuget pack <project-name>.csproj

Hinweis

Die direkte Verwendung der Projektdatei ist für die Tokenersetzung erforderlich, da das Projekt die Quelle der Tokenwerte ist. Die Tokenersetzung tritt nicht auf, wenn Sie eine nuget pack.nuspec Datei verwenden.

In allen Fällen schließt nuget pack Ordner aus, die mit einem Punkt beginnen, wie .git oder .hg.

NuGet gibt an, ob fehler in der .nuspec Datei vorhanden sind, die korrigiert werden müssen, z. B. das Vergessen, Platzhalterwerte im Manifest zu ändern.

Sobald nuget pack dies erfolgreich ist, verfügen Sie über eine .nupkg Datei, die Sie in einem geeigneten Katalog veröffentlichen können, wie in der Veröffentlichung eines Pakets beschrieben.

Tipp

Eine hilfreiche Möglichkeit, ein Paket nach dem Erstellen zu untersuchen, besteht darin, es im Paket-Explorer-Tool zu öffnen. Dadurch erhalten Sie eine grafische Ansicht des Paketinhalts und des zugehörigen Manifests. Sie können die resultierende .nupkg Datei auch in eine .zip Datei umbenennen und deren Inhalte direkt durchsuchen.

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 in der Packbefehlsreferenz.

Die folgenden Optionen sind einige, die für Visual Studio-Projekte ü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 Einschlussprozess ist rekursiv. Wenn MyProject.csproj auf die Projekte B und C verweist und diese Projekte auf D, E und F verweisen, werden Dateien aus B, C, D, E und F in das Paket aufgenommen.

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

• Buildkonfiguration: Standardmäßig verwendet NuGet den Standardbuildkonfigurationssatz in der Projektdatei, in der Regel "Debuggen". Verwenden Sie zum Packen von Dateien aus einer anderen Buildkonfiguration, z. B. "Release", die -properties Option mit der Konfiguration:

  nuget pack MyProject.csproj -properties Configuration=Release
  

• Symbole: Um Symbole einzuschließen, mit denen Verbraucher den Paketcode im Debugger durchlaufen können, verwenden Sie die -Symbols Option:

  nuget pack MyProject.csproj -symbols
  

Testen der Paketinstallation

Vor dem Veröffentlichen eines Pakets möchten Sie in der Regel den Prozess der Installation eines Pakets in einem Projekt testen. Die Tests stellen sicher, dass alle Dateien an ihren richtigen Stellen im Projekt enden.

Sie können Installationen manuell in Visual Studio oder über die Befehlszeile testen, indem Sie die normalen Installationsschritte des Pakets ausführen.

Bei automatisierten Tests lautet der grundlegende Prozess wie folgt:

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 (siehe Nuget-Quellen). Beachten Sie, dass Sie diese lokale Quelle nur einmal auf einem bestimmten Computer festlegen müssen.
3. Installieren Sie das Paket aus dieser Quelle mithilfe von nuget install <packageID> -source <name> dort, wo <name> dem Namen Ihrer Quelle entspricht, wie in nuget sources angegeben. Durch Angeben der Quelle wird sichergestellt, dass das Paket allein aus dieser Quelle installiert wird.
4. Überprüfen Sie das Dateisystem, um zu überprüfen, ob Dateien ordnungsgemäß installiert sind.

Nächste Schritte

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, wie im Veröffentlichen eines Pakets beschrieben.

Möglicherweise möchten Sie auch die Funktionen Ihres Pakets erweitern oder andere Szenarien unterstützen, wie in den folgenden Themen beschrieben:

• Paketversionsverwaltung
• Unterstützen mehrerer Zielframeworks
• Transformationen von Quell- und Konfigurationsdateien
• Lokalisierung
• Vorabversionen
• Pakettyp festlegen
• Pakete mit COM-Interop-Assemblies erstellen

Schließlich sind zusätzliche Pakettypen zu beachten:

• Native Pakete
• Symbolpakete