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
sutrue
.
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:
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
sufalse
nel file di progetto.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
sutrue
nel file di progetto.Assumere il controllo esplicito della versione del framework del runtime impostando
RuntimeFrameworkVersion
sulla versione specifica della patch nel file di progetto.