Ein altes WPF-Projekt auf .NET 10 heben
- Matt
Über die Feiertage habe ich eine WPF-Anwendung von .NET Framework 4.8 auf .NET 10 gehoben. Rund 40.000 Zeilen, gewachsen seit 2016. Was ich vorher gern gewusst hätte.
Der einfache Teil
Die Projektdatei wird ersetzt, nicht angepasst. Aus einer 300-Zeilen-.csproj mit einzeln aufgelisteten Dateien wird:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>net10.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
<Nullable>enable</Nullable>
</PropertyGroup>
</Project>
Das -windows im Zielframework ist Pflicht, sonst kennt der Compiler keine WPF-Typen. Dateien werden nicht mehr aufgezählt, alles im Ordner wird übersetzt. Das allein hat bei mir 260 Zeilen gespart und die Konflikte beim Zusammenführen halbiert.
Der Teil, der Arbeit macht
app.config und Konfigurationsabschnitte. ConfigurationManager.AppSettings funktioniert zwar noch über ein Paket, aber eigene ConfigurationSection-Klassen sind der Punkt, an dem man umbaut. Ich habe auf IConfiguration mit JSON gewechselt und dabei gleich die Validierung beim Start eingebaut.
Alles rund um Verschlüsselung und Zertifikate. Hier lagen die einzigen echten Verhaltensänderungen. Standardwerte haben sich verschoben, und einiges aus dem alten System.Security.Cryptography ist unter .NET nicht mehr da oder tut etwas anderes.
Drittanbieter-Steuerelemente. Der offensichtliche Punkt, den man trotzdem unterschätzt. Ein Steuerelement ohne .NET-Version ist der Moment, an dem das Projekt steht.
Was ich empfehlen würde
Nicht in einem Zug. Erst die Projektdateien auf das neue SDK-Format umstellen, aber weiterhin auf net48 bauen. Das läuft, ist getestet und man hat den größten strukturellen Schritt hinter sich. Danach in einem zweiten Durchgang das Zielframework hochziehen.
Der Upgrade Assistant nimmt einem den mechanischen Teil ab. Die Konfiguration und die Kryptografie muss man selbst durchgehen.
Gedauert hat es zwei Tage statt der geschätzten vier Stunden. Das ist ungefähr der übliche Faktor.