Panoramica della pubblicazione di applicazioni .NET

Questo articolo illustra i diversi modi per pubblicare un'applicazione .NET. Illustra le modalità di pubblicazione, come produrre file eseguibili e file binari multipiattaforma e l'impatto di ogni approccio sugli ambienti di distribuzione e di runtime. È possibile pubblicare applicazioni .NET usando l'interfaccia della riga di comando di .NET o Visual Studio.

Per una breve esercitazione sulla pubblicazione, vedere Esercitazione: Pubblicare un'applicazione console .NET con Visual Studio Code.

Per una breve esercitazione sulla pubblicazione, vedere Esercitazione: Pubblicare un'applicazione console .NET con Visual Studio.

Che cos'è la pubblicazione

La pubblicazione di un'app .NET significa compilare il codice sorgente per creare un file eseguibile o binario, insieme alle relative dipendenze e ai file correlati, per la distribuzione. Dopo la pubblicazione, si distribuisce l'app in un server, una piattaforma di distribuzione, un contenitore o un ambiente cloud. Il processo di pubblicazione prepara un'app per la distribuzione e l'uso all'esterno di un ambiente di sviluppo.

Modalità di pubblicazione

Esistono due modi principali per pubblicare un'app. Alcuni fattori che influenzano questa decisione includono se l'ambiente di distribuzione ha installato il runtime .NET appropriato e se sono necessarie funzionalità di compilazione specifiche che richiedono la creazione di bundle del runtime con l'app. Le due modalità di pubblicazione sono:

• Pubblicare indipendentemente
  Questa modalità produce una cartella di pubblicazione che include un eseguibile specifico della piattaforma usato per avviare l'app, un file binario compilato contenente il codice dell'app, tutte le dipendenze dell'app e il runtime .NET necessario per eseguire l'app. L'ambiente che esegue l'app non deve avere il runtime .NET preinstallato.

• Pubblicare dipendenti dal framework
  Questa modalità produce una cartella di pubblicazione che include un eseguibile facoltativo specifico della piattaforma usato per avviare l'app, un file binario compilato contenente il codice dell'app ed eventuali dipendenze dell'app. L'ambiente che esegue l'app deve avere una versione del runtime .NET installata che l'app può usare.

Importante

Specificare la piattaforma di destinazione con un identificatore di runtime (RID). Per altre informazioni sui RID, vedere catalogo RID .NET.

Nozioni di base sulla pubblicazione

L'impostazione <TargetFramework> del file di progetto specifica il framework di destinazione predefinito quando si pubblica l'app. È possibile modificare il framework di destinazione in qualsiasi moniker del framework di destinazione (TFM) valido. Ad esempio, se il progetto usa <TargetFramework>net9.0</TargetFramework>, viene creato un file binario destinato a .NET 9.

Se si desidera impostare più framework come destinazione, è possibile impostare l'impostazione <TargetFrameworks> su più valori TFM, separati da un punto e virgola. Quando si compila l'app, l'app viene compilata per ogni framework di destinazione definito dal progetto. Tuttavia, quando si pubblica l'app, è necessario specificare il framework di destinazione:

La modalità di configurazione di compilazione predefinita è Release, a meno che non venga modificata con il -c parametro .

dotnet publish -c Release -f net9.0

La directory di output predefinita del dotnet publish comando è ./bin/<BUILD-CONFIGURATION>/<TFM>/publish/. Ad esempio, dotnet publish -c Release -f net9.0 pubblica in ./bin/Release/net9.0/publish/. Tuttavia, è possibile acconsentire esplicitamente a un percorso di output semplificato e a una struttura di cartelle per tutti gli output di compilazione. Per altre informazioni, vedere Layout di output degli artefatti.

In Visual Studio creare profili di pubblicazione separati per ogni framework di destinazione.

File binari portabili

