Creare un pacchetto usando l'interfaccia della riga di comando di nuget.exe

Indipendentemente dalle operazioni del pacchetto o dal codice che contiene, è possibile usare uno degli strumenti dell'interfaccia della riga di comando ( nuget.exe CLI) o dotnet.exeper creare un pacchetto di tale funzionalità in un componente che può essere condiviso con e usato da altri sviluppatori. Per installare gli strumenti dell'interfaccia della riga di comando di NuGet, vedere Installare gli strumenti client NuGet. Visual Studio non include automaticamente uno strumento CLI.

• Per i progetti non in stile SDK, in genere .NET progetti Framework, seguire la procedura descritta in questo articolo per creare un pacchetto. Per una guida introduttiva che fornisce istruzioni dettagliate sull'uso di Visual Studio e dell'interfaccia della riga di comando di nuget.exe, vedere Quickstart: Creare e pubblicare un pacchetto usando Visual Studio (.NET Framework, Windows).

• Per i progetti .NET Core e .NET Standard che usano il formato stile SDK, e qualsiasi altro progetto in stile SDK, consultare Creare un pacchetto NuGet con l'interfaccia della riga di comando dotnet.

• Per i progetti migrati da packages.config a PackageReference, usare il msbuild -t:pack comando .

Tecnicamente, un pacchetto NuGet è un file ZIP rinominato per avere l'estensione .nupkg e il cui contenuto corrisponde a determinate convenzioni. Questo articolo descrive il processo dettagliato di creazione di un pacchetto che soddisfi tali convenzioni.

La creazione di pacchetti inizia con il codice compilato (assembly), i simboli e altri file che si desidera recapitare come pacchetto. Per una panoramica del processo di creazione dei pacchetti, vedere Flusso di lavoro di creazione dei pacchetti. Questo processo è indipendente dalla compilazione o dalla generazione dei file che vengono inseriti nel pacchetto. È tuttavia possibile ricavare informazioni in un file di progetto per mantenere sincronizzati gli assembly e i pacchetti compilati.

Importante

Questo articolo si applica a progetti non in stile SDK, in genere progetti diversi da .NET Core e .NET progetti Standard che usano Visual Studio 2017 e versioni successive e NuGet 4.0+.

Decidere quali assembly includere nel pacchetto

La maggior parte dei pacchetti per utilizzo generico contiene uno o più assembly che altri sviluppatori possono usare nei propri progetti.

In generale, è consigliabile avere un assembly per ogni pacchetto NuGet, purché ogni assembly sia utile in modo indipendente. Si considerino ad esempio i casi seguenti che coinvolgono un assembly denominato Utilities.dll che dipende da un assembly denominato Parser.dll:

• Se Parser.dll è utile autonomamente, creare un pacchetto per Utilities.dll e uno per Parser.dll. In questo modo gli sviluppatori possono usare Parser.dll indipendentemente da Utilities.dll.

• Se Parser.dll contiene codice usato solo da Utilities.dll, è consigliabile mantenere Parser.dll nello stesso pacchetto. In generale, se la libreria è costituita da più assembly che non sono utili singolarmente, va bene combinarli in un unico pacchetto.

• Se Utilities.dll dipende anche da Utilities.resources.dlle Utilities.resources.dll non è utile autonomamente, inserire entrambi nello stesso pacchetto.

Le risorse, ad esempio l'assembly Utilities.resources.dll nell'esempio precedente, sono un caso speciale. Quando un pacchetto viene installato in un progetto, NuGet aggiunge automaticamente i riferimenti all'assembly alle DLL del pacchetto, escluse quelle denominate .resources.dll, perché si presuppone che siano assembly satellite localizzati. Per altre informazioni sulle versioni localizzate di una libreria, vedere Creazione di pacchetti NuGet localizzati. Per questo motivo, evitare di usare .resources.dll per i file che contengono codice di pacchetto essenziale.

Se la libreria contiene assembly di interoperabilità COM (Component Object Model), seguire le linee guida aggiuntive in Creare pacchetti NuGet che contengono assembly di interoperabilità COM.

Ruolo e struttura del file .nuspec

Quando si conoscono i file da creare in pacchetto, il passaggio successivo consiste nel creare un manifesto del pacchetto in un file XML con estensione nuspec .

Il manifesto:

