Migration von .NET Framework 4.8 zu .NET 11 im Jahr 2026

Korrektur — 2. November 2026: Korrigiert wurden Releasestatus und Support von .NET 11, Framework-Lebenszyklus, Konfigurationsbindung, Serialisierung, Werkzeuge und Bereitstellung. Unbelegte Angaben zu Dauer, Speicherersparnis und angeblich selbst erlebten Problemen wurden entfernt.

Der Wechsel von .NET Framework 4.8 zu modernem .NET kann einen neuen Anwendungshost sowie Änderungen an Bibliotheken, Bereitstellung und Datenverträgen erfordern. Es ist kein In-Place-Runtime-Update. Klären Sie zuerst den Anlass und welche Teile unabhängig umziehen können.

Zum Prüfdatum ist .NET 11 RC3 eine Go-live-Vorabversion, .NET 11 eine STS-Linie und .NET 10 die veröffentlichte LTS-Option. Framework-Support folgt dem jeweiligen Windows-Produkt. Es gibt kein einheitliches Framework-4.8-Enddatum für sämtliche Windows-10-Installationen. Prüfen Sie das tatsächliche Betriebssystem und dessen unterstützte Framework-Version.

Vor Änderungen inventarisieren

Bauen und testen Sie die bestehende Anwendung in ihrer unterstützten Windows-Umgebung. Halten Sie Entwickler-/Referenzpakete und Buildwerkzeuge während der Migration verfügbar. Erfassen Sie Authentifizierung, Sitzungen, Windows-Integration, native Bibliotheken, Jobs, Datenbankprovider und gespeicherte Formate. Ob ein net48-Paket weiterverwendbar ist, hängt von APIs und Assets ab.

Die Upgrade-Assistant-Übersicht bezeichnet das Werkzeug inzwischen als veraltet und verweist auf den GitHub-Copilot-Modernisierungsagenten. Automatisierte Unterstützung ist optional; prüfen und testen Sie deren Änderungen. Ein alter unfixierter Installationsbefehl garantiert keine .NET-11-Unterstützung.

Trennen Sie nach Möglichkeit Projektformatbereinigung und Runtime-Wechsel. SDK-Stil übersetzt weder System.Web noch WCF-Hosting, COM-Abhängigkeiten oder eigene MSBuild-Tasks. Bewahren Sie einen funktionierenden Ausgangszustand und migrieren Sie Blattbibliotheken vor ihren Aufrufern.

Migrationsgrenze wählen

Microsofts ASP.NET-Migrationsleitfaden unterstützt inkrementelles Vorgehen. Routen hinter einem Proxy erlauben den Weiterbetrieb alter Teile. Eine Teilmigration ist sinnvoll, wenn Authentifizierung, Routing, Datenverantwortung und Rollback bewusst geregelt sind.

CoreWCF garantiert keine vollständige WCF-Kompatibilität. Testen Sie Ihre Bindings und Authentifizierung. EF6 unterstützt modernes .NET seit 6.3; wählen und testen Sie eine aktuelle kompatible Version samt Provider, statt 6.5.0 als universelle Mindestversion anzunehmen. EF Core ist kein direkter Ersatz für EF6.

Mit einem kleinen funktionierenden Teil beginnen

Ein ASP.NET-Core-Evaluierungsprojekt für .NET 11 hat diese Grundstruktur:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>net11.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

Verwenden Sie ein installiertes, bewusst gewähltes SDK und kompatible Pakete. Die .NET-8-zu-11-Checkliste zeigt den aktuellen RC3-Pin. Desktopprojekte benötigen dagegen passende Windows-TFMs und Einstellungen; ersetzen Sie nicht jedes Projekt durch Microsoft.NET.Sdk.Web.

Dieses vollständige Program.cs ist ein Smoke-Test, keine migrierte Anwendung:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/health", () => Results.Ok(new { status = "ok" }));
app.Run();

Es wurde bei dieser Korrektur unter .NET 8 und 10 gebaut, veröffentlicht und aufgerufen. Eine MVC-Anwendung muss Controller registrieren, bevor sie diese abbildet. Authentifizierung benötigt ein tatsächliches Schema und Dienste; UseAuthentication() allein migriert keine Forms Authentication.

Konfiguration und Datensemantik erhalten

Ein kleines appsettings.json:

{
  "Migration": {
    "MaxRetries": 3
  }
}

Der .NET-JSON-Konfigurationsprovider ignoriert Groß-/Kleinschreibung bei Schlüsseln. Das ist von allgemeinen JSON-Serialisierungsregeln zu unterscheiden. Prüfen Sie Providerreihenfolge und Geheimnisspeicherung. XML-Unterstützung bildet nicht automatisch alle app.config-Abschnitte oder Binding Redirects nach. System.Configuration.ConfigurationManager kann für unterstützte APIs eine Kompatibilitätsoption sein; nicht jede Verwendung muss entfernt werden. Bei IIS bleibt web.config relevant.

Die eingebaute BinaryFormatter-Implementierung wirft ab .NET 9, der Typ bleibt jedoch erhalten. Nutzen Sie einen unterstützten Serializer oder prüfen Sie den NRBF-Reader zum Lesen alter Daten ohne Instanziierung beliebiger kodierter Typen. Konvertierung erfordert nicht zwingend den alten unsicheren Deserializer unter Framework 4.8.

AssemblyLoadContext ermöglicht Laden und kooperatives Entladen, ersetzt aber keine AppDomain-Sicherheitsgrenze. Referenzen, laufender Code und Ereignishandler können das Entladen verhindern. Ein einzelner GC-Lauf beweist keinen Erfolg. Unvertrauenswürdiger Code benötigt eine geeignete Prozess-/Containergrenze mit passenden Berechtigungen.

Lassen Sie Zertifikatsvalidierung aktiv. Prüfen Sie Zertifikat, Hostname, Vertrauenskette, SQL-Client-Einstellungen und Plattform bei TLS-Fehlern. Akzeptieren Sie nicht pauschal jedes Zertifikat. Testen Sie konkrete Datumsformate, Kulturen und Serialisierungsverträge statt einer unbelegten allgemeinen Parsing-Änderung in .NET 11.

Bereitstellung und Rollback üben

dotnet restore
dotnet build -c Release --no-restore
dotnet test -c Release --no-build
dotnet publish -c Release --self-contained false

Der Publish-Befehl erzeugt ausdrücklich eine frameworkabhängige Anwendung. Self-contained erfordert --self-contained true und einen geeigneten RID; es ist keine automatische Folge von dotnet publish. Behalten Sie Windows-CI für verbleibende Framework-Projekte und prüfen Sie moderne Artefakte auf der Zielplattform.

Testen Sie auch verweigerte Zugriffe, Sitzungen, Datenbankänderungen, Nachrichten, Hintergrundarbeit und Desktopintegration. Halten Sie das alte Deployment bereit, ändern Sie Schema und Daten abwärtskompatibel und üben Sie die Rückschaltung. Rollback benötigt alte Anwendung und Konfiguration, nicht bloß die Neuinstallation der Framework-Runtime.

Prüfgrenzen: Keine Windows-/Framework-Anwendung, kein .NET-11-SDK, kein WCF-Dienst, keine EF-Provider-Migration und kein Produktionsdeployment wurden hier getestet. Portabler Endpunkt und Konfigurationsschlüssel wurden unter .NET 8 und 10 geprüft. Aufwand und Leistung müssen anhand Ihres eigenen repräsentativen Teilprojekts geschätzt werden.

Weitere Primärquellen

• AssemblyLoadContext
• .NET Framework technologies unavailable on .NET
• .NET application publishing