Condividi tramite

Eseguire l'aggiornamento a una nuova versione di .NET

Le nuove versioni di .NET vengono rilasciate ogni anno. Molti sviluppatori avviano il processo di aggiornamento non appena è disponibile la nuova versione, mentre altri attendono fino a quando la versione in uso non è più supportata. Per il processo di aggiornamento è necessario prendere in considerazione diversi aspetti.

Motivi comuni per eseguire l'aggiornamento a una nuova versione di .NET:

  • La versione di .NET attualmente usata non è più supportata
  • La versione nuova supporta un nuovo sistema operativo
  • La nuova versione include un'API, prestazioni o funzionalità di sicurezza importanti

Aggiornare l'ambiente di sviluppo

Per eseguire l'aggiornamento a una nuova versione di .NET, il componente principale da installare è .NET SDK. Include un'interfaccia della riga di comando di .NET aggiornata, un sistema di compilazione e una versione di runtime.

Il sito Web .NET offre programmi di installazione e archivi che è possibile scaricare e usare in qualsiasi sistema operativo e architettura supportati.

Alcuni sistemi operativi includono uno strumento di gestione pacchetti che è possibile usare anche per installare una nuova versione di .NET e si potrebbe preferire questa opzione.

Visual Studio installa automaticamente nuove versioni di .NET SDK. Per gli utenti di Visual Studio è sufficiente eseguire l'aggiornamento a una versione più recente di Visual Studio.

Aggiornare il codice sorgente

L'unica modifica necessaria per aggiornare un'app consiste nell'aggiornare la proprietà TargetFramework in un file di progetto alla versione più recente di .NET.

Ecco come eseguire questa operazione:

  • Aprire il file di progetto (il file *.csproj, *.vbproj o *.fsproj).
  • Modificare il valore della proprietà <TargetFramework> da net6.0 a net8.0, ad esempio.
  • Lo stesso criterio si applica alla proprietà <TargetFrameworks> se viene usata.

Suggerimento

La funzionalità di modernizzazione dell'app GitHub Copilot - aggiornamento può apportare automaticamente queste modifiche.

Il passaggio successivo consiste nel compilare il progetto (o la soluzione) con il nuovo SDK. Se sono necessarie modifiche aggiuntive, l'SDK visualizzerà avvisi ed errori in merito.

Potrebbe essere necessario eseguire dotnet workload restore per ripristinare i carichi di lavoro con la nuova versione dell'SDK.

Altre risorse:

Bloccare la versione

Quando si aggiornano strumenti di sviluppo come .NET SDK, Visual Studio o altri componenti, è possibile che si verifichino nuovi comportamenti, avvisi dell'analizzatore o modifiche che influiscono sul processo di compilazione. Fissando a una versione, è possibile aggiornare l'ambiente di sviluppo mantenendo il controllo su quando aggiornare componenti specifici nei progetti.

Il pinning delle versioni offre diversi vantaggi:

  • Compilazioni prevedibili: garantisce risultati di compilazione coerenti in computer e ambienti CI/CD diversi.
  • Adozione graduale: consente di adottare nuove funzionalità in modo incrementale anziché contemporaneamente.
  • Evitare modifiche impreviste: impedisce a nuove regole dell'analizzatore, comportamenti dell'SDK o versioni del pacchetto di causare errori di compilazione.
  • Coordinamento del team: consente ai team di eseguire l'aggiornamento insieme in un momento pianificato anziché singolarmente quando gli strumenti vengono aggiornati.
  • Debug e risoluzione dei problemi: semplifica l'isolamento dei problemi quando si controllano le versioni modificate.

Le sezioni seguenti descrivono vari meccanismi per controllare le versioni di diversi componenti nei progetti .NET:

Controllare la versione dell'SDK con global.json

È possibile aggiungere la versione di .NET SDK per un progetto o una soluzione usando un fileglobal.json . Questo file specifica la versione dell'SDK da usare quando si eseguono i comandi dell'interfaccia della riga di comando di .NET ed è indipendente dalla versione di runtime di destinazione del progetto.

Creare un fileglobal.json nella directory radice della soluzione:

dotnet new globaljson --sdk-version 9.0.100 --roll-forward latestFeature

Questo comando crea il file diglobal.json seguente che aggiunge l'SDK alla versione 9.0.100 o a qualsiasi patch o banda di funzionalità successiva all'interno della versione principale 9.0:

{
  "sdk": {
    "version": "9.0.100",
    "rollForward": "latestFeature"
  }
}

I rollForward criteri controllano la modalità di selezione della versione dell'SDK quando la versione esatta non è disponibile. Questa configurazione garantisce che quando si aggiorna Visual Studio o si installa un nuovo SDK, il progetto continua a usare SDK 9.0.x fino a quando non si aggiorna in modo esplicito il file global.json .

Per altre informazioni, vedere panoramica di global.json.

Controllare il comportamento dell'analizzatore

Gli analizzatori del codice possono introdurre nuovi avvisi o modificare il comportamento tra le versioni. È possibile controllare le versioni dell'analizzatore per mantenere compilazioni coerenti usando la AnalysisLevel proprietà . Questa proprietà consente di bloccare una versione specifica delle regole dell'analizzatore, impedendo l'introduzione di nuove regole durante l'aggiornamento dell'SDK.

<PropertyGroup>
  <AnalysisLevel>9.0</AnalysisLevel>
</PropertyGroup>

Se impostato su 9.0, vengono abilitate solo le regole dell'analizzatore fornite con .NET 9, anche se si usa .NET 10 SDK. Ciò impedisce che le nuove regole dell'analizzatore .NET 10 influiscano sulla compilazione fino a quando non si è pronti per risolverle.

Per altre informazioni, vedere AnalysisLevel.

Controllare le versioni dei pacchetti NuGet

Gestendo le versioni dei pacchetti in modo coerente tra progetti, è possibile evitare aggiornamenti imprevisti e gestire compilazioni affidabili.

File di blocco del pacchetto

I file di blocco del pacchetto assicurano che le operazioni di ripristino dei pacchetti usino esattamente le stesse versioni dei pacchetti in ambienti diversi. Il file di blocco (packages.lock.json) registra le versioni esatte di tutti i pacchetti e le relative dipendenze.

Abilitare i file di blocco nel file di progetto:

<PropertyGroup>
  <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
</PropertyGroup>

Per assicurarsi che le compilazioni falliscano se il file di blocco non è aggiornato:

<PropertyGroup>
  <RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
  <RestoreLockedMode>true</RestoreLockedMode>
</PropertyGroup>

Dopo aver abilitato i file di blocco, eseguire dotnet restore per generare il file packages.lock.json . Eseguire il commit del file nel controllo del codice sorgente.

Gestione centrale dei pacchetti

La gestione centrale dei pacchetti (CPM) consente di gestire le versioni dei pacchetti in un'unica posizione per tutti i progetti in una soluzione. Questo approccio semplifica la gestione delle versioni e garantisce la coerenza tra i progetti.

Creare un file Directory.Packages.props nella radice della soluzione:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>

  <ItemGroup>
    <PackageVersion Include="Azure.Identity" Version="1.17.0" />
    <PackageVersion Include="Microsoft.Extensions.AI" Version="9.10.1" />
  </ItemGroup>
</Project>

Nei file di progetto fare riferimento ai pacchetti senza specificare una versione:

<ItemGroup>
  <PackageReference Include="Azure.Identity" />
  <PackageReference Include="Microsoft.Extensions.AI" />
</ItemGroup>

Mapping di origine pacchetto

Il mapping dell'origine dei pacchetti consente di controllare quali feed NuGet vengono usati per pacchetti specifici, migliorando la sicurezza e l'affidabilità.

Configurare il mapping di origine nel file nuget.config :

<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    <add key="contoso" value="https://contoso.com/packages/" />
  </packageSources>

  <packageSourceMapping>
    <packageSource key="nuget.org">
      <package pattern="*" />
    </packageSource>
    <packageSource key="contoso">
      <package pattern="Contoso.*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

Questa configurazione garantisce che tutti i pacchetti che iniziano con Contoso. vengano ripristinati solo dal contoso feed, mentre altri pacchetti provengono da nuget.org.

Per altre informazioni, vedere Ripristino dei pacchetti NuGet.

Controllare la versione di MSBuild

Visual Studio supporta l'installazione side-by-side di più versioni. Ad esempio, è possibile installare Visual Studio 2026 e Visual Studio 2022 nello stesso computer. Ogni versione di Visual Studio include un SDK .NET corrispondente. Quando si aggiorna Visual Studio, viene aggiornata anche la versione dell'SDK inclusa. Tuttavia, è possibile continuare a usare le versioni precedenti dell'SDK installandole separatamente dalla pagina di download di .NET.

Le versioni di MSBuild corrispondono alle versioni di Visual Studio. Ad esempio, Visual Studio 2022 versione 17.8 include MSBuild 17.8. .NET SDK include anche MSBuild. Quando si usa dotnet build, si usa la versione di MSBuild inclusa nell'SDK specificato da global.json o dall'SDK installato più recente.

Per usare una versione specifica di MSBuild:

  • Usare dotnet build con una versione dell'SDK bloccata in global.json.
  • Avviare il Prompt dei Comandi per gli Sviluppatori di Visual Studio appropriato, che configura l'ambiente per MSBuild della versione di Visual Studio.
  • Richiamare direttamente MSBuild da un'installazione specifica di Visual Studio , ad esempio "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\MSBuild.exe".

Per altre informazioni, vedere .NET SDK, MSBuild e Controllo delle versioni di Visual Studio.

Aggiornare l'integrazione continua (CI)

Le pipeline CI seguono un processo di aggiornamento simile a quello dei file di progetto e dei Dockerfile. In genere, è possibile aggiornare pipeline CI modificando solo i valori di versione.

Aggiornare l'ambiente di hosting

Esistono diversi criteri usati per l'hosting di applicazioni. Se l'ambiente di hosting include il runtime .NET, è necessario installare la nuova versione del runtime .NET. In Linux è necessario installare le dipendenze, che tuttavia in genere non cambiano tra le versioni di .NET.

Per i contenitori è necessario modificare le FROM istruzioni per includere nuovi numeri di versione.

L'esempio dockerfile seguente illustra il pull di un'immagine ASP.NET Core 9.0.

FROM mcr.microsoft.com/dotnet/aspnet:9.0

In un servizio cloud come Servizio app di Azure è necessaria una modifica della configurazione.

Vedere anche

  • Last updated on