Quando si pubblica un'app .NET, è possibile specificare una piattaforma specifica o creare un file binario portabile. Per impostazione predefinita, anche quando si crea un file binario portabile, .NET pubblica un eseguibile specifico della piattaforma ("apphost") insieme alla DLL portabile, a meno che non si disabiliti in modo esplicito questo comportamento.

L'eseguibile specifico della piattaforma viene creato a causa della UseAppHost proprietà , che per impostazione predefinita è true. Per pubblicare solo la DLL portabile senza l'eseguibile specifico della piattaforma, impostare UseAppHostfalse su nella riga di comando (-p:UseAppHost=false) o come proprietà del progetto.

Il vantaggio della destinazione di una piattaforma specifica è che può gestire le dipendenze native che l'app potrebbe richiedere, garantendo la compatibilità con i requisiti specifici della piattaforma di destinazione.

Dipendenze native

Se l'app ha dipendenze native, potrebbe non essere eseguita in un sistema operativo diverso se pubblicato come file binario portabile. Ad esempio, le app che dipendono dall'API Di Windows non vengono eseguite in modo nativo in macOS o Linux. È necessario fornire codice specifico della piattaforma e compilare un eseguibile per ogni piattaforma.

Considerare anche che, se una libreria a cui si fa riferimento fornisce dipendenze specifiche della piattaforma, l'app potrebbe non essere eseguita in ogni piattaforma. Tuttavia, quando si pubblica e si usa una piattaforma specifica, le dipendenze specifiche della piattaforma di un pacchetto NuGet vengono copiate nella cartella di pubblicazione.

Per assicurarsi che l'app venga pubblicata con le relative dipendenze native, pubblicare per una piattaforma specifica:

dotnet publish -c Release -r <RID>

• -c Release

  Questa opzione imposta la configurazione di compilazione su Release, ottimizzata per la distribuzione di produzione.

• -r <RID>

  Questa opzione usa un identificatore di runtime (RID) per specificare la piattaforma di destinazione e garantisce che le dipendenze native siano incluse (se necessario). Per un elenco degli identificatori di runtime, vedere Catalogo dell'identificatore di runtime (RID).

1. Fare clic con il pulsante destro del mouse sul progetto in Esplora soluzioni e scegliere Pubblica.
2. Se si tratta della prima pubblicazione, selezionare Cartella come destinazione di pubblicazione e selezionare Avanti.
3. Scegliere un percorso della cartella o accettare l'impostazione predefinita, quindi selezionare Fine.
4. Nel profilo di pubblicazione selezionare Mostra tutte le impostazioni.
5. Impostare Runtime di destinazione sulla piattaforma desiderata, ad esempio win-x64 per Windows a 64 bit.
6. Selezionare Salva e quindi Pubblica.

Per un elenco degli identificatori di runtime, vedere Catalogo dell'identificatore di runtime (RID).

Riferimento rapido

La tabella seguente fornisce esempi rapidi di come pubblicare l'app.

Modalità di pubblicazione	Comando
Distribuzione dipendente dal framework	dotnet publish -c Release [-r <RID>]
Distribuzione dipendente dal framework (DLL)	dotnet publish -c Release -p:UseAppHost=false
Distribuzione autonoma	dotnet publish -c Release [-r <RID>] --self-contained true
Distribuzione a file singolo	dotnet publish -c Release [-r <RID>] -p:PublishSingleFile=true
Distribuzione AOT nativa	dotnet publish -c Release [-r <RID>] -p:PublishAot=true
Distribuzione ReadyToRun	dotnet publish -c Release [-r <RID>] -p:PublishReadyToRun=true
Distribuzione del contenitore	dotnet publish -c Release [-r <RID>] -t:PublishContainer

Distribuzione dipendente dal framework

La distribuzione dipendente dal framework è la modalità predefinita quando si pubblica dall'interfaccia della riga di comando o da Visual Studio. In questa modalità viene creato un eseguibile specifico della piattaforma che può essere usato per avviare l'app. L'eseguibile specifico della piattaforma è denominato qualcosa di simile a myapp.exe in Windows o solo myapp in altre piattaforme.