• Descrive il contenuto del pacchetto ed è incluso nel pacchetto.
• Determina la creazione del pacchetto e indica a NuGet come installare il pacchetto in un progetto. Ad esempio, il manifesto identifica altre dipendenze del pacchetto in modo che NuGet possa installare anche tali dipendenze quando viene installato il pacchetto principale.
• Contiene proprietà obbligatorie e facoltative, come descritto nella parte restante di questa sezione. Per informazioni dettagliate, incluse altre proprietà non menzionate qui, vedere .nuspec reference (Informazioni di riferimento su .nuspec).

Nel manifesto sono necessarie le proprietà seguenti:

• Identificatore del pacchetto, che deve essere univoco nella raccolta che ospita il pacchetto
• Numero di versione specifico nel formato Major.Minor.Patch[-Suffix], dove -Suffix identifica le versioni non definitive
• Il titolo del pacchetto come dovrebbe apparire nell'host (ad esempio nuget.org)
• Informazioni sull'autore
• Descrizione lunga del pacchetto

Le proprietà seguenti sono quelle facoltative comuni:

• Note sulla versione.
• Informazioni sul copyright.
• Breve descrizione dell'interfaccia utente Package Manager in Visual Studio.
• ID di localizzazione.
• URL di progetto.
• Una licenza come espressione o file. La licenseUrl proprietà è deprecata. Invece, usare l'elemento di metadati "nuspec".
• Un file README.
• Un file icona. La iconUrl proprietà è deprecata. Invece, usare l'elemento di metadati "nuspec".
• Elenchi di dipendenze e riferimenti.
• Tag utili per le ricerche nella galleria.

Il codice seguente è un file tipico (ma fittizio) con estensione nuspec , con commenti che descrivono le proprietà:

<?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>

Per informazioni dettagliate sulla dichiarazione delle dipendenze e sulla specifica dei numeri di versione, vedere packages.config e controllo delle versioni dei pacchetti. È anche possibile usare gli include attributi e exclude nell'elemento dependency per specificare gli asset di dipendenza da includere o escludere nel pacchetto. Per altre informazioni, vedere .nuspec Reference - Dependencies element .

Poiché il manifesto è incluso nel pacchetto creato da esso, è possibile trovare esempi esaminando i pacchetti esistenti. Una buona fonte è la cartella global-packages nel computer. Per trovare il percorso, usare il comando seguente:

nuget locals -list global-packages

Dopo aver individuato il percorso della cartella global-packages , seguire questa procedura per trovare un file manifesto:

1. Passare alla cartella global-packages .
2. In tale cartella passare alla sottocartella per qualsiasi pacchetto e quindi passare a una sottocartella per qualsiasi versione del pacchetto.
3. Nella sottocartella della versione, creare una copia del file con estensione nupkg e modificare l'estensione della copia in zip.
4. Aprire il file .zip ed esaminare il file con estensione nuspec al suo interno.

Annotazioni

Quando si crea un file .nuspec da un progetto di Visual Studio, il manifesto contiene token sostituiti con informazioni del progetto al momento della compilazione del pacchetto. Per altre informazioni, vedere Creare il file con estensione nuspec da un progetto Visual Studio.

Creare il file con estensione nuspec

La creazione di un manifesto completo inizia in genere con un file con estensione nuspec di base generato tramite uno dei metodi seguenti:

• Directory di lavoro basata su convenzioni
• DLL di assemblaggio
• A progetto di Visual Studio
• Nuovo file con valori predefiniti

Si modifica quindi il file a mano in modo che descriva il contenuto esatto desiderato nel pacchetto finale.

Importante

I file con estensione nuspec generati contengono segnaposto che è necessario modificare prima di creare il pacchetto usando il nuget pack comando . Questo comando ha esito negativo se il file .nuspec contiene segnaposto.

Da una directory di lavoro basata su convenzioni

Poiché un pacchetto NuGet è un file ZIP rinominato con l'estensione nupkg , spesso è più semplice creare la struttura di cartelle desiderata nel file system locale e quindi creare il file con estensione nuspec direttamente da tale struttura. Il nuget pack comando aggiunge quindi automaticamente tutti i file nella struttura di cartelle, ma esclude tutte le cartelle che iniziano con un punto, in modo da poter mantenere i file privati nella stessa struttura.

