Partager via

Mise à niveau vers une nouvelle version de .NET

De nouvelles versions de .NET sont mises en production chaque année. De nombreux développeurs démarrent le processus de mise à niveau dès que la nouvelle version est disponible, alors que d’autres attendent jusqu’à la fin de la prise en charge de la version qu’ils utilisent. Le processus de mise à niveau a plusieurs points à prendre en compte.

Raisons courantes d’une mise à niveau vers une nouvelle version de .NET :

  • La version de .NET actuellement utilisée n’est plus prise en charge
  • La nouvelle version prend en charge un nouveau système d’exploitation
  • La nouvelle version dispose d’une fonctionnalité de sécurité, d’un niveau de performance ou d’une API importante

Mise à niveau de l’environnement de développement

Pour effectuer une mise à niveau vers une nouvelle version de .NET, le Kit de développement logiciel (SDK) .NET constitue le principal composant à installer. Il inclut une version de runtime, un système de génération et une interface Azure CLI .NET mis à jour.

Le site web de .NET propose des programmes d’installation et des archives que vous pouvez télécharger et utiliser sur n’importe quel système d’exploitation et n’importe quelle architecture pris en charge.

Certains systèmes d’exploitation disposent également d’un gestionnaire de package que vous préférerez peut-être utiliser pour installer une nouvelle version de .NET.

Visual Studio installe les nouvelles versions du Kit de développement logiciel (SDK) .NET automatiquement. Pour les utilisateurs de Visual Studio, une mise à jour vers une version plus récente de Visual Studio est suffisante.

Mise à niveau de code source

La seule modification requise pour la mise à niveau d’une application consiste à mettre à jour la propriété TargetFramework dans un Fichier projet vers la dernière version de .NET.

Voici comment procéder :

  • Ouvrez le Fichier projet (le fichier *.csproj, *.vbproj ou *.fsproj).
  • Remplacez la valeur de propriété <TargetFramework> à partir de net6.0, par exemple, par net8.0.
  • Le même modèle s’applique pour la propriété <TargetFrameworks> si elle est en cours d’utilisation.

Conseil / Astuce

La modernisation de l’application GitHub Copilot : la fonctionnalité de mise à niveau peut apporter ces modifications automatiquement.

L’étape suivante consiste à générer le projet (ou solution) avec le nouveau Kit de développement logiciel (SDK). Si d’autres modifications sont nécessaires, le Kit de développement logiciel (SDK) vous fournira des avertissements et des erreurs pour vous guider.

Il est possible que vous deviez exécuter dotnet workload restore pour restaurer des charges de travail avec la nouvelle version du Kit de développement logiciel (SDK).

Autres ressources :

Épinglage de version

Lorsque vous mettez à niveau des outils de développement tels que le Kit de développement logiciel (SDK) .NET, Visual Studio ou d’autres composants, vous pouvez rencontrer de nouveaux comportements, des avertissements d'analyse ou des modifications cassantes qui affectent votre processus de génération. En épinglant à une version, vous pouvez mettre à niveau votre environnement de développement tout en conservant le contrôle du moment où les composants spécifiques sont mis à jour dans vos projets.

L'ancrage de version offre plusieurs avantages :

  • Builds prévisibles : garantit des résultats de build cohérents sur différents ordinateurs et environnements CI/CD.
  • Adoption progressive : vous permet d’adopter de nouvelles fonctionnalités de manière incrémentielle plutôt que tout à la fois.
  • Évitez les modifications inattendues : empêche les nouvelles règles d’analyseur, les comportements du KIT de développement logiciel (SDK) ou les versions de package de provoquer des défaillances de build.
  • Coordination d’équipe : permet aux équipes de se mettre à niveau ensemble à un moment planifié plutôt que individuellement lorsque les outils sont mis à jour.
  • Débogage et résolution des problèmes : facilite l’isolation des problèmes lorsque vous contrôlez les versions modifiées.

Les sections suivantes décrivent différents mécanismes pour contrôler les versions de différents composants dans vos projets .NET :

Contrôler la version du Kit de développement logiciel (SDK) avec global.json

Vous pouvez épingler la version du SDK .NET pour un projet ou une solution à l’aide d’un fichier global.json. Ce fichier spécifie la version du KIT de développement logiciel (SDK) à utiliser lors de l’exécution de commandes CLI .NET et est indépendante de la version runtime que votre projet cible.

Créez un fichier global.json dans le répertoire racine de votre solution :

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

Cette commande crée le fichier global.json suivant qui épingle le Kit de développement logiciel (SDK) à la version 9.0.100 ou toute bande de fonctionnalités ou correctifs ultérieurs dans la version principale 9.0 :

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

La rollForward stratégie contrôle la façon dont la version du Kit de développement logiciel (SDK) est sélectionnée lorsque la version exacte n’est pas disponible. Cette configuration garantit que lorsque vous mettez à niveau Visual Studio ou installez un nouveau SDK, votre projet continue d’utiliser sdk 9.0.x jusqu’à ce que vous mettez à jour explicitement le fichier global.json .

Pour plus d’informations, consultez global.json vue d’ensemble.

Comportement de l’analyseur de contrôle

Les analyseurs de code peuvent introduire de nouveaux avertissements ou modifier le comportement entre les versions. Vous pouvez contrôler les versions de l’analyseur pour gérer les builds cohérentes à l’aide de la AnalysisLevel propriété. Cette propriété vous permet de verrouiller une version spécifique des règles d’analyseur, ce qui empêche les nouvelles règles d’être introduites lorsque vous mettez à niveau le Kit de développement logiciel (SDK).

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

Quand la valeur est définie 9.0, seules les règles d’analyseur fournies avec .NET 9 sont activées, même si vous utilisez le KIT SDK .NET 10. Cela empêche les nouvelles règles d’analyseur .NET 10 d’affecter votre build jusqu’à ce que vous soyez prêt à les traiter.

Pour plus d’informations, consultez AnalysisLevel.

Contrôler les versions du package NuGet

En gérant les versions de package de manière cohérente entre les projets, vous pouvez empêcher des mises à jour inattendues et gérer des builds fiables.

Fichiers de verrouillage de paquet

Les fichiers de verrouillage de package garantissent que les opérations de restauration de package utilisent exactement les mêmes versions de package dans différents environnements. Le fichier de verrouillage (packages.lock.json) enregistre les versions exactes de tous les packages et de leurs dépendances.

Activez les fichiers de verrouillage dans votre fichier projet :

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

Pour garantir que les builds échouent si le fichier de verrouillage est obsolète :

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

Après avoir activé les fichiers de verrouillage, exécutez dotnet restore pour générer le fichier packages.lock.json . Validez ce fichier dans le contrôle de code source.

Gestion centralisée des packages

La gestion centralisée des packages (CPM) vous permet de gérer les versions de package à un emplacement unique pour tous les projets d’une solution. Cette approche simplifie la gestion des versions et garantit la cohérence entre les projets.

Créez un fichier Directory.Packages.props dans la racine de votre solution :

<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>

Dans vos fichiers projet, référencez des packages sans spécifier de version :

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

Mappage de source du package

Le mappage de source de package vous permet de contrôler les flux NuGet utilisés pour des packages spécifiques, ce qui améliore la sécurité et la fiabilité.

Configurez le mappage source dans votre fichier 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>

Cette configuration garantit que tous les packages commençant par Contoso. sont restaurés uniquement à partir du contoso flux, tandis que d’autres packages proviennent nuget.org.

Pour plus d’informations, consultez restauration de package NuGet.

Contrôler la version MSBuild

Visual Studio prend en charge l’installation côte à côte de plusieurs versions. Par exemple, vous pouvez installer Visual Studio 2026 et Visual Studio 2022 sur le même ordinateur. Chaque version de Visual Studio inclut un KIT SDK .NET correspondant. Lorsque vous mettez à jour Visual Studio, la version incluse du Kit de développement logiciel (SDK) est également mise à jour. Toutefois, vous pouvez continuer à utiliser des versions antérieures du Kit de développement logiciel (SDK) en les installant séparément de la page de téléchargement .NET.

Les versions de MSBuild correspondent aux versions de Visual Studio. Par exemple, Visual Studio 2022 version 17.8 inclut MSBuild 17.8. Le Kit de développement logiciel (SDK) .NET inclut également MSBuild. Lorsque vous utilisez dotnet build, vous utilisez la version MSBuild incluse dans le Kit de développement logiciel (SDK) spécifié par global.json ou le kit DE développement logiciel (SDK) installé le plus récent.

Pour utiliser une version SPÉCIFIQUE de MSBuild :

  • Utilisez dotnet build avec une version épinglée du Kit de développement logiciel (SDK) dans global.json.
  • Lancez l’invite de commandes du développeur Visual Studio appropriée, qui configure l’environnement de MSBuild pour cette version de Visual Studio.
  • Appelez directement MSBuild à partir d’une installation spécifique de Visual Studio (par exemple). "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\MSBuild.exe"

Pour plus d’informations, consultez le Kit de développement logiciel (SDK) .NET, MSBuild et visual Studio versioning.

Mise à jour de l’intégration continue (CI)

Les pipelines d’intégration suivent un processus de mise à jour similaire aux Fichiers projets et Dockerfiles. Vous pouvez généralement mettre à jour des Pipelines d’intégration continue en modifiant uniquement les valeurs de version.

Mise à jour d’un environnement d’hébergement

Il existe plusieurs modèles utilisés pour des applications d’hébergement. Si l’environnement d’hébergement comprend le runtime .NET, vous devez alors installer la nouvelle version du runtime .NET. Sur Linux, vous devez installer des dépendances. Toutefois, elles ne changent généralement pas entre les versions .NET.

Pour les conteneurs, vous devez modifier les instructions FROM pour inclure les nouveaux numéros de version.

L’exemple Dockerfile suivant illustre l’extraction d’une image ASP.NET Core 9.0.

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

Dans un service cloud comme Azure App Service, une modification de configuration est nécessaire.

Voir aussi

  • Last updated on