Roll forward del runtime di distribuzione autonoma

Le distribuzioni di applicazioni autonome .NET Core includono sia le librerie che il runtime .NET Core. A partire da .NET Core 2.1 SDK (versione 2.1.300), le distribuzioni di applicazioni autonome pubblicano nel computer il runtime della patch con il numero di versione più alto. Per impostazione predefinita, dotnet publish per una distribuzione autonoma seleziona la versione più recente installata come parte dell'SDK nel computer di pubblicazione. Ciò consente l'esecuzione dell'applicazione distribuita con le correzioni, di sicurezza e di altro tipo, disponibili durante l'esecuzione di publish. Per ottenere una nuova patch, l'applicazione deve essere ripubblicata. Le applicazioni autonome vengono create specificando -r <RID> nel comando dotnet publish o specificando l'identificatore di runtime nel file di progetto (csproj o vbproj) o nella riga di comando.

Panoramica del roll forward della versione della patch

restore, build e publish sono comandi dotnet eseguibili separatamente. La scelta del runtime fa parte dell'operazione di restore, non di publish o di build. Se si chiama publish, viene scelta la versione più recente della patch. Se si chiama publish con l'argomento --no-restore, non è possibile ottenere la versione desiderata della patch, perché in precedenza non può essere stato eseguito un comando restore con i nuovi criteri di pubblicazione dell'applicazione autonoma. In questo caso, viene generato un errore di compilazione con testo simile al seguente:

"The project was restored using Microsoft.NETCore.App version 2.0.0, but with current settings, version 2.0.6 would be used instead. To resolve this issue, make sure the same settings are used for restore and for subsequent operations such as build or publish. Typically this issue can occur if the RuntimeIdentifier property is set during build or publish but not during restore" (Il progetto è stato ripristinato tramite Microsoft.NETCore.App versione 2.0.0, ma con le impostazioni correnti avrebbe dovuto essere usata la versione 2.0.6. Per risolvere il problema, assicurarsi che vengano usate le stesse impostazioni per il comando restore e per operazioni successive, quali build o publish. Questo problema si presenta, in genere, se la proprietà RuntimeIdentifier viene impostata durante l'operazione build o publish ma non durante restore).

Nota

I comandi restore e build possono essere eseguiti in modo implicito all'interno di un altro comando, ad esempio publish. Durante l'esecuzione in modo implicito all'interno di un altro comando, vengono specificati con contesto aggiuntivo, in modo che vengano generati gli artefatti corretti. Quando si esegue publish con un runtime (ad esempio, dotnet publish -r linux-x64), il comando restore implicito ripristina i pacchetti per il runtime linux-x64. Se chiamato in modo esplicito, restore non ripristina i pacchetti di runtime per impostazione predefinita, poiché non dispone di tale contesto.

Come evitare il ripristino durante la pubblicazione

L'esecuzione di restore all'interno dell'operazione publish può essere indesiderata per lo scenario. Per evitare l'esecuzione di restore durante la creazione di applicazioni autonome tramite publish, eseguire le operazioni seguenti:

• Impostare la proprietà RuntimeIdentifiers su un elenco delimitato da punto e virgola di tutti i RID da pubblicare.
• Impostare la proprietà TargetLatestRuntimePatch su true.

Argomento no-restore con le opzioni di dotnet publish

Se con lo stesso file di progetto si vogliono creare sia applicazioni autonome che applicazioni dipendenti dal framework e si vuole usare l'argomento --no-restore con dotnet publish, scegliere una delle alternative seguenti:

1. Preferire il comportamento dipendente dal framework. Se l'applicazione è dipendente dal framework, questo è il comportamento predefinito. Se l'applicazione è autonoma e può usare un runtime locale versione 2.1.0 senza patch, impostare TargetLatestRuntimePatch su false nel file di progetto.

2. Preferire il comportamento autonomo. Se l'applicazione è autonoma, questo è il comportamento predefinito. Se l'applicazione è dipendente dal framework e richiede l'installazione della patch più recente, impostare TargetLatestRuntimePatch su true nel file di progetto.

3. Assumere il controllo esplicito della versione del framework del runtime impostando RuntimeFrameworkVersion sulla versione specifica della patch nel file di progetto.