Il vantaggio di questo approccio è che non è necessario specificare nel manifesto i file da includere nel pacchetto, come illustrato più avanti in questa sezione. Invece, è possibile che il processo di compilazione generi esattamente la struttura di cartelle che viene inserita nel pacchetto. È anche possibile includere facilmente altri file che potrebbero non far parte di un progetto altrimenti:

• Contenuto e codice sorgente da inserire nel progetto di destinazione
• Script di PowerShell
• Trasformazioni in file di codice sorgente e di configurazione esistenti in un progetto

Le cartelle sono allineate alle convenzioni seguenti:

Cartella	Contenuto	Azione all'installazione del pacchetto
(root)	Manifest del pacchetto, cartelle di primo livello, e, facoltativamente, un file Markdown di tipo read-me e un'immagine dell'icona	Questa cartella viene usata come punto di partenza per le sottocartelle standardizzate, ad esempio lib e build.
lib/<tfm>	Assembly (.dll), documentazione (.xml) e file di simboli (.pdb) per l'identificatore del framework di destinazione specificato (TFM)	Gli assembly vengono aggiunti come riferimenti per la fase di compilazione e il runtime. I file.xml e pdb vengono copiati nelle cartelle del progetto. Per informazioni sulla creazione di sottocartelle specifiche della destinazione del framework, vedere Supporta più versioni .NET.
ref/<tfm>	File assembly (.dll) e file simbolo (.pdb) per il TFM specificato.	Gli assembly vengono aggiunti come riferimenti solo per la fase di compilazione. Non viene copiato alcun elemento nella cartella bin del progetto.
runtime	Assembly specifico dell'architettura (.dll), simbolo (.pdb) e file di risorse native (.pri)	Gli assembly vengono aggiunti come riferimenti solo per il runtime. Gli altri file vengono copiati in cartelle di progetto. Deve essere sempre presente un assembly specifico corrispondente (TFM) AnyCPU nella cartella /ref/<tfm> per fornire l'assembly in fase di compilazione corrispondente. Vedere Supporta più versioni di .NET.
contenuto	File arbitrari	Il contenuto viene copiato nella radice del progetto. Si consideri la cartella di contenuto come la radice dell'applicazione di destinazione che in definitiva utilizza il pacchetto. Per fare in modo che il pacchetto aggiunga un'immagine nella cartella /images dell'applicazione, inserirla nella cartella content/images del pacchetto.
Costruire	(3.x+) Microsoft Build Engine (MSBuild) .targets e .props file	Questi file vengono inseriti automaticamente nel progetto.
buildMultiTargeting	(4.0+) File MSBuild .targets e .props per il supporto di più framework	Questi file vengono inseriti automaticamente nel progetto.
buildTransitive	(5.0+) file MSBuild con estensione .targets e .props che vengono propagati transitivamente a qualsiasi progetto che li utilizza	Questi file vengono inseriti automaticamente nel progetto. Vedere la pagina delle funzionalità.
Strumenti	Script e programmi di PowerShell accessibili dalla console di Package Manager	La cartella tools viene aggiunta alla variabile di ambiente PATH solo per la console Package Manager. Non viene aggiunto al valore PATH che MSBuild utilizza quando compila il progetto.

Poiché la struttura di cartelle può contenere assembly per molti framework di destinazione, questo metodo è necessario quando si creano pacchetti che supportano più framework.

Quando si dispone della struttura di cartelle desiderata, eseguire il comando seguente in tale cartella per creare il file con estensione nuspec :

nuget spec

Il file con estensione nuspec generato non contiene riferimenti espliciti ai file nella struttura di cartelle. NuGet include automaticamente tutti i file quando viene creato il pacchetto. È comunque necessario modificare i valori segnaposto in altre parti del manifesto.

Da una DLL di assembly

Nel caso di base della creazione di un pacchetto da un assembly, è possibile generare un file con estensione nuspec dai metadati nell'assembly usando il comando seguente:

nuget spec <assembly-name>.dll

L'utilizzo di questo formulario sostituisce alcuni segnaposto nel manifest con valori specifici provenienti dall'assembly. Ad esempio, la <id> proprietà viene impostata sul nome dell'assembly e <version> viene impostata sulla versione dell'assembly. Altre proprietà nel manifest, tuttavia, non hanno valori corrispondenti nell'assembly. Queste proprietà contengono ancora segnaposto dopo l'esecuzione del comando.

