dotnet publish

  • Articolo

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>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
    [-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>] [--tl:[auto|on|off]]
    [--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 .deps.json che include tutte le dipendenze del progetto.
  • File .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, il sistema di hosting può avere o meno installato 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 publish e dotnet pack. Per disabilitare il ripristino implicito, usare l'opzione --no-restore.

Il comando dotnet restore è ancora utile in alcuni scenari in cui ha senso eseguire un ripristino esplicito, ad esempio le compilazioni di integrazione continua in Azure DevOps Services o in sistemi di compilazione che richiedono il controllo esplicito quando viene eseguito 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 proprietàIsPublishable è impostata su false per un determinato progetto, non è possibile richiamare la destinazione Publish e il comando dotnet publish esegue solo il comando implicito dotnet restore 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 comando dotnet publish accetta le opzioni di MSBuild, come -p per impostare le proprietà e -l per definire un logger. Ad esempio, è possibile impostare una proprietà MSBuild usando il formato: -p:<NAME>=<VALUE>.

File .pubxml

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

dotnet publish -p:PublishProfile=FolderProfile

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

Nel file .pubxml:

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

Se si desidera che lo scenario funzioni in tutte le posizioni, è possibile inizializzare entrambe le proprietà allo stesso valore nel file .pubxml.. Quando viene risolto il problema di GitHub dotnet/sdk#20931, è 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 completare l'allineamento dell'interfaccia della riga di comando con il 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 e dotnet/sdk#29817 prevede di aggiungere il supporto per altre proprietà correlate. Tuttavia, l'interfaccia della riga di comando non si occupa dell'aspetto di automazione della distribuzione della pubblicazione e le proprietà correlate che non sono supportate. Le proprietà .pubxml più importanti che non sono supportate da dotnet publish sono quelle seguenti, che non influiscono sulla compilazione:

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

proprietà di MSBuild

Le proprietà di 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 ReadyToRun images.

    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

    Crea il pacchetto dell'app come file eseguibile singolo specifico per la 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 Trimming di distribuzioni ed eseguibili autonomi. Disponibile da .NET 6 SDK.

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

Per ulteriori informazioni, vedi le seguenti risorse:

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 contenente un file di progetto C#, F# o Visual Basic. Se la directory non è specificata, la scelta predefinita è 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 della soluzione. Se la directory non è specificata, la scelta predefinita è 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 computer win-x64, specificando --arch x86 si 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.

  • --artifacts-path <ARTIFACTS_DIR>

    Tutti i file di output di compilazione del comando eseguito verranno inseriti nelle sottocartelle nel percorso specificato, separati dal progetto. Per altre informazioni, vedere Layout output artefatti. Disponibile a partire da .NET 8 SDK.

  • -c|--configuration <CONFIGURATION>

    Definisce la configurazione di compilazione. Se si sviluppa con .NET 8 SDK o una versione successiva, il comando usa la Release configurazione per impostazione predefinita per i progetti il cui targetFramework è impostato su net8.0 o una versione successiva. La configurazione di compilazione predefinita è Debug per le versioni precedenti dell'SDK e per i framework di destinazione precedenti. È possibile eseguire l'override del valore predefinito nelle impostazioni del progetto o usando questa opzione. Per altre informazioni, vedere 'dotnet publish' uses Release configuration and 'dotnet pack' uses Release configuration.For more information, see 'dotnet publish' uses Release configuration and 'dotnet pack' uses Release configuration.

  • --disable-build-servers

    Forza il comando a ignorare tutti i server di compilazione persistenti. Questa opzione consente di disabilitare in modo coerente l'uso della memorizzazione nella cache di compilazione, che forza una compilazione da zero. Una compilazione che non si basa sulle cache è utile quando le cache potrebbero essere danneggiate o errate per qualche motivo. Disponibile da .NET 7 SDK.

  • -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 comando dotnet store. 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 viene specificato, il valore predefinito è [project_file_folder]/bin/[configuration]/[framework]/publish/ per un file eseguibile dipendente dal framework e file binari multipiattaforma. L'impostazione predefinita è [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ per un file eseguibile autonomo.

    In un progetto Web, se la cartella di output si trova nella cartella del progetto, i comandi dotnet publish successivi generano cartelle di output annidate. Ad esempio, se la cartella del progetto è myprojecte la cartella di output di pubblicazione è myproject/publishe si esegue dotnet publish due volte, la seconda esegue file di contenuto come .config e file .json in myproject/publish/publish. Per evitare l'annidamento delle cartelle di pubblicazione, specificare una cartella di pubblicazione che non sia direttamente sotto la cartella del progetto, oppure escludere la cartella di pubblicazione dal progetto. Per escludere una cartella di pubblicazione denominata publishoutput, aggiungere l'elemento seguente a un elemento PropertyGroup nel file .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 (un 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 verrebbero copiati nella directory specificata e questo non è compatibile con progetti con più destinazioni, né con progetti con versioni diverse di dipendenze dirette e transitive. Per altre informazioni, vedere l'opzione a livello di soluzione --output non più valida per i comandi correlati alla compilazione.

    • .NET Core 3.x SDK e versioni successive

      Se viene specificato 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 di tutti i progetti vengono inseriti nella cartella specificata rispetto alla directory di lavoro corrente. Per fare in modo che l'output di pubblicazione vada in 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 cartella publish nella cartella che contiene il file di progetto.

    • .NET Core 2.x SDK

      Se viene specificato 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 viene specificato 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 viene specificato 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 computer win-x64, specificando --os linux si 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 non sia necessario installarlo 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 questo caso, non inserire l'argomento della soluzione o del progetto subito dopo --self-contained, perché in quella posizione è previsto true o false 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 anche --self-contained o --no-self-contained.

  • --tl:[auto|on|off]

    Specifica se il logger del terminale deve essere usato per l'output di compilazione. Il valore predefinito è auto, che prima di abilitare la registrazione del terminale verifica l'ambiente. Prima di abilitare il nuovo logger, il controllo dell'ambiente verifica che il terminale sia in grado di usare le funzionalità di output moderne e che non utilizzi un output standard reindirizzato. on ignora il controllo dell'ambiente e abilita la registrazione del terminale. off ignora il controllo dell'ambiente e usa il logger di console predefinito.

    Il logger del terminale mostra la fase di ripristino seguita dalla fase di compilazione. Durante ogni fase, i progetti che sono in corso di compilazione vengono visualizzati nella parte inferiore del terminale. Ogni progetto che compila restituisce sia la destinazione MSBuild attualmente in fase di compilazione che la quantità di tempo impiegato per tale destinazione. È possibile cercare queste informazioni per altre informazioni sulla compilazione. Al termine della compilazione di un progetto, viene scritta una singola sezione "compilazione completata" che acquisisce:

    • Il nome del progetto compilato.
    • Il framework di destinazione (se sono presenti più destinazioni).
    • Lo stato della compilazione.
    • L'output primario di tale compilazione (con collegamento ipertestuale).
    • Qualsiasi diagnostica generata per il progetto.

    Questa opzione è disponibile a partire da .NET 8.

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

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

  • -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 ulteriori informazioni, vedere LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

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

Esempi

  • 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 file eseguibile dipendente dal framework per la piattaforma corrente.

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

    dotnet publish --runtime osx-x64

    Il RID deve trovarsi nel file di progetto.

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

    dotnet publish --runtime osx-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 e un framework di destinazione specifico:

    dotnet publish --framework net8.0 --runtime osx-x64

  • Pubblicare il file di progetto specificato:

    dotnet publish ~/projects/app1/app1.csproj

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

    dotnet publish --no-dependencies

Vedi anche