Delen via

Upgraden naar een nieuwe .NET-versie

Er worden elk jaar nieuwe .NET-versies uitgebracht. Veel ontwikkelaars starten het upgradeproces zodra de nieuwe versie beschikbaar is, terwijl anderen wachten totdat de versie die ze gebruiken, niet meer wordt ondersteund. Het upgradeproces heeft meerdere aspecten die u moet overwegen.

Veelvoorkomende redenen om een upgrade uit te voeren naar een nieuwe .NET-versie:

  • De momenteel gebruikte .NET-versie wordt niet meer ondersteund
  • De nieuwe versie ondersteunt een nieuw besturingssysteem
  • De nieuwe versie heeft een belangrijke API, prestaties of beveiligingsfunctie

Ontwikkelomgeving upgraden

Als u een upgrade wilt uitvoeren naar een nieuwe .NET-versie, is de .NET SDK het primaire onderdeel dat moet worden geïnstalleerd. Het bevat een bijgewerkte .NET CLI, buildsysteem en runtime-versie.

De .NET-website biedt installatieprogramma's en archieven die u kunt downloaden en gebruiken op elk ondersteund besturingssysteem en elke ondersteunde architectuur.

Sommige besturingssystemen hebben een pakketbeheerder die u ook kunt gebruiken om een nieuwe .NET-versie te installeren, die u misschien liever gebruikt.

Visual Studio installeert automatisch nieuwe .NET SDK-versies. Voor Visual Studio-gebruikers is het voldoende om een upgrade uit te voeren naar een nieuwere Versie van Visual Studio.

Broncode bijwerken

De enige vereiste wijziging voor het bijwerken van een app is het bijwerken van de TargetFramework eigenschap in een projectbestand naar de nieuwere .NET-versie.

Ga als volgt te werk:

  • Open het projectbestand (de *.csproj, *.vbprojof *.fsproj het bestand).
  • Wijzig de <TargetFramework> eigenschapswaarde bijvoorbeeld net6.0net8.0van .
  • Hetzelfde patroon is van toepassing op de <TargetFrameworks> eigenschap als deze wordt gebruikt.

Aanbeveling

De mogelijkheid tot modernisering en upgrading van de GitHub Copilot-app kan deze wijzigingen automatisch aanbrengen.

De volgende stap bestaat uit het bouwen van het project (of de oplossing) met de nieuwe SDK. Als er aanvullende wijzigingen nodig zijn, biedt de SDK waarschuwingen en fouten die u helpen.

Mogelijk moet u uitvoeren dotnet workload restore om workloads te herstellen met de nieuwe SDK-versie.

Meer resources:

Versie vastmaken

Wanneer u ontwikkelhulpprogramma's zoals de .NET SDK, Visual Studio of andere onderdelen bijwerkt, kunnen er nieuwe gedragingen, analysewaarschuwingen of belangrijke wijzigingen optreden die van invloed zijn op uw buildproces. Door een versie vast te maken, kunt u uw ontwikkelomgeving upgraden terwijl u de controle behoudt over wanneer specifieke onderdelen in uw projecten worden bijgewerkt.

Versie vastmaken biedt verschillende voordelen:

  • Voorspelbare builds: zorgt voor consistente buildresultaten op verschillende computers en CI/CD-omgevingen.
  • Geleidelijke ingebruikname: hiermee kunt u nieuwe functies stapsgewijs in plaats van allemaal tegelijk gebruiken.
  • Vermijd onverwachte wijzigingen: voorkomt dat nieuwe analyseregels, SDK-gedrag of pakketversies buildfouten veroorzaken.
  • Teamcoördinatie: hiermee kunnen teams op een gepland tijdstip upgraden in plaats van afzonderlijk wanneer hulpprogramma's worden bijgewerkt.
  • Foutopsporing en probleemoplossing: hiermee kunt u gemakkelijker problemen isoleren wanneer u bepaalt welke versies zijn gewijzigd.

In de volgende secties worden verschillende mechanismen beschreven voor het beheren van versies van verschillende onderdelen in uw .NET-projecten:

Sdk-versie beheren met global.json

U kunt de .NET SDK-versie vastmaken voor een project of oplossing met behulp van een global.json-bestand . Dit bestand geeft aan welke SDK-versie moet worden gebruikt bij het uitvoeren van .NET CLI-opdrachten en is onafhankelijk van de runtimeversie van uw projectdoelen.

Maak een global.json-bestand in de hoofdmap van uw oplossing:

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

Met deze opdracht maakt u het volgende global.json-bestand waarmee de SDK wordt vastgemaakt aan versie 9.0.100 of een nieuwere patch of functieband in de primaire versie van 9.0:

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

Het rollForward beleid bepaalt hoe de SDK-versie wordt geselecteerd wanneer de exacte versie niet beschikbaar is. Deze configuratie zorgt ervoor dat wanneer u Visual Studio bijwerkt of een nieuwe SDK installeert, uw project SDK 9.0.x blijft gebruiken totdat u het global.json-bestand expliciet bijwerkt .

Zie global.json overzicht voor meer informatie.

Het gedrag van de analyser controleren

Codeanalyses kunnen nieuwe waarschuwingen introduceren of het gedrag tussen versies wijzigen. U kunt analyseversies beheren om consistente builds te onderhouden met behulp van de AnalysisLevel eigenschap. Met deze eigenschap kunt u vergrendelen naar een specifieke versie van analyseregels, waardoor er geen nieuwe regels worden geïntroduceerd wanneer u de SDK bijwerken.

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

Wanneer deze optie is ingesteld 9.0, worden alleen de analyseregels die worden geleverd met .NET 9 ingeschakeld, zelfs als u de .NET 10 SDK gebruikt. Hiermee voorkomt u dat nieuwe .NET 10 Analyzer-regels van invloed zijn op uw build totdat u er klaar voor bent om ze aan te pakken.

Zie AnalysisLevel voor meer informatie.

NuGet-pakketversies beheren

Door pakketversies consistent te beheren in projecten, kunt u onverwachte updates voorkomen en betrouwbare builds onderhouden.

Pakketvergrendelingsbestanden

Pakketvergrendelingsbestanden zorgen ervoor dat pakketherstelbewerkingen exact dezelfde pakketversies gebruiken in verschillende omgevingen. Het vergrendelingsbestand (packages.lock.json) registreert de exacte versies van alle pakketten en hun afhankelijkheden.

Vergrendelingsbestanden inschakelen in uw projectbestand:

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

Om ervoor te zorgen dat builds mislukken als het vergrendelingsbestand verouderd is:

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

Nadat u vergrendelingsbestanden hebt ingeschakeld, voert u de opdracht uit dotnet restore om het packages.lock.json-bestand te genereren. Voer dit bestand door naar broncodebeheer.

Centraal pakketbeheer

Met Central Package Management (CPM) kunt u pakketversies op één locatie beheren voor alle projecten in een oplossing. Deze aanpak vereenvoudigt versiebeheer en zorgt voor consistentie tussen projecten.

Maak een Directory.Packages.props-bestand in de hoofdmap van uw oplossing.

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

Referentiepakketten in uw projectbestanden zonder een versie op te geven:

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

Pakketbron koppeling

Met pakketbrontoewijzing kunt u bepalen welke NuGet-feeds worden gebruikt voor specifieke pakketten, waardoor de beveiliging en betrouwbaarheid worden verbeterd.

Brontoewijzing configureren in uw nuget.config-bestand :

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

Deze configuratie garandeert dat alle pakketten die beginnen met Contoso. alleen worden hersteld uit de contoso feed, terwijl andere pakketten komen uit nuget.org.

Zie NuGet-pakketherstel voor meer informatie.

MSBuild-versie beheren

Visual Studio ondersteunt de installatie van meerdere versies naast elkaar. U kunt bijvoorbeeld Visual Studio 2026 en Visual Studio 2022 op dezelfde computer installeren. Elke Visual Studio-versie bevat een bijbehorende .NET SDK. Wanneer u Visual Studio bijwerkt, wordt ook de meegeleverde SDK-versie bijgewerkt. U kunt echter oudere SDK-versies blijven gebruiken door ze afzonderlijk van de .NET-downloadpagina te installeren.

MSBuild-versies komen overeen met Visual Studio-versies. Visual Studio 2022 versie 17.8 bevat bijvoorbeeld MSBuild 17.8. De .NET SDK bevat ook MSBuild. Wanneer u gebruikt dotnet build, gebruikt u de MSBuild-versie die is opgenomen in de SDK die is opgegeven door global.json of de nieuwste geïnstalleerde SDK.

Een specifieke MSBuild-versie gebruiken:

  • Gebruik dotnet build met een vastgepinde SDK-versie in global.json.
  • Start de juiste Visual Studio Developer-opdrachtprompt, waarmee de omgeving voor de MSBuild van die Visual Studio-versie wordt ingesteld.
  • Rechtstreeks MSBuild aanroepen vanuit een specifieke Visual Studio-installatie (bijvoorbeeld "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\MSBuild.exe").

Zie .NET SDK, MSBuild en Visual Studio-versiebeheer voor meer informatie.

Continue integratie bijwerken (CI)

CI-pijplijnen volgen een vergelijkbaar updateproces als projectbestanden en Dockerfiles. Normaal gesproken kunt u CI-pijplijnen bijwerken door alleen versiewaarden te wijzigen.

Hostingomgeving bijwerken

Er zijn veel patronen die worden gebruikt voor het hosten van toepassingen. Als de hostingomgeving de .NET-runtime bevat, moet de nieuwe versie van de .NET-runtime worden geïnstalleerd. In Linux moeten afhankelijkheden worden geïnstalleerd, maar ze veranderen doorgaans niet in .NET-versies.

Voor containers FROM moeten instructies worden gewijzigd om nieuwe versienummers op te nemen.

In het volgende Dockerfile-voorbeeld ziet u hoe u een ASP.NET Core 9.0-installatiekopie ophaalt.

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

In een cloudservice zoals Azure-app Service is een configuratiewijziging nodig.

Zie ook

  • Last updated on