Da un progetto di Visual Studio

La creazione di un file con estensione nuspec da un file con estensione csproj o vbproj è utile, perché gli altri pacchetti installati nel progetto vengono automaticamente indicati come dipendenze. Per creare un manifesto da un file di progetto, usare il comando seguente nella cartella contenente il file di progetto:

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

Il file project-name.nuspec< risultante> contiene token che vengono sostituiti in fase di creazione del pacchetto con valori del progetto, inclusi i riferimenti a tutti gli altri pacchetti già installati.

Se sono presenti dipendenze del pacchetto da includere in .nuspec, usare nuget packinvece . Ottenere quindi il file con estensione nuspec dall'interno del file con estensione nupkg generato. Ad esempio, usare il comando seguente:

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

Un token è delimitato da $ simboli su entrambi i lati della proprietà del progetto. Ad esempio, il <id> valore in un manifesto generato in questo modo è in genere simile alla riga seguente:

<id>$id$</id>

Questo token viene sostituito con il AssemblyName valore del file di progetto in fase di compressione. Per il mapping esatto dei valori del progetto ai token del file con estensione .nuspec, vedere Token di sostituzione.

I token evitano la necessità di aggiornare valori cruciali come il numero di versione nel file con estensione nuspec durante l'aggiornamento del progetto. Ma è anche possibile sostituire i token con valori letterali.

Quando si lavora da un progetto di Visual Studio sono disponibili diverse opzioni aggiuntive per la creazione di pacchetti, come descritto in Run nuget pack per generare il file con estensione nupkg più avanti in questo articolo.

Pacchetti a livello di soluzione

Solo per NuGet 2.x. Non disponibile in NuGet 3.0+.

NuGet 2.x supporta la nozione di pacchetto a livello di soluzione che installa strumenti o comandi aggiuntivi per la Console di Gestione Pacchetti (i contenuti della cartella tools), ma non aggiunge riferimenti, contenuti o personalizzazioni di compilazione a nessun progetto della soluzione. Tali pacchetti non contengono file nelle cartelle dirette lib, contenuto o compilazione, e nessuna delle relative dipendenze include file nelle rispettive cartelle lib, contenuto o compilazione.

NuGet tiene traccia dei pacchetti installati a livello di soluzione in un file packages.config nella cartella nuget , anziché nel file packages.config del progetto.

Da un nuovo file con valori predefiniti

Il comando seguente crea un manifesto predefinito con segnaposto, che consente di iniziare con la struttura di file corretta:

nuget spec [<package-name>]

Se si omette <package-name>, il file risultante è denominato Package.nuspec. Se si specifica un nome, ad Contoso.Utility.UsefulStuffesempio , il file è denominato Contoso.Utility.UsefulStuff.nuspec.

Il file con estensione nuspec risultante contiene segnaposto per valori come projectUrl. Prima di utilizzare il file per creare il file finale .nupkg, sostituite i segnaposto con i valori appropriati.

Scegliere un identificatore univoco del pacchetto e impostare il numero di versione

L'identificatore del pacchetto (<id> elemento) e il numero di versione (<version> elemento ) sono i due valori più importanti nel manifesto, perché identificano in modo univoco il codice esatto contenuto nel pacchetto.

Procedure consigliate per l'identificatore del pacchetto

• Univocità: l'identificatore deve essere univoco nella raccolta che ospita il pacchetto, ad esempio nuget.org. Prima di decidere un identificatore, cercare nella raccolta applicabile per verificare se il nome è già in uso. Per evitare conflitti, un modello valido consiste nell'usare il nome della società come prima parte dell'identificatore, ad esempio Contoso.
• Namespace-like names: seguire un modello simile ai namespace in .NET, usando la notazione a punti anziché utilizzare i trattini. Ad esempio, usare Contoso.Utility.UsefulStuff anziché Contoso-Utility-UsefulStuff o Contoso_Utility_UsefulStuff. I consumatori trovano inoltre utile quando l'identificatore del pacchetto corrisponde ai namespace usati nel codice.
• Pacchetti esempio: se viene prodotto un pacchetto di codice di esempio che dimostra come usare un altro pacchetto, allegare .Sample come suffisso all'identificatore, come in Contoso.Utility.UsefulStuff.Sample. Un pacchetto di esempio di questo tipo ha una dipendenza dal pacchetto che illustra come usare. ** Quando si crea un pacchetto di esempio, utilizzare il metodo della directory di lavoro convenzionale precedentemente descritto. Nella cartella del contenuto disporre il codice di esempio in una cartella denominata \Samples\<identifier>, come in \Samples\Contoso.Utility.UsefulStuff.Sample.

