Dela via

Uppgradera till en ny .NET-version

Nya .NET-versioner släpps varje år. Många utvecklare startar uppgraderingsprocessen så snart den nya versionen är tillgänglig, medan andra väntar tills den version de använder inte längre stöds. Uppgraderingsprocessen har flera aspekter att tänka på.

Vanliga orsaker till att uppgradera till en ny .NET-version:

  • Den .NET-version som används stöds inte längre
  • Den nya versionen stöder ett nytt operativsystem
  • Den nya versionen har en viktig API-funktion, prestanda eller säkerhetsfunktion

Uppgradera utvecklingsmiljön

Om du vill uppgradera till en ny .NET-version är .NET SDK den primära komponent som ska installeras. Den innehåller en uppdaterad .NET CLI-version, byggsystem och körningsversion.

På .NET-webbplatsen finns installationsprogram och arkiv som du kan ladda ned och använda på alla operativsystem och arkitekturer som stöds.

Vissa operativsystem har en pakethanterare som du också kan använda för att installera en ny .NET-version, vilket du kanske föredrar.

Visual Studio installerar nya .NET SDK-versioner automatiskt. För Visual Studio-användare räcker det att uppgradera till en nyare Visual Studio-version.

Uppgradera källkod

Den enda nödvändiga ändringen för att uppgradera en app är att uppdatera TargetFramework egenskapen i en projektfil till den nyare .NET-versionen.

Så här gör du:

  • Öppna projektfilen ( *.csprojfilen , *.vbprojeller *.fsproj ).
  • Ändra egenskapsvärdet <TargetFramework> från till exempel net6.0 till net8.0.
  • Samma mönster gäller för egenskapen om den <TargetFrameworks> används.

Tips/Råd

GitHub Copilot-appmoderniseringen – uppgraderingsfunktionen kan göra dessa ändringar automatiskt.

Nästa steg är att skapa projektet (eller lösningen) med den nya SDK:n. Om ytterligare ändringar behövs kommer SDK:n att ge varningar och fel som vägleder dig.

Du kan behöva köra dotnet workload restore för att återställa arbetsbelastningar med den nya SDK-versionen.

Fler resurser:

Versionsfastsättning

När du uppgraderar utvecklingsverktyg som .NET SDK, Visual Studio eller andra komponenter kan du stöta på nya beteenden, analysvarningar eller icke-bakåtkompatibla ändringar som påverkar byggprocessen. Genom att fästa på en version kan du uppgradera utvecklingsmiljön samtidigt som du behåller kontrollen över när specifika komponenter uppdateras i dina projekt.

Versionshantering ger flera fördelar:

  • Förutsägbara versioner: Säkerställer konsekventa byggresultat för olika datorer och CI/CD-miljöer.
  • Gradvis införande: Gör att du kan införa nya funktioner stegvis i stället för alla på en gång.
  • Undvik oväntade ändringar: Förhindrar att nya analysregler, SDK-beteenden eller paketversioner orsakar byggfel.
  • Teamsamordning: Gör det möjligt för team att uppgradera tillsammans vid en planerad tidpunkt i stället för individuellt när verktygen uppdateras.
  • Felsökning och felsökning: Gör det enklare att isolera problem när du styr vilka versioner som har ändrats.

I följande avsnitt beskrivs olika mekanismer för att kontrollera versioner av olika komponenter i dina .NET-projekt:

Kontrollera SDK-versionen med global.json

Du kan fästa .NET SDK-versionen för ett projekt eller en lösning med hjälp av en global.json fil. Den här filen anger vilken SDK-version som ska användas när du kör .NET CLI-kommandon och är oberoende av körningsversionen som projektet riktar in sig på.

Skapa en global.json fil i lösningens rotkatalog:

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

Det här kommandot skapar följande global.json fil som fäster SDK:t på version 9.0.100 eller senare korrigerings- eller funktionsband i 9.0-huvudversionen:

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

Principen rollForward styr hur SDK-versionen väljs när den exakta versionen inte är tillgänglig. Den här konfigurationen säkerställer att projektet fortsätter att använda SDK 9.0.x när du uppgraderar Visual Studio eller installerar ett nytt SDK tills du uttryckligen uppdaterar global.json-filen .

För mer information, se global.json översikt.

Styr analysatorns beteende

Kodanalysverktyg kan introducera nya varningar eller ändra beteende mellan versioner. Du kan styra analysatorversioner för att upprätthålla konsekventa versioner genom att använda AnalysisLevel-egenskapen. Med den här egenskapen kan du låsa till en specifik version av analysregler, vilket förhindrar att nya regler introduceras när du uppgraderar SDK:n.

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

När det är inställt 9.0på är endast analysreglerna som levereras med .NET 9 aktiverade, även om du använder .NET 10 SDK. Detta förhindrar att nya .NET 10-analysregler påverkar din version tills du är redo att åtgärda dem.

Mer information finns i AnalysisLevel.

Kontrollera NuGet-paketversioner

Genom att hantera paketversioner konsekvent mellan projekt kan du förhindra oväntade uppdateringar och underhålla tillförlitliga versioner.

Paketlåsfiler

Paketlåsfiler ser till att paketåterställningsåtgärder använder exakt samma paketversioner i olika miljöer. Låsfilen (packages.lock.json) registrerar de exakta versionerna av alla paket och deras beroenden.

Aktivera låsfiler i projektfilen:

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

Så här ser du till att byggen misslyckas om låsfilen är inaktuell:

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

När du har aktiverat låsfiler kör du dotnet restore för att generera packages.lock.json-filen . Checka in den här filen i källkontrollen.

Central pakethantering

Med central pakethantering (CPM) kan du hantera paketversioner på en enda plats för alla projekt i en lösning. Den här metoden förenklar versionshanteringen och säkerställer konsekvens mellan projekt.

Skapa en Directory.Packages.props-fil i lösningsroten :

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

I projektfilerna refererar du till paket utan att ange någon version:

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

Mappning av paketkälla

Med paketkällmappning kan du styra vilka NuGet-feeds som används för specifika paket, vilket förbättrar säkerheten och tillförlitligheten.

Konfigurera källmappning i dinnuget.config-fil :

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

Den här konfigurationen säkerställer att alla paket som börjar med Contoso. endast återställs från feeden contoso , medan andra paket kommer från nuget.org.

Mer information finns i NuGet-paketåterställning.

Kontrollera MSBuild-versionen

Visual Studio stöder sida vid sida-installation av flera versioner. Du kan till exempel installera Visual Studio 2026 och Visual Studio 2022 på samma dator. Varje Visual Studio-version innehåller en motsvarande .NET SDK. När du uppdaterar Visual Studio uppdateras även den inkluderade SDK-versionen. Du kan dock fortsätta att använda äldre SDK-versioner genom att installera dem separat från nedladdningssidan för .NET.

MSBuild-versioner motsvarar Visual Studio-versioner. Visual Studio 2022 version 17.8 innehåller till exempel MSBuild 17.8. .NET SDK innehåller även MSBuild. När du använder dotnet buildanvänder du den MSBuild-version som ingår i SDK:t som anges av global.json eller den senaste installerade SDK:t.

Så här använder du en specifik MSBuild-version:

  • Använd dotnet build med en pinnad SDK-version i global.json.
  • Starta lämplig Visual Studio Developer-kommandotolk, som konfigurerar miljön för visual studioversionens MSBuild.
  • Anropa MSBuild direkt från en specifik Visual Studio-installation (till exempel "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\MSBuild.exe").

Mer information finns i versionshantering för .NET SDK, MSBuild och Visual Studio.

Uppdatera kontinuerlig integrering (CI)

CI-pipelines följer en liknande uppdateringsprocess som projektfiler och Dockerfiles. Vanligtvis kan du uppdatera CI-pipelines genom att endast ändra versionsvärden.

Uppdatera värdmiljön

Det finns många mönster som används för att hantera program. Om värdmiljön innehåller .NET-körningen måste den nya versionen av .NET-körningen installeras. I Linux måste beroenden installeras, men de ändras vanligtvis inte mellan .NET-versioner.

För containrar FROM måste instruktioner ändras för att inkludera nya versionsnummer.

Följande Dockerfile-exempel visar hur du hämtar en ASP.NET Core 9.0-avbildning.

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

I en molntjänst som Azure App Service krävs en konfigurationsändring.

Se även

  • Last updated on