Panoramica della pubblicazione di applicazioni .NET
Le applicazioni create con .NET possono essere pubblicate in due modalità diverse e la modalità influisce sul modo in cui un utente esegue l'app.
La pubblicazione dell'app come indipendente produce un'applicazione che include il runtime e le librerie .NET e l'applicazione e le relative dipendenze. Gli utenti dell'applicazione possono eseguirla in un computer in cui non è installato il runtime .NET.
La pubblicazione dell'app come dipendente dal framework produce un'applicazione che include solo l'applicazione stessa e le relative dipendenze. Gli utenti dell'applicazione devono installare separatamente il runtime .NET.
Entrambe le modalità di pubblicazione producono un eseguibile specifico della piattaforma per impostazione predefinita. Le applicazioni dipendenti dal framework possono essere create senza un eseguibile e queste applicazioni sono multipiattaforma.
Quando viene generato un eseguibile, è possibile specificare la piattaforma di destinazione con un identificatore di runtime (RID). Per altre informazioni sui RID, vedere Catalogo RID .NET.
La tabella seguente descrive i comandi usati per pubblicare un'app come dipendente dal framework o indipendente:
| Type | Comando |
|---|---|
| eseguibile dipendente dal framework per la piattaforma corrente. | dotnet publish |
| eseguibile dipendente dal framework per una piattaforma specifica. | dotnet publish -r <RID> |
| binario dipendente dal framework. | dotnet publish |
| eseguibile autonomo. | dotnet publish -r <RID> --self-contained |
Per altre informazioni, vedere comando .NET dotnet publish.
Produrre un eseguibile
I file eseguibili non sono multipiattaforma, sono specifici di un sistema operativo e di un'architettura della CPU. Quando si pubblica l'app e si crea un eseguibile, è possibile pubblicare l'app come indipendente o come dipendente dal framework. La pubblicazione di un'app come indipendente include il runtime .NET con l'app e gli utenti dell'app non devono preoccuparsi di installare .NET prima di eseguire l'app. La pubblicazione di un'app come dipendente dal framework non include il runtime .NET; sono incluse solo le dipendenze dell'app e di terze parti.
I comandi seguenti producono un eseguibile:
| Type | Comando |
|---|---|
| eseguibile dipendente dal framework per la piattaforma corrente. | dotnet publish |
| eseguibile dipendente dal framework per una piattaforma specifica. | dotnet publish -r <RID> |
| eseguibile autonomo. | dotnet publish -r <RID> --self-contained |
Produrre un file binario multipiattaforma
I file binari multipiattaforma vengono creati quando si pubblica l'app come dipendente dal framework, sotto forma di file dll. Il file dll è denominato dopo il progetto. Ad esempio, se si dispone di un'app denominata word_reader, viene creato un file denominato word_reader.dll. Le app pubblicate in questo modo vengono eseguite con il comando dotnet <filename.dll> e possono essere eseguite in qualsiasi piattaforma.
I file binari multipiattaforma possono essere eseguiti in qualsiasi sistema operativo, purché il runtime .NET di destinazione sia già installato. Se il runtime .NET di destinazione non è installato, l'app può essere eseguita usando un runtime più recente se l'app è configurata per il rollforward. Per altre informazioni, vedere roll forward delle app dipendenti dal framework.
Il comando seguente genera un file binario multipiattaforma:
| Type | Comando |
|---|---|
| binario multipiattaforma dipendente dal framework. | dotnet publish |
Pubblicare dipendenti dal framework
Le app pubblicate come dipendenti dal framework sono multipiattaforma e non includono il runtime .NET. L'utente dell'app è necessario per installare il runtime .NET.
La pubblicazione di un'app come dipendente dal framework produce un file binario multipiattaforma come file dll e un eseguibile specifico della piattaforma destinato alla piattaforma corrente. Il dll è multipiattaforma, mentre l'eseguibile non lo è. Ad esempio, se si pubblica un'app denominata word_reader e windows di destinazione, viene creato un eseguibile word_reader.exe insieme a word_reader.dll. Quando la destinazione è Linux o macOS, viene creato un eseguibile word_reader insieme a word_reader.dll. Se l'app usa un pacchetto NuGet con implementazioni specifiche della piattaforma, le dipendenze per tutte le piattaforme vengono copiate nella cartella publish\runtimes\{platform}.
Il file binario multipiattaforma dell'app può essere eseguito con il comando dotnet <filename.dll> e può essere eseguito su qualsiasi piattaforma.
Dipendente della piattaforma e dipendente dal framework
È possibile pubblicare un'app dipendente dal framework specifica della piattaforma passando i parametri -r <RID> al comando dotnet publish. La pubblicazione in questo modo equivale alla pubblicazione dipendente dal framework, ad eccezione del fatto che le dipendenze specifiche della piattaforma vengono gestite in modo diverso. Se l'app usa un pacchetto NuGet con implementazioni specifiche della piattaforma, vengono copiate solo le dipendenze della piattaforma di destinazione. Queste dipendenze vengono copiate direttamente nella cartella di pubblicazione.
Anche se tecnicamente il file binario prodotto è multipiattaforma, se si sceglie come target una piattaforma specifica, l'app non è garantita per l'esecuzione multipiattaforma. È possibile eseguire dotnet <filename.dll>, ma l'app potrebbe arrestarsi in modo anomalo quando tenta di accedere a dipendenze specifiche della piattaforma mancanti.
Per altre informazioni sui RID, vedere Catalogo RID .NET.
Vantaggi
Distribuzione di piccole dimensioni
Vengono distribuite solo l'app e le relative dipendenze. Il runtime e le librerie .NET vengono installati dall'utente e tutte le app condividono il runtime.Multipiattaforma
L'app e qualsiasi la libreria basata su .NET viene eseguita in altri sistemi operativi. Non è necessario definire una piattaforma di destinazione per l'app. Per informazioni sul formato di file .NET, vedere Formato file assembly .NET.Usa il runtime con patch più recente
L'app usa il runtime più recente (all'interno della famiglia principale secondaria di destinazione di .NET) installato nel sistema di destinazione. Ciò significa che l'app usa automaticamente la versione con patch più recente del runtime .NET. Questo comportamento predefinito può essere sottoposto a override. Per altre informazioni, vedere roll forward delle app dipendenti dal framework.
Svantaggi
Richiede l'installazione preliminare del runtime
L'app può essere eseguita solo se la versione di .NET di destinazione dell'app è già installata nel sistema host. È possibile configurare il comportamento di roll forward per l'app per richiedere una versione specifica di .NET o consentire una versione più recente di .NET. Per altre informazioni, vedere roll forward delle app dipendenti dal framework..NET può cambiare
È possibile aggiornare il runtime e le librerie .NET nel computer in cui viene eseguita l'app. In rari casi, questo può modificare il comportamento dell'app se si usano le librerie .NET, che la maggior parte delle app esegue. È possibile configurare il modo in cui l'app usa le versioni più recenti di .NET. Per altre informazioni, vedere roll forward delle app dipendenti dal framework.
Esempi
Pubblicare un'app come multipiattaforma e dipendente dal framework. Un eseguibile destinato alla piattaforma corrente viene creato insieme al file dll. Tutte le dipendenze specifiche della piattaforma vengono pubblicate con l'app.
dotnet publish
Pubblicare un'app come dipendente dalla piattaforma e dipendente dal framework. Viene creato un eseguibile Linux a 64 bit insieme al file dll. Solo le dipendenze della piattaforma di destinazione vengono pubblicate con l'app.
dotnet publish -r linux-x64
Pubblicare indipendentemente
La pubblicazione dell'app come indipendente produce un eseguibile specifico della piattaforma. La cartella di pubblicazione dell'output contiene tutti i componenti dell'app, incluse le librerie .NET e il runtime di destinazione. L'app è isolata da altre app .NET e non usa un runtime condiviso installato in locale. L'utente dell'app non è necessario per scaricare e installare .NET.
È possibile pubblicare un'app autonoma passando il parametro --self-contained al comando dotnet publish. Il file binario eseguibile viene generato per la piattaforma di destinazione specificata. Ad esempio, se si dispone di un'app denominata word_reader e si pubblica un eseguibile autonomo per Windows, viene creato un file word_reader.exe. La pubblicazione per Linux o macOS viene creato un file word_reader. La piattaforma e l'architettura di destinazione sono specificate con il parametro -r <RID> per il comando dotnet publish. Per altre informazioni sui RID, vedere Catalogo RID .NET.
Se l'app ha dipendenze specifiche della piattaforma, ad esempio un pacchetto NuGet contenente dipendenze specifiche della piattaforma, queste vengono copiate nella cartella di pubblicazione insieme all'app.
Vantaggi
Controllare la versione di .NET
È possibile controllare la versione di .NET distribuita con l'app.Targeting specifico della piattaforma
Poiché si deve pubblicare l'app per ogni piattaforma, si sa dove verrà eseguita l'app. Se .NET introduce una nuova piattaforma, gli utenti non possono eseguire l'app su tale piattaforma fino a quando non si rilascia una versione destinata a tale piattaforma. È possibile testare l'app per verificare la compatibilità prima che gli utenti eseguano l'app nella nuova piattaforma.
Svantaggi
Distribuzioni più grandi
Poiché l'app include il runtime .NET e tutte le dipendenze dell'app, le dimensioni del download e lo spazio su disco rigido necessari sono maggiori di una versione dipendente dal framework.Suggerimento
È possibile ridurre le dimensioni della distribuzione nei sistemi Linux di circa 28 MB usando .NET modalità invariante di globalizzazione. In questo modo l'app deve trattare tutte le culture come le impostazioni cultura inglese non dipendenti da paese/area geografica.
Suggerimento
Il Trimming IL può ridurre ulteriormente le dimensioni della distribuzione.
Più difficile aggiornare la versione di .NET
Il runtime .NET (distribuito con l'app) può essere aggiornato solo rilasciando una nuova versione dell'app.
Esempi
Pubblicare un'app autonoma. Viene creato un eseguibile macOS a 64 bit.
dotnet publish -r osx-x64 --self-contained
Pubblicare un'app autonoma. Viene creato un eseguibile a 64 bit di Windows.
dotnet publish -r win-x64 --self-contained
Pubblicare con immagini ReadyToRun
La pubblicazione con immagini ReadyToRun migliora il tempo di avvio dell'applicazione a costo di aumentare le dimensioni dell'applicazione. Per altre informazioni, vedere ReadyToRun.
Vantaggi
- Tempo di avvio migliorato
L'applicazione impiega meno tempo per l'esecuzione di JIT.
Svantaggi
- Dimensioni maggiori
L'applicazione sarà più grande su disco.
Esempi
Pubblicare un'app autonoma e ReadyToRun. Viene creato un eseguibile macOS a 64 bit.
dotnet publish -c Release -r osx-x64 --self-contained -p:PublishReadyToRun=true
Pubblicare un'app autonoma e ReadyToRun. Viene creato un eseguibile a 64 bit di Windows.
dotnet publish -c Release -r win-x64 --self-contained -p:PublishReadyToRun=true