L'app è configurata per specificare una versione specifica di .NET. Il runtime .NET di destinazione deve trovarsi nell'ambiente in cui viene eseguita l'app. Ad esempio, se l'app è destinata a .NET 9, qualsiasi ambiente in cui viene eseguita l'app deve avere installato il runtime .NET 9.

La pubblicazione di una distribuzione dipendente dal framework crea un'app che esegue automaticamente il roll forward alla patch di sicurezza .NET più recente disponibile nell'ambiente che esegue l'app. Per altre informazioni sull'associazione di versioni in fase di compilazione, vedere Selezionare la versione di .NET da usare.

Vantaggi

• Distribuzione di piccole dimensioni: vengono distribuite solo l'app e le relative dipendenze. L'ambiente in cui viene eseguita l'app deve avere già installato il runtime .NET.
• Multipiattaforma: l'app e qualsiasi . La libreria basata su NET viene eseguita in altri sistemi operativi.
• Usa il runtime con patch più recente: l'app usa il runtime più recente installato nell'ambiente.

Difetto

• Richiede la pre-installazione del runtime: l'app può essere eseguita solo se la versione di .NET è già installata nell'ambiente.
• .NET potrebbe cambiare: l'ambiente in cui viene eseguita l'app potrebbe usare un runtime .NET più recente, che potrebbe modificare il comportamento dell'app.

Avviare app dipendenti dal framework

Esistono due modi per eseguire app dipendenti dal framework: tramite l'eseguibile specifico della piattaforma ("apphost") e tramite dotnet myapp.dll. È possibile eseguire direttamente l'eseguibile apphost anziché chiamare dotnet myapp.dll, che è comunque un modo accettabile per eseguire l'app. Quando possibile, è consigliabile usare apphost. L'uso di apphost offre numerosi vantaggi:

• I file eseguibili vengono visualizzati come file eseguibili della piattaforma nativa standard.
• I nomi eseguibili vengono mantenuti nei nomi dei processi, ovvero le app possono essere facilmente riconosciute in base ai nomi.
• Poiché apphost è un file binario nativo, è possibile allegare asset nativi come manifesti.
• Le mitigazioni di sicurezza di basso livello disponibili su Apphost sono applicate per impostazione predefinita, rendendolo più sicuro. Ad esempio, lo stack shadow CET (Control-Flow Enforcement Technology) è abilitato per impostazione predefinita a partire da .NET 9. Le mitigazioni applicate a dotnet sono il denominatore comune più basso di tutti i runtime supportati.

Pubblicare

dotnet publish -c Release [-r <RID>]

• -c Release

  Questa opzione imposta la configurazione di compilazione su Release, ottimizzata per la distribuzione di produzione.

• -r <RID>

  Questa opzione usa un identificatore di runtime (RID) per specificare la piattaforma di destinazione e garantisce che le dipendenze native siano incluse (se necessario). Per un elenco degli identificatori di runtime, vedere Catalogo dell'identificatore di runtime (RID).

Oppure in modo esplicito:

dotnet publish -c Release [-r <RID>] --self-contained false

• --self-contained false

  Questa opzione indica in modo esplicito a .NET SDK di creare una distribuzione dipendente dal framework.

1. Fare clic con il pulsante destro del mouse sul progetto in Esplora soluzioni e scegliere Pubblica.
2. Se si tratta della prima pubblicazione, selezionare Cartella come destinazione di pubblicazione e selezionare Avanti.
3. Scegliere un percorso della cartella o accettare l'impostazione predefinita, quindi selezionare Fine.
4. Nel profilo di pubblicazione selezionare Mostra tutte le impostazioni.
5. Impostare Modalità di distribuzionesu Dipendente dal framework (impostazione predefinita).
6. Impostare Runtime di destinazione sulla piattaforma desiderata, ad esempio win-x64 per Windows a 64 bit.
7. Selezionare Salva e quindi Pubblica.