Procedure consigliate per la versione del pacchetto

• In generale, impostare la versione del pacchetto in modo che corrisponda alla libreria. Queste indicazioni sono consigliate ma non strettamente necessarie. Questa procedura è semplice quando si limita un pacchetto a un singolo assembly, come descritto in precedenza in Decidere quali assembly impacchettare. In generale, tenere presente che NuGet gestisce le versioni dei pacchetti durante la risoluzione delle dipendenze, non le versioni degli assembly.
• Quando si usa uno schema di versione non standard, prendere in considerazione le regole di controllo delle versioni di NuGet come illustrato in Controllo delle versioni dei pacchetti.

Per altre risorse utili per comprendere il controllo delle versioni, vedere la serie seguente di brevi post di blog:

• Parte 1: Affrontare il problema del DLL Hell
• Parte 2: Algoritmo principale
• Parte 3: Unificazione tramite reindirizzamenti di binding

Aggiungere un file read-me e altri file

Per specificare direttamente i file da includere nel pacchetto, usare il nodo <files> nel file con estensione nuspec, che segue il <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>

Suggerimento

Quando si utilizza l'approccio della directory di lavoro basata su convenzioni, è possibile inserire il file readme.md nella radice del pacchetto e altri contenuti nella cartella content. Nessun <file> elemento è necessario nel manifesto.

Per includere un file read-me nel pacchetto, usare l'elemento readme di metadati per specificare il percorso di destinazione del file read-me. Usare anche un file elemento di metadati per specificare il percorso di origine e la cartella di destinazione del file read-me. Per altre informazioni, vedere 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 visualizza il contenuto del file read-me nell'interfaccia utente di Package Manager. Ad esempio, lo screenshot seguente mostra il file read-me per il HtmlAgilityPack pacchetto:

Annotazioni

Se si include un nodo vuoto <files> nel file con estensione nuspec , NuGet include il contenuto della cartella lib nel pacchetto, ma nessun altro contenuto.

Includere i props e le destinazioni di MSBuild in un pacchetto

In alcuni casi, è possibile aggiungere destinazioni o proprietà di compilazione personalizzate ai progetti che utilizzano il pacchetto, ad esempio l'esecuzione di uno strumento personalizzato o un processo durante la compilazione. Per maggiori informazioni sui target e le proprietà di compilazione personalizzate, vedere MSBuild .props e .targets in un pacchetto.

Creare <file package-id.targets> o <package-id.props>, ad esempio Contoso.Utility.UsefulStuff.targets, nelle cartelle di compilazione del progetto.

Quindi, nel file con estensione nuspec fare riferimento a questi file nel <files> nodo:

<?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>

Quando i pacchetti vengono aggiunti a un progetto, NuGet include automaticamente queste proprietà e destinazioni.

Eseguire nuget pack per generare il file con estensione nupkg

Quando viene utilizzato un assembly o una directory di lavoro basata su convenzioni, crea un pacchetto eseguendo nuget pack utilizzando il file .nuspec. Nel comando seguente sostituire <project-name> con il nome del progetto:

nuget pack <project-name>.nuspec

Quando si usa un progetto Visual Studio, eseguire nuget pack con il file di progetto. Questo comando carica automaticamente il file con estensione nuspec del progetto e sostituisce tutti i token in esso contenuti con i valori corrispondenti nel file di progetto:

nuget pack <project-name>.csproj

Annotazioni

Per la sostituzione dei token, è necessario usare direttamente il file di progetto, perché il progetto è l'origine dei valori del token. La sostituzione del token non riesce se si usa nuget pack con un file con estensione nuspec .

In tutti i casi, nuget pack esclude le cartelle che iniziano con un punto, ad esempio .git o .hg.

NuGet indica se sono presenti errori nel file con estensione nuspec che richiedono la correzione, ad esempio i valori segnaposto nel manifesto che devono essere aggiornati.

Una volta che nuget pack ha avuto successo, si dispone di un file .nupkg che è possibile pubblicare in una raccolta appropriata, come descritto in Pubblicare pacchetti NuGet.

Suggerimento

Un modo utile per esaminare un pacchetto dopo averlo creato consiste nell'aprirlo nello strumento Esplora pacchetti . Questo strumento offre una visualizzazione grafica del contenuto del pacchetto e del relativo manifesto. È anche possibile rinominare il file con estensione nupkg risultante in un file .zip ed esplorare direttamente il relativo contenuto.

Opzioni aggiuntive

È possibile usare varie opzioni della riga di comando con nuget pack per escludere i file, ignorare il numero di versione nel manifesto e modificare la cartella di output, tra le altre funzionalità. Per un elenco completo, vedere Comando pack (interfaccia della riga di comando NuGet).

Di seguito sono riportate alcune opzioni comuni ai progetti Visual Studio:

• Progetti a cui si fa riferimento: se il progetto fa riferimento ad altri progetti, è possibile aggiungere i progetti a cui si fa riferimento come parte del pacchetto o come dipendenze usando l'opzione -IncludeReferencedProjects :

  nuget pack MyProject.csproj -IncludeReferencedProjects
  

  Questo processo di inclusione è ricorsivo. Ad esempio, se MyProject.csproj fa riferimento a progetti B e C e tali progetti fanno riferimento a D, E e F, i file da B, C, D, E e F sono inclusi nel pacchetto.

  Se un progetto a cui si fa riferimento include un file con estensione nuspec personalizzato, NuGet aggiunge invece il progetto a cui si fa riferimento come dipendenza. È necessario creare un pacchetto e pubblicare il progetto separatamente.

• Configurazione della compilazione: Per impostazione predefinita, NuGet usa la configurazione di compilazione predefinita impostata nel file di progetto, tipicamente in Debug. Per comprimere i file da una configurazione di compilazione diversa, ad esempio Release, usare l'opzione -properties con la configurazione:

  nuget pack MyProject.csproj -properties Configuration=Release
  

• Simboli: per includere simboli che consentono agli utenti di eseguire il debug del codice del pacchetto, usare le opzioni e -Symbols. Per l'opzione -SymbolPackageFormat specificare un formato di snupkg:

  nuget pack MyProject.csproj -symbols -SymbolPackageFormat snupkg
  

Installazione del pacchetto di test

Prima di pubblicare un pacchetto, in genere si vuole testare il processo di installazione del pacchetto in un progetto. Un test consente di assicurarsi che tutti i file necessari vengano inseriti nella posizione corretta nel progetto.

È possibile testare le installazioni manualmente in Visual Studio o nella riga di comando usando i passaggi di installazione standard package.

Per i test automatizzati, è possibile usare il processo di base seguente:

1. Copiare il file con estensione nupkg in una cartella locale.
2. Aggiungere la cartella alle origini del pacchetto usando il nuget sources add -name <name> -source <path> comando . Per altre informazioni, vedere comando sources (interfaccia della riga di comando NuGet). È necessario impostare questa origine locale una sola volta in un determinato computer.
3. Installare il pacchetto da tale origine usando nuget install <package-ID> -source <name>. In questo comando <name> deve corrispondere al nome dell'origine usata nel nuget sources comando . Se si specifica l'origine, viene indicato a NuGet di installare il pacchetto solo da tale origine.
4. Esaminare il file system per verificare che i file siano installati correttamente.

Contenuti correlati

Dopo aver creato un pacchetto, ovvero un file con estensione nupkg , è possibile pubblicarlo nella raccolta di propria scelta. Per altre informazioni, vedere Pubblicare pacchetti NuGet.

È anche possibile estendere le funzionalità del pacchetto o supportare altri scenari. Per altre informazioni, consultare gli articoli seguenti:

• Controllo delle versioni dei pacchetti
• Supporta più versioni di .NET
• Trasformazione del codice sorgente e dei file di configurazione
• Creazione di pacchetti NuGet localizzati
• Compilazione di pacchetti pre-rilascio
• Impostare un tipo di pacchetto NuGet
• Creare pacchetti NuGet che contengono assembly di interoperabilità COM

Per conoscere altri tipi di pacchetto, vedere gli articoli seguenti:

• Creazione di pacchetti nativi
• Creazione di pacchetti di simboli (.snupkg)