dotnet publish

Questo articolo si applica a: ✔️ .NET Core 3.1 SDK e versioni successive

Nome

dotnet publish - Pubblica l'applicazione e le relative dipendenze in una cartella per la distribuzione in un sistema di hosting.

Riepilogo

dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--manifest <PATH_TO_MANIFEST_FILE>] [--no-build] [--no-dependencies]
    [--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained [true|false]] [--no-self-contained]
    [-s|--source <SOURCE>] [--use-current-runtime, --ucr [true|false]]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

Descrizione

dotnet publish compila l'applicazione, legge le relative dipendenze specificate nel file di progetto e pubblica il set di file risultante in una directory. L'output include gli asset seguenti:

• Codice linguaggio intermedio (IL) in un assembly con un'estensione dll.
• File con estensione deps.json che include tutte le dipendenze del progetto.
• File con estensione runtimeconfig.json che specifica il runtime condiviso previsto dall'applicazione, nonché altre opzioni di configurazione per il runtime, ad esempio il tipo di Garbage Collection.
• Dipendenze dell'applicazione copiate dalla cache NuGet nella cartella di output.

L'output del comando dotnet publish è pronto per la distribuzione in un sistema di hosting (ad esempio, un server, un PC, un Mac, un laptop) per l'esecuzione. È l'unico metodo supportato ufficialmente per preparare l'applicazione per la distribuzione. A seconda del tipo di distribuzione specificato dal progetto, è possibile che nel sistema di hosting sia installato o meno il runtime condiviso .NET. Per altre informazioni, vedere Pubblicare app .NET con l'interfaccia della riga di comando di .NET.

Ripristino implicito

Non è necessario eseguire dotnet restore perché viene eseguito in modo implicito da tutti i comandi che richiedono un ripristino, ad esempio dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishe dotnet pack. Per disabilitare il ripristino implicito, usare l'opzione --no-restore .

Il dotnet restore comando è ancora utile in determinati scenari in cui il ripristino esplicito ha senso, ad esempio le compilazioni di integrazione continua in Azure DevOps Services o nei sistemi di compilazione che devono controllare in modo esplicito quando si verifica il ripristino.

Per informazioni su come gestire i feed NuGet, vedere la dotnet restore documentazione.

MSBuild

Il comando dotnet publish chiama MSBuild che richiama la destinazione Publish. Se la IsPublishable proprietà è impostata su false per un determinato progetto, la Publish destinazione non può essere richiamata e il dotnet publish comando esegue solo il ripristino dotnet implicito nel progetto.

Tutti i parametri passati a dotnet publish vengono passati a MSBuild. I parametri -c e -o sono mappati rispettivamente alle proprietà Configuration e PublishDir di MSBuild.

Il dotnet publish comando accetta le opzioni di MSBuild, ad esempio -p per l'impostazione delle proprietà e -l per definire un logger. Ad esempio, è possibile impostare una proprietà MSBuild usando il formato : -p:<NAME>=<VALUE>.

File con estensione pubxml

È anche possibile impostare proprietà correlate alla pubblicazione facendo riferimento a un file con estensione pubxml . Ad esempio:

dotnet publish -p:PublishProfile=FolderProfile

Nell'esempio precedente viene utilizzato il file FolderProfile.pubxml presente nella <cartella project_folder>/Properties/PublishProfiles . Se si specifica un percorso e un'estensione di file durante l'impostazione della PublishProfile proprietà, vengono ignorati. MSBuild per impostazione predefinita cerca nella cartella Properties/PublishProfiles e presuppone l'estensione di file pubxml . Per specificare il percorso e il nome file, inclusa l'estensione, impostare la PublishProfileFullPath proprietà anziché la PublishProfile proprietà .

Nel file .pubxml :

• PublishUrl viene usato da Visual Studio per indicare la destinazione Pubblica.
• PublishDir viene usato dall'interfaccia della riga di comando per indicare la destinazione Di pubblicazione.

Se si vuole che lo scenario funzioni in tutte le posizioni, è possibile inizializzare entrambe queste proprietà sullo stesso valore nel file con estensione pubxml . Quando il problema di GitHub dotnet/sdk#20931 viene risolto, è necessario impostare solo una di queste proprietà.

Alcune proprietà nel file .pubxml vengono rispettate solo da Visual Studio e non hanno alcun effetto su dotnet publish. Stiamo lavorando per rendere l'interfaccia della riga di comando più allineata al comportamento di Visual Studio. Tuttavia, alcune proprietà non verranno mai usate dall'interfaccia della riga di comando. L'interfaccia della riga di comando e Visual Studio eseguono entrambi l'aspetto della creazione di pacchetti della pubblicazione e dotnet/sdk#29817 prevede di aggiungere il supporto per altre proprietà correlate. L'interfaccia della riga di comando, tuttavia, non esegue l'aspetto di automazione della distribuzione della pubblicazione e le proprietà correlate a che non sono supportate. Le proprietà .pubxml più importanti che non sono supportate da dotnet publish sono quelle seguenti che influiscono sulla compilazione:

• LastUsedBuildConfiguration
• Configuration
• Platform
• LastUsedPlatform
• TargetFramework
• TargetFrameworks
• RuntimeIdentifier
• RuntimeIdentifiers

proprietà di MSBuild

Le proprietà MSBuild seguenti modificano l'output di dotnet publish.

• PublishReadyToRun

  Compila gli assembly dell'applicazione come formato ReadyToRun (R2R). R2R è un formato di compilazione AOT (Ahead-of-time). Per altre informazioni, vedere Immagini ReadyToRun.

  Per visualizzare avvisi sulle dipendenze mancanti che potrebbero causare errori di runtime, usare PublishReadyToRunShowWarnings=true.

  È consigliabile specificare PublishReadyToRun in un profilo di pubblicazione anziché nella riga di comando.

• PublishSingleFile

  Inserisce l'app in un eseguibile a file singolo specifico della piattaforma. Per altre informazioni sulla pubblicazione di file singolo, vedere il documento sulla progettazione di un bundler con file singolo.

  È consigliabile specificare questa opzione nel file di progetto anziché nella riga di comando.

• PublishTrimmed

  Taglia le librerie inutilizzate per ridurre le dimensioni di distribuzione di un'app durante la pubblicazione di un eseguibile autonomo. Per altre informazioni, vedere Trim self-contained deployments and executables .For more information, see Trim self-contained deployments and executables. Disponibile a partire da .NET 6 SDK.

  È consigliabile specificare questa opzione nel file di progetto anziché nella riga di comando.

Per altre informazioni, vedere le risorse seguenti:

• Riferimenti alla riga di comando di MSBuild
• Profili di pubblicazione di Visual Studio (.pubxml) per la distribuzione di app ASP.NET Core
• dotnet msbuild

Download del manifesto del carico di lavoro

Quando si esegue questo comando, avvia un download in background asincrono dei manifesti pubblicitari per i carichi di lavoro. Se il download è ancora in esecuzione al termine di questo comando, il download viene arrestato. Per altre informazioni, vedere Manifesti pubblicitari.

Argomenti

• PROJECT|SOLUTION

  Progetto o soluzione da pubblicare.

  • PROJECT è il percorso e il nome file di un file di progetto C#, F#o Visual Basic oppure il percorso di una directory che contiene un file di progetto C#, F# o Visual Basic. Se la directory non viene specificata, per impostazione predefinita viene predefinito la directory corrente.

  • SOLUTION è il percorso e il nome file di un file di soluzione (estensione sln ) o il percorso di una directory che contiene un file di soluzione. Se la directory non viene specificata, per impostazione predefinita viene predefinito la directory corrente.

Opzioni

• -a|--arch <ARCHITECTURE>

  Specifica l'architettura di destinazione. Si tratta di una sintassi abbreviata per l'impostazione dell'identificatore di runtime (RID), in cui il valore fornito viene combinato con il RID predefinito. Ad esempio, in un win-x64 computer, specificando --arch x86 imposta il RID su win-x86. Se si usa questa opzione, non usare l'opzione -r|--runtime . Disponibile a partire da .NET 6 Preview 7.

• -c|--configuration <CONFIGURATION>

  Definisce la configurazione di compilazione. Il valore predefinito per la maggior parte dei progetti è Debug, ma è possibile eseguire l'override delle impostazioni di configurazione della compilazione nel progetto.

• -f|--framework <FRAMEWORK>

  Pubblica l'applicazione per il framework di destinazione specificato. È necessario specificare il framework di destinazione nel file di progetto.

• --force

  Forza la risoluzione di tutte le dipendenze, anche se l'ultimo ripristino ha avuto esito positivo. La specifica di questo flag equivale all'eliminazione del file project.assets.json.

• -?|-h|--help

  Stampa una descrizione di come usare il comando .

• --interactive

  Consente al comando di arrestarsi e attendere l'input o l'azione dell'utente, ad esempio il completamento dell'autenticazione. Disponibile a partire da .NET Core 3.0 SDK.

• --manifest <PATH_TO_MANIFEST_FILE>

  Specifica uno o più manifesti di destinazione da usare per rimuovere il set di pacchetti pubblicati con l'app. Il file manifesto fa parte dell'output del dotnet store comando. Per specificare più manifesti, aggiungere un'opzione --manifest per ogni manifesto.

• --no-build

  Non compila il progetto prima della pubblicazione. Imposta anche in modo implicito il flag --no-restore.

• --no-dependencies

  Ignora i riferimenti da progetto a progetto e ripristina solo il progetto radice.

• --nologo

  Non visualizza il messaggio di avvio né il messaggio di copyright.

• --no-restore

  Non esegue un ripristino implicito quando si esegue il comando.

• -o|--output <OUTPUT_DIRECTORY>

  Specifica il percorso della directory di output.

  Se non specificato, il valore predefinito è [project_file_folder]/bin/[configuration]/[framework]/publish/ per un eseguibile dipendente dal framework e file binari multipiattaforma. Per impostazione predefinita , [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ per un eseguibile autonomo.

  In un progetto Web, se la cartella di output si trova nella cartella del progetto, i comandi successivi dotnet publish generano cartelle di output annidate. Ad esempio, se la cartella del progetto è myproject e la cartella di output di pubblicazione è myproject/publish e si esegue dotnet publish due volte, la seconda esegue i file di contenuto, ad esempio .config e json in myproject/publish/publish. Per evitare di annidare le cartelle di pubblicazione, specificare una cartella di pubblicazione che non si trova direttamente nella cartella del progetto o escludere la cartella publish dal progetto. Per escludere una cartella di pubblicazione denominata publishoutput, aggiungere l'elemento seguente a un PropertyGroup elemento nel file con estensione csproj :

  <DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>
  

  • .NET 7.0.200 SDK e versioni successive

    Se si specifica l'opzione --output quando si esegue questo comando in una soluzione, l'interfaccia della riga di comando genererà un avviso (errore nella versione 7.0.200) a causa della semantica non chiara del percorso di output. L'opzione --output non è consentita perché tutti gli output di tutti i progetti compilati vengono copiati nella directory specificata, che non è compatibile con progetti con più destinazioni, nonché progetti con versioni diverse di dipendenze dirette e transitive. Per altre informazioni, vedere Opzione a livello --output di soluzione non più valida per i comandi correlati alla compilazione.

  • .NET Core 3.x SDK e versioni successive

    Se si specifica un percorso relativo durante la pubblicazione di un progetto, la directory di output generata è relativa alla directory di lavoro corrente, non al percorso del file di progetto.

    Se si specifica un percorso relativo durante la pubblicazione di una soluzione, tutti gli output per tutti i progetti vengono inseriti nella cartella specificata rispetto alla directory di lavoro corrente. Per rendere l'output di pubblicazione passare a cartelle separate per ogni progetto, specificare un percorso relativo usando la proprietà msbuild PublishDir anziché l'opzione --output . Ad esempio, dotnet publish -p:PublishDir=.\publish invia l'output di pubblicazione per ogni progetto a una publish cartella nella cartella che contiene il file di progetto.

  • .NET Core 2.x SDK

    Se si specifica un percorso relativo durante la pubblicazione di un progetto, la directory di output generata è relativa al percorso del file di progetto, non alla directory di lavoro corrente.

    Se si specifica un percorso relativo durante la pubblicazione di una soluzione, l'output di ogni progetto viene inserito in una cartella separata rispetto al percorso del file di progetto. Se si specifica un percorso assoluto durante la pubblicazione di una soluzione, tutti gli output di pubblicazione per tutti i progetti vengono inseriti nella cartella specificata.

• --os <OS>

  Specifica il sistema operativo di destinazione. Si tratta di una sintassi abbreviata per l'impostazione dell'identificatore di runtime (RID), in cui il valore fornito viene combinato con il RID predefinito. Ad esempio, in un win-x64 computer, specificando --os linux imposta il RID su linux-x64. Se si usa questa opzione, non usare l'opzione -r|--runtime . Disponibile a partire da .NET 6.

• --sc|--self-contained [true|false]

  Pubblica il runtime .NET con l'applicazione in modo che il runtime non debba essere installato nel computer di destinazione. Il valore predefinito è true se viene specificato un identificatore di runtime e il progetto è un progetto eseguibile (non un progetto di libreria). Per altre informazioni, vedere Pubblicazione di applicazioni .NET e Pubblicazione di app .NET con l'interfaccia della riga di comando di .NET.

  Se questa opzione viene usata senza specificare true o false, il valore predefinito è true. In tal caso, non inserire l'argomento della soluzione o del progetto immediatamente dopo --self-contained, perché true o false è previsto in tale posizione.

• --no-self-contained

  Equivalente a --self-contained false.

• --source <SOURCE>

  URI dell'origine del pacchetto NuGet da usare durante l'operazione di ripristino.

• -r|--runtime <RUNTIME_IDENTIFIER>

  Pubblica l'applicazione per un determinato runtime. Per un elenco degli identificatori di runtime (RID, Runtime Identifier), vedere il catalogo RID. Per altre informazioni, vedere Pubblicazione di applicazioni .NET e Pubblicazione di app .NET con l'interfaccia della riga di comando di .NET. Se si usa questa opzione, usare --self-contained o --no-self-contained anche.

• -v|--verbosity <LEVEL>

  Imposta il livello di dettaglio del comando. I valori consentiti sono q[uiet], m[inimal], n[ormal], d[etailed] e diag[nostic]. Il valore predefinito è minimal. Per altre informazioni, vedere LoggerVerbosity.

• --use-current-runtime, --ucr [true|false]

  Imposta su RuntimeIdentifier una piattaforma portabile RuntimeIdentifier in base a quella del computer. Ciò avviene in modo implicito con le proprietà che richiedono un RuntimeIdentifier, ad esempio SelfContained, PublishAot, PublishSelfContained, PublishSingleFilee PublishReadyToRun. Se la proprietà è impostata su false, la risoluzione implicita non verrà più eseguita.

• --version-suffix <VERSION_SUFFIX>

  Definisce il suffisso di versione che sostituirà l'asterisco (*) nel campo del file di progetto relativo alla versione.

Esempio

• Creare un file binario multipiattaforma dipendente dal framework per il progetto nella directory corrente:

  dotnet publish
  

  A partire da .NET Core 3.0 SDK, questo esempio crea anche un eseguibile dipendente dal framework per la piattaforma corrente.

• Creare un eseguibile autonomo per il progetto nella directory corrente, per un runtime specifico:

  dotnet publish --runtime osx.10.11-x64
  

  Il rid deve trovarsi nel file di progetto.

• Creare un eseguibile dipendente dal framework per il progetto nella directory corrente, per una piattaforma specifica:

  dotnet publish --runtime osx.10.11-x64 --self-contained false
  

  Il rid deve trovarsi nel file di progetto. Questo esempio si applica a .NET Core 3.0 SDK e versioni successive.

• Pubblicare il progetto nella directory corrente per un runtime specifico e un framework di destinazione:

  dotnet publish --framework netcoreapp3.1 --runtime osx.10.11-x64
  

• Pubblicare il file di progetto specificato:

  dotnet publish ~/projects/app1/app1.csproj
  

• Pubblicare l'applicazione corrente ma non ripristinare riferimenti da progetto a progetto (P2P), solo il progetto radice durante l'operazione di ripristino:

  dotnet publish --no-dependencies
  

Vedi anche

• Panoramica della pubblicazione di applicazioni .NET
• Pubblicare app .NET con l'interfaccia della riga di comando di .NET
• Framework di destinazione
• Catalogo RID (Runtime Identifier)
• Containerizzare un'app .NET con dotnet publish
• Uso della notarizzazione di macOS Catalina
• Struttura di directory di un'applicazione pubblicata
• Riferimenti alla riga di comando di MSBuild
• Profili di pubblicazione di Visual Studio (.pubxml) per la distribuzione di app ASP.NET Core
• dotnet msbuild
• Trimming delle distribuzioni autonome