Configurare il comportamento di ricerca di installazione di .NET

Per impostazione predefinita, apphost individua e usa un runtime .NET installato a livello globale, con percorsi di installazione variabili per piattaforma. Per altre informazioni sull'individuazione del runtime e sui percorsi di installazione, vedere Risolvere gli errori di avvio delle app.

Il percorso di runtime .NET può anche essere personalizzato in base all'esecuzione. La DOTNET_ROOT variabile di ambiente può essere usata per puntare alla posizione personalizzata. Per altre informazioni su tutte le DOTNET_ROOT opzioni di configurazione, vedere Variabili di ambiente .NET.

In generale, la procedura consigliata per l'uso DOTNET_ROOT consiste nel:

1. Cancellare DOTNET_ROOT prima le variabili di ambiente, ovvero tutte le variabili di ambiente che iniziano con il testo DOTNET_ROOT.
2. Imposta DOTNET_ROOT, e solo DOTNET_ROOT, sul percorso di destinazione.
3. Eseguire l'apphost di destinazione.

In .NET 9 e versioni successive è possibile configurare i percorsi di ricerca di installazione .NET del file eseguibile pubblicato tramite le AppHostDotNetSearch proprietà e AppHostRelativeDotNet .

AppHostDotNetSearch consente di specificare uno o più percorsi in cui l'eseguibile cercherà un'installazione .NET:

• AppLocal: cartella dell'eseguibile dell'app
• AppRelative: percorso relativo all'eseguibile dell'app
• EnvironmentVariable: valore delle variabili di DOTNET_ROOT[_<arch>] ambiente
• Global: percorsi di installazione globali registrati e predefiniti

AppHostRelativeDotNet specifica il percorso relativo all'eseguibile che verrà cercato quando AppHostDotNetSearch contiene AppRelative.

Per altre informazioni, vedere AppHostDotNetSearchOpzioni del percorso di installazione , AppHostRelativeDotNete in apphost.

Distribuzione di DLL multipiattaforma

In alternativa, è possibile pubblicare l'app come DLL multipiattaforma senza un eseguibile specifico della piattaforma. In questa modalità viene creato un myapp.dll file nella cartella di output di pubblicazione. Per eseguire l'app, passare alla cartella di output e usare il dotnet myapp.dll comando .

Per pubblicare come DLL multipiattaforma:

dotnet publish -c Release -p:UseAppHost=false

• -c Release

  Questa opzione imposta la configurazione di compilazione su Release, ottimizzata per la distribuzione di produzione.

• -p:UseAppHost=false

  Questa proprietà disabilita la creazione di un eseguibile specifico della piattaforma, producendo solo la DLL portabile.

1. Fare clic con il pulsante destro del mouse sul progetto in Esplora soluzioni e scegliere Pubblica.
2. Se si tratta della prima pubblicazione, selezionare Cartella come destinazione di pubblicazione e selezionare Avanti.
3. Scegliere un percorso della cartella o accettare l'impostazione predefinita, quindi selezionare Fine.
4. Nel profilo di pubblicazione selezionare Mostra tutte le impostazioni.
5. Impostare Modalità di distribuzionesu Dipendente dal framework.
6. Deselezionare Produce singolo file.
7. Impostare Runtime di destinazione su Portabile (o lasciare vuoto).
8. Selezionare Salva e quindi Pubblica.

Distribuzione autonoma

Quando si pubblica una distribuzione autonoma , il processo di pubblicazione crea un eseguibile specifico della piattaforma. La pubblicazione di un gruppo di sicurezza include tutti i file .NET necessari per eseguire l'app, ma non include le dipendenze native di .NET. Queste dipendenze devono essere presenti nell'ambiente prima dell'esecuzione dell'app.

La pubblicazione di una distribuzione guidata crea un'app che non esegue il roll forward alla patch di sicurezza .NET più recente disponibile. Per altre informazioni sull'associazione di versioni in fase di compilazione, vedere Selezionare la versione di .NET da usare.

Vantaggi

• Controllare la versione di .NET: controllare la versione di .NET distribuita con l'app.
• Destinazione specifica della piattaforma: poiché l'app deve essere pubblicata per ogni piattaforma, è chiaro dove viene eseguita l'app.

Difetto

• Distribuzioni di dimensioni maggiori: poiché l'app include il runtime .NET e tutte le dipendenze, le dimensioni del download e lo spazio su disco rigido necessari sono maggiori di una distribuzione dipendente dal framework.
• Più difficile aggiornare la versione di .NET: il runtime .NET può essere aggiornato solo rilasciando una nuova versione dell'app.

Consiglio

È possibile ridurre le dimensioni totali delle app autonome compatibili pubblicando tagliate o abilitando la modalità invariante di globalizzazione. Per altre informazioni sulla modalità invariante di globalizzazione, vedere Modalità invariante di globalizzazione .NET.

Pubblicare

dotnet publish -c Release -r <RID> --self-contained true

• -c Release

  Questa opzione imposta la configurazione di compilazione su Release, ottimizzata per la distribuzione di produzione.

• -r <RID>

  Questa opzione usa un identificatore di runtime (RID) per specificare la piattaforma di destinazione e garantisce che le dipendenze native siano incluse (se necessario). Per un elenco degli identificatori di runtime, vedere Catalogo dell'identificatore di runtime (RID).

• --self-contained true

  Questa opzione indica a .NET SDK di creare un eseguibile come distribuzione autonoma (SCD).

1. Fare clic con il pulsante destro del mouse sul progetto in Esplora soluzioni e scegliere Pubblica.
2. Se si tratta della prima pubblicazione, selezionare Cartella come destinazione di pubblicazione e selezionare Avanti.
3. Scegliere un percorso della cartella o accettare l'impostazione predefinita, quindi selezionare Fine.
4. Nel profilo di pubblicazione selezionare Mostra tutte le impostazioni.
5. Impostare Modalità di distribuzione su Indipendente.
6. Impostare Runtime di destinazione sulla piattaforma desiderata, ad esempio win-x64 per Windows a 64 bit.
7. Selezionare Salva e quindi Pubblica.

Distribuzione a file singolo

Quando si pubblica l'app come distribuzione a file singolo, tutti i file dipendenti dall'applicazione vengono raggruppati in un singolo file binario. Questo modello di distribuzione è disponibile sia per le applicazioni dipendenti dal framework che per le applicazioni autonome, offrendo un'opzione interessante per distribuire e distribuire l'applicazione come singolo file.

Le app a file singolo sono sempre specifiche del sistema operativo e dell'architettura. È necessario pubblicare per ogni configurazione, ad esempio Linux x64, Linux Arm64, Windows x64 e così via.

Vantaggi

• Distribuzione semplificata: distribuire e distribuire l'applicazione come singolo file eseguibile.
• Riduzione del disordine dei file: tutte le dipendenze vengono raggruppate, eliminando la necessità di gestire più file.
• Distribuzione semplice: copiare un singolo file per distribuire l'applicazione.

Difetto

• Dimensioni di file maggiori: il singolo file include tutte le dipendenze, rendendolo più grande di singoli file.
• Avvio più lento: i file devono essere estratti in fase di esecuzione, che possono influire sulle prestazioni di avvio.
• Specifico della piattaforma: deve pubblicare file separati per ogni piattaforma di destinazione.

La distribuzione a file singolo può essere combinata con altre ottimizzazioni, ad esempio trimming e ReadyToRun compilazione per un'ulteriore ottimizzazione.

Per altre informazioni sulla distribuzione a file singolo, vedere Distribuzione a file singolo.

Pubblicare

dotnet publish -c Release -r <RID> -p:PublishSingleFile=true

• -c Release

  Questa opzione imposta la configurazione di compilazione su Release, ottimizzata per la distribuzione di produzione.

• -r <RID>

  Questa opzione usa un identificatore di runtime (RID) per specificare la piattaforma di destinazione e garantisce che le dipendenze native siano incluse (se necessario). Per un elenco degli identificatori di runtime, vedere Catalogo dell'identificatore di runtime (RID).

• -p:PublishSingleFile=true

  Questa proprietà aggrega tutti i file dipendenti dall'applicazione in un singolo file binario.

1. Fare clic con il pulsante destro del mouse sul progetto in Esplora soluzioni e scegliere Pubblica.
2. Se si tratta della prima pubblicazione, selezionare Cartella come destinazione di pubblicazione e selezionare Avanti.
3. Scegliere un percorso della cartella o accettare l'impostazione predefinita, quindi selezionare Fine.
4. Nel profilo di pubblicazione selezionare Mostra tutte le impostazioni.
5. Impostare modalità di distribuzione su indipendente o dipendente dal framework.
6. Impostare Runtime di destinazione sulla piattaforma desiderata, ad esempio win-x64 per Windows a 64 bit.
7. Selezionare Produce singolo file.
8. Selezionare Salva e quindi Pubblica.

Distribuzione AOT nativa

La distribuzione AOT nativa compila l'app direttamente nel codice nativo, eliminando la necessità di un runtime. Questa opzione di pubblicazione usa la modalità di distribuzione autonoma , perché il codice nativo compilato deve includere tutti gli elementi necessari per eseguire l'applicazione. Ciò comporta tempi di avvio più rapidi e riduzione dell'utilizzo della memoria, ma presenta alcune limitazioni sulle funzionalità supportate.

Vantaggi

• Avvio rapido: nessuna compilazione JIT necessaria in fase di esecuzione, con conseguente avvio più rapido dell'applicazione.
• Riduzione dell'utilizzo della memoria: footprint di memoria inferiore rispetto alle applicazioni .NET tradizionali.
• Nessuna dipendenza di runtime: l'applicazione viene eseguita senza richiedere l'installazione del runtime .NET.
• Dimensioni di distribuzione inferiori: spesso inferiori alla distribuzione autonoma con il runtime completo.

Difetto

• Supporto del framework limitato: non tutte le funzionalità e le librerie .NET sono compatibili con Native AOT.
• Tempi di compilazione più lunghi: la compilazione nel codice nativo richiede più tempo rispetto alle normali compilazioni.
• Specifico della piattaforma: deve essere compilato separatamente per ogni piattaforma e architettura di destinazione.
• Limitazioni di debug: esperienza di debug più complessa rispetto alle normali applicazioni .NET.

Per altre informazioni sulla distribuzione AOT nativa, vedere Distribuzione AOT nativa.

Pubblicare

dotnet publish -c Release -r <RID> -p:PublishAot=true

• -c Release

  Questa opzione imposta la configurazione di compilazione su Release, ottimizzata per la distribuzione di produzione.

• -r <RID>

  Questa opzione usa un identificatore di runtime (RID) per specificare la piattaforma di destinazione e garantisce che le dipendenze native siano incluse (se necessario). Per un elenco degli identificatori di runtime, vedere Catalogo dell'identificatore di runtime (RID).

• -p:PublishAot=true

  Questa proprietà abilita la compilazione AOT nativa, che compila l'app direttamente nel codice nativo.

La pubblicazione AOT nativa deve essere configurata nel file di progetto. Non è possibile abilitarlo tramite l'interfaccia utente di pubblicazione di Visual Studio.

1. In Esplora soluzioni fare clic con il pulsante destro del mouse sul progetto e scegliere Modifica file di progetto.

2. Aggiungere la proprietà seguente a un oggetto <PropertyGroup>:

   <PublishAot>true</PublishAot>
   

3. Salvare il file di progetto.

4. Fare clic con il pulsante destro del mouse sul progetto in Esplora soluzioni e scegliere Pubblica.

5. Se si tratta della prima pubblicazione, selezionare Cartella come destinazione di pubblicazione e selezionare Avanti.

6. Scegliere un percorso della cartella o accettare l'impostazione predefinita, quindi selezionare Fine.

7. Nel profilo di pubblicazione selezionare Mostra tutte le impostazioni.

8. Impostare Modalità di distribuzione su Indipendente.

9. Impostare Runtime di destinazione sulla piattaforma desiderata, ad esempio win-x64 per Windows a 64 bit.

10. Selezionare Salva e quindi Pubblica.

Per altre informazioni sulla distribuzione AOT nativa, vedere Distribuzione AOT nativa.

Distribuzione ReadyToRun

Quando si pubblica l'app con la compilazione ReadyToRun, gli assembly dell'applicazione vengono compilati come formato ReadyToRun (R2R). R2R è una forma di compilazione AOT (Ahead-of-Time) che migliora le prestazioni di avvio riducendo la quantità di lavoro che il compilatore JIT (Just-In-Time) deve eseguire durante il caricamento dell'applicazione. Questa opzione di pubblicazione può essere usata con modalità di distribuzione dipendenti dal framework e autonome .

I file binari ReadyToRun contengono sia il codice del linguaggio intermedio (IL) che la versione nativa dello stesso codice. Anche se i file binari R2R sono più grandi di quelli normali, offrono prestazioni di avvio migliori.

Vantaggi

• Tempo di avvio migliorato: l'app impiega meno tempo durante l'esecuzione del compilatore JIT durante l'avvio.
• Prestazioni migliori per il primo utilizzo: riduzione della latenza per la prima esecuzione dei percorsi di codice.
• Compatibile con il codice esistente: funziona con la maggior parte delle librerie e dei framework .NET senza modifiche.
• Distribuzione flessibile: può essere combinata sia con la distribuzione dipendente dal framework che con le modalità di distribuzione autonoma .

Difetto

• Dimensioni maggiori: l'app è più grande sul disco, a causa dell'inclusione sia del codice IL che del codice nativo.
• Tempi di compilazione più lunghi: la compilazione richiede più tempo rispetto alla pubblicazione standard.
• Ottimizzazioni specifiche della piattaforma: i migliori miglioramenti delle prestazioni richiedono la destinazione di piattaforme specifiche.

Pubblicare

dotnet publish -c Release -r <RID> -p:PublishReadyToRun=true

• -c Release

  Questa opzione imposta la configurazione di compilazione su Release, ottimizzata per la distribuzione di produzione.

• -r <RID>

  Questa opzione usa un identificatore di runtime (RID) per specificare la piattaforma di destinazione e garantisce che le dipendenze native siano incluse (se necessario). Per un elenco degli identificatori di runtime, vedere Catalogo dell'identificatore di runtime (RID).

• -p:PublishReadyToRun=true

  Questa proprietà abilita la compilazione ReadyToRun, che migliora le prestazioni di avvio precompilazione degli assembly.

1. Fare clic con il pulsante destro del mouse sul progetto in Esplora soluzioni e scegliere Pubblica.
2. Se si tratta della prima pubblicazione, selezionare Cartella come destinazione di pubblicazione e selezionare Avanti.
3. Scegliere un percorso della cartella o accettare l'impostazione predefinita, quindi selezionare Fine.
4. Nel profilo di pubblicazione selezionare Mostra tutte le impostazioni.
5. Impostare modalità di distribuzione su indipendente o dipendente dal framework.
6. Impostare Runtime di destinazione sulla piattaforma desiderata, ad esempio win-x64 per Windows a 64 bit.
7. Selezionare Abilita compilazione ReadyToRun.
8. Selezionare Salva e quindi Pubblica.

Per altre informazioni sulla distribuzione ReadyToRun, vedere Compilazione ReadyToRun.

Distribuzione del contenitore

Quando si pubblica l'app come contenitore, .NET SDK crea un pacchetto dell'applicazione e delle relative dipendenze in un'immagine del contenitore senza richiedere un Dockerfile separato. Questa modalità di distribuzione crea un'immagine del contenitore completa che può essere eseguita in qualsiasi runtime del contenitore, ad esempio Docker o Podman. La distribuzione dei contenitori semplifica il processo di containerizzazione eliminando la necessità di scrivere e gestire i Dockerfile fornendo immagini di base ottimizzate.

A partire da .NET SDK 8.0.200, il supporto dei contenitori è incluso per impostazione predefinita e non richiede pacchetti NuGet aggiuntivi. Per le applicazioni console, potrebbe essere necessario abilitare il supporto dei contenitori in modo esplicito impostando la EnableSdkContainerSupport proprietà su true.

Consiglio

Per altre informazioni sulle impostazioni del progetto correlate ai contenitori, vedere Containerize a .NET app reference (Informazioni di riferimento su containerizzare un'app .NET).

Vantaggi

• Containerizzazione semplificata: non è necessario scrivere o gestire i Dockerfile per scenari di base.
• Immagini di base ottimizzate: usa immagini di base ottimizzate fornite da Microsoft con gli aggiornamenti della sicurezza più recenti.
• Ambiente coerente: garantisce un ambiente di runtime coerente tra sviluppo, test e produzione.
• Distribuzione semplice: le immagini del contenitore possono essere facilmente condivise e distribuite in ambienti diversi.
• Isolamento della piattaforma: le applicazioni vengono eseguite in contenitori isolati, riducendo i conflitti tra le applicazioni.

Difetto

• Dipendenza del runtime del contenitore: l'ambiente di destinazione deve avere un runtime del contenitore installato.
• Dimensioni immagine: le immagini del contenitore sono in genere più grandi di altri metodi di distribuzione.
• Curva di apprendimento: richiede la comprensione dei concetti e degli strumenti dei contenitori.
• Personalizzazione limitata: minore flessibilità rispetto ai Dockerfile personalizzati per scenari complessi.

Pubblicare

dotnet publish -c Release [-r <RID>] /t:PublishContainer

• -c Release

  Questa opzione imposta la configurazione di compilazione su Release, ottimizzata per la distribuzione di produzione.

• -r <RID>

  Questa opzione usa un identificatore di runtime (RID) per specificare la piattaforma di destinazione e garantisce che le dipendenze native siano incluse (se necessario). Per un elenco degli identificatori di runtime, vedere Catalogo dell'identificatore di runtime (RID).

• -t:PublishContainer

  Questa destinazione pubblica l'applicazione come immagine del contenitore.

È anche possibile usare l'approccio del profilo di pubblicazione:

dotnet publish -c Release [-r <RID>] -p:PublishProfile=DefaultContainer

• -p:PublishProfile=DefaultContainer

  Questo profilo attiva il processo di pubblicazione del contenitore.

1. Fare clic con il pulsante destro del mouse sul progetto in Esplora soluzioni e scegliere Pubblica.
2. Selezionare Registro Contenitori come destinazione di pubblicazione e selezionare Avanti.
3. Scegliere il registro contenitori di destinazione( ad esempio Registro Azure Container, Hub Docker o Registro generico) e selezionare Avanti.
4. Configurare i dettagli e l'autenticazione della connessione del Registro di sistema.
5. Nel profilo di pubblicazione selezionare Mostra tutte le impostazioni.
6. Impostare modalità di distribuzione su indipendente o dipendente dal framework in base alle esigenze.
7. Impostare Runtime di destinazione sulla piattaforma desiderata, ad esempio linux-x64 per contenitori Linux.
8. Configurare impostazioni specifiche del contenitore, ad esempio nome e tag dell'immagine.
9. Selezionare Salva e quindi Pubblica.

Per altre informazioni sulla distribuzione dei contenitori, vedere Panoramica della creazione di contenitori .NET SDK.

Vedere anche

• Catalogo dell'identificatore di runtime .NET (RID)
• Selezionare la versione di .NET da usare
• Pubblicazione per macOS