Condividi tramite

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.

Sinossi

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 del 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, PC, Mac, portatile) per l'esecuzione. È l'unico modo ufficialmente supportato 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 comando dotnet restore è ancora utile in alcuni scenari in cui il ripristino esplicito ha senso, ad esempio 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 documentazione dotnet restore.

MSBuild

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

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

Il comando dotnet publish accetta opzioni di MSBuild, ad esempio -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 con estensione pubxml

È anche possibile impostare proprietà correlate alla pubblicazione facendo riferimento a un file .pubxml . Per 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, 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 queste proprietà sullo stesso valore nel file .pubxml. Quando si risolve 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 della pubblicazione e dotnet/sdk#29817 prevede di aggiungere il supporto per altre proprietà correlate. Tuttavia, l'interfaccia della riga di comando non esegue l'aspetto di automazione della distribuzione della pubblicazione e le proprietà correlate a che non sono supportate. Le proprietà più importanti .pubxml non supportate da dotnet publish sono le proprietà seguenti che 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 è una forma 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 a file singolo, vedere il documento di progettazione del bundler a 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. 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:

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, per impostazione predefinita viene dicata la directory corrente.

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

Opzioni

  • -a|--arch <ARCHITECTURE>

    Specifica l'architettura di destinazione. Si tratta di una sintassi abbreviata per impostare ilidentificatore di runtime (RID) , in cui il valore fornito viene combinato con il RID predefinito. Ad esempio, in un computer win-x64, specificando --arch x86 imposta 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 di 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 versione successiva, il comando usa la configurazione Release per impostazione predefinita per i progetti i cui TargetFramework è impostato su net8.0 o 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' usa la configurazione della versione e 'dotnet pack' usa la configurazione della versione.

  • --disable-build-servers

    Forza il comando a ignorare tutti i server di compilazione permanenti. 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 a partire 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 è riuscito. Specificare questo flag equivale all'eliminazione del file di project.assets.json.

  • -?|-h|--help

    Stampa una descrizione di come usare il comando .

  • --interactive

    Consente al comando di arrestare e attendere l'input o l'azione dell'utente. Ad esempio, per completare l'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 tagliare 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 banner di avvio o il messaggio di copyright.

  • --no-restore

    Non esegue un ripristino implicito quando si esegue il comando .

  • -o|--output <OUTPUT_DIRECTORY>

    Specifica il percorso per la directory di output.

    Se non specificato, per impostazione predefinita viene [project_file_folder]/bin/[configuration]/[framework]/publish/ per un file 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 è myprojecte la cartella di output di pubblicazione è myproject/publishe si esegue dotnet publish due volte, la seconda esegue file di contenuto, ad esempio .config e .json file in myproject/publish/publish/publish. Per evitare di annidare le cartelle di pubblicazione, specificare una cartella di pubblicazione che non 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 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 verranno 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 di --output a livello 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 cartella publish 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 impostare ilidentificatore di runtime (RID) , in cui il valore fornito viene combinato con il RID predefinito. Ad esempio, in un computer win-x64, specificando --os linux imposta 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 Pubblicare 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), vedere il catalogo RID . Per altre informazioni, vedere pubblicazione di applicazioni .NET e Pubblicare 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. Il controllo dell'ambiente verifica che il terminale sia in grado di usare le funzionalità di output moderne e non usa un output standard reindirizzato prima di abilitare il nuovo logger. 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 attualmente in fase 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:

    • Nome del progetto compilato.
    • Framework di destinazione (se multi-destinazione).
    • Stato della compilazione.
    • 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 il RuntimeIdentifier su un RuntimeIdentifier portabile della piattaforma in base a quello del computer. Ciò avviene in modo implicito con 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.

  • -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.

  • --version-suffix <VERSION_SUFFIX>

    Definisce il suffisso della versione per sostituire l'asterisco (*) nel campo della versione del file di progetto.

Esempi

  • Creare un 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-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-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 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), solo il progetto radice durante l'operazione di ripristino:

    dotnet publish --no-dependencies

Vedere anche