Seite 3: Windows Forms migrieren

Für Windows-Forms-basierte Anwendungen gestaltet sich die Situation ähnlich, im Detail zeigen sich jedoch Unterschiede. Zunächst einmal können Entwickler eine Windows-Forms-Anwendung auf .NET Core auch via Projektvorlage in Visual Studio oder per .NET Core CLI dotnet new winforms beginnen. Das Projektformat ist genauso prägnant. Die einzige Änderung betrifft das Tag: <UseWindowsForms>true</UseWindowsForms> statt <UseWPF>true</UseWPF>.

Wie bei WPF fehlt ein adäquates Migrationswerkzeug von Microsoft, die Migrationsschritte sind hingegen gleich und auch der skriptbasierte Ansatz aus Listing 2 kann unterstützen.

Allerdings ist es aus der Sicht eines auf Effizienz ausgelegten Praktikers noch zu früh, jetzt eine Windows-Forms-Anwendung auf .NET Core zu schreiben oder eine bestehende Anwendung zu migrieren. Grund dafür ist, dass es noch keinen praxistauglichen Designer für Windows-Forms-Benutzeroberflächen in einem .NET-Core-Projekt gibt. Es findet sich in Visual Studio 2019 Version 16.5 Preview 1 eine Vorschauversion, die man in den Optionen der Entwicklungsumgebung aktivieren kann (Menü Tools/Options, Rubrik Environment/Preview Features), diese Vorschauversion funktioniert aber nur für sehr einfache Fenster. Sobald es einen komplexeren Bildschirmaufbau gibt, streikt der Designer, wie sich in den Abbildungen 3 und 4 nachvollziehen lässt.

Als Umgehung empfiehlt Microsoft in "How to port a Windows Forms desktop app to .NET Core", parallel zu dem .NET-Core-Projekt noch ein .NET-Framework-basiertes Projekt zu behalten und in diesem die Oberflächen zu gestalten. Dann soll das .NET-Core-Projekt die generierten Code- und Ressourcendateien beim Kompilieren folgendermaßen einbinden:

<ItemGroup>
    <Compile Include="..\MyFormsApp\**\*.cs" />
    <EmbeddedResource Include="..\MyFormsApp\**\*.resx" />
 </ItemGroup>

Das funktioniert zwar, hemmt den Arbeitsfluss aber spürbar.

Einen verkündeten Erscheinungstermin für den Windows Forms Designer für .NET Core gibt es noch nicht. Dass sich dies so lange hinzieht, liegt auch an der Komplexität der Materie und dem Alter des Programmcodes: Er entstand um die Jahrtausendwende, und die Entwickler, die damals daran gearbeitet haben, sind längst nicht mehr verfügbar – auch weil das Produkt zwischenzeitlich viele Jahre unverändert blieb.

Einhergehend mit dem fehlenden Designer gibt es auch die dazugehörigen Klassen in .NET Core nicht. Im klassischen .NET Framework bestand stets die Möglichkeit, den Windows Forms Designer in eigene Windows-Forms-Oberflächen zu integrieren (sogenanntes Self-Hosting des Designers) und so Endbenutzer zu befähigen, die Gestaltung der Benutzeroberflächen zur Laufzeit anzupassen oder sogar eigene Formulare zu gestalten.

Der Windows Forms Designer soll Microsoft zufolge "irgendwann in diesem Jahr" fertig werden. Unklar bleibt, ob dann auch das Self-Hosting des Designers zurückkehren wird.

Aber auch wenn Microsoft diese Lücke schließt, eine andere wird bleiben: Einige ältere Windows-Forms-Steuerelemente aus dem klassischen .NET Framework, die es in allen Versionen von 1.0 bis 4.8 gibt, sind in .NET Core 3.1 nicht mehr enthalten (s. Tabelle 1). Das betrifft allerdings Steuerelemente, die in modernen Windows-Forms-Anwendungen nicht mehr so häufig eingesetzt werden. Microsoft hatte diese Steuerelemente in .NET Framework 1.0 2002 eingeführt, aber bereits drei Jahre später in .NET Framework 2.0 bessere Alternativen angeboten (s. dritte Spalte in Tabelle 1). Das heißt aber nicht, dass alle Kunden auf diese Steuerelemente migriert hätten beziehungsweise dass nicht auch noch neue Anwendungen seit 2005 damit entstanden sind.

Kurios ist, dass die in der ersten Spalte genannten Steuerelemente von Microsoft in .NET Core 3.0 eingebaut wurden, in der drei Monate später erschienenen .NET-Core-Version 3.1 aber wieder entfernt wurden. Solche Breaking Changes, die verhindern, dass eine 3.0-basierte Anwendung einwandfrei auf Version 3.1 läuft, sollte es gemäß dem von Microsoft propagierten Semantic Versioning in einem Versionssprung an der zweiten Stelle (von 3.0 auf 3.1) allerdings gar nicht geben.

Den Grund für den Verstoß gegen die Prinzipien des Semantic Versioning nennt der Softwarehersteller aus Redmond im Blogeintrag zu .NET Core 3.1: Man will sich den Aufwand ersparen, auch diese Steuerelemente im neuen Windows Forms Designer für .NET Core einzubauen. Zitat Richard Lander, Program Manager im .NET-Team: "As we got further into the Windows Forms designer project, we realized that these controls were not aligned with creating modern applications and should never have been part of the .NET Core port of Windows Forms. We also saw that they would require more time from us to support than made sense." Immerhin ist sich der Hersteller seiner Schuld bewusst und entschuldigt sich bei den Kunden: "We should have made these changes before we released .NET Core 3.0, and we appologize for that."