© Event Horizon/shutterstock.com, © S&S Media
WPF und sogar Windows Forms in .NET Core 3.0

Sie sind wieder da!


Zwei Totgesagte leben länger: Nachdem viele .NET-Entwickler nicht nur Windows Forms, sondern auch WPF aufgegeben hatten, sind jetzt beide Desktop-Frameworks in .NET Core 3.0 neu erschienen und erlauben die Migration alter Anwendungen.

In den Versionen 1.0, 1.1, 2.0, 2.1 und 2.2 war das modulare .NET Core auf Webserveranwendungen (MVC, Razor Pages, Web-APIs) und Konsolenanwendungen sowie die eingeschränkten Windows 10 Universal Apps beschränkt. Am 23. September 2019 ist nun .NET Core 3.0 erschienen. Damit kann man eine Reihe weiterer Anwendungsarten erstellen: Hintergrunddienste (Windows Services und systemd für Linux), Googles RPC-Server und -Clients (gRPC), Single Page Web Applications mit ASP.NET Blazor Server und auch klassische Desktopanwendungen mit Windows Forms und WPF auf Basis der neuen .NET Core Desktop Runtime (Abb. 1).

schwichtenberg_NETCore3_1.tif_fmt1.jpgAbb. 1: Die .NET-Familie 2019

Während alle anderen .NET-Core-Anwendungsarten plattformneutral sind, laufen Windows Forms und WPF allerdings nur auf Windows (ab Windows 7 und Windows Server 2012 R2). Microsoft hat zwar den .NET-Teil beider Frameworks auf .NET Core portiert, nicht aber die Basistechniken (GDI, Milcore und DirectX). Bislang gibt es zwar keine konkrete Ankündigung, auch diese zu portieren, um WPF und Windows Forms plattformneutral zu machen, Microsoft schließt aber auf Nachfrage auch nicht aus, dass das in Zukunft passieren könnte.

Funktional fast ganz da

Funktional sollen WPF und Windows Forms in der .NET-Core-Welt ihren Brüdern aus der klassischen .NET-Framework-Welt entsprechen. Bei Windows Forms fehlt aber noch der grafische Designer für Visual Studio. Ihn gibt es seit dem 30. September 2019 als funktionseingeschränkte Vorschauversion [1]. Wer dennoch schon mit Windows Forms in .NET Core arbeiten will, muss die Oberflächen noch in einem klassischen .NET-Framework-Projekt gestalten und das Ergebnis dann in .NET Core verlinken. Ebenso laufen Anwendungen noch nicht in .NET Core, die den Windows-Forms-Designer selbst in sich hosten, um Endanwendern die (Um-)Gestaltung von Formularen zu ermöglichen.

Auch die oft in Windows-Forms- und WPF-Anwendungen eingesetzte Microsoft-ReportViewer-Komponente gibt es noch nicht für .NET Core [2]. Typisierte Data Sets, auch in den alten Welten noch oft im Einsatz, funktionieren in .NET Core 3.0 wegen eines gravierenden Bugs in der System.Data.SqlClient-Bibliothek nur mit aufwendigen manuellen Eingriffen in den generierten Programmcode [3]. Abhilfe für den letzten Punkt soll erst in .NET Core 3.1 gegen Jahresende kommen, auch wenn der Autor dieses Beitrags das Problem fast dreieinhalb Wochen vor dem Erscheinen von .NET Core 3.0 an Microsoft gemeldet hatte. Obwohl ein Fix eine Woche später durch einen Microsoft-Entwickler erstellt war, ist das Entwicklungsteam immer noch nicht agil genug, diesen nur leicht geänderten Quellcode dann kurzfristig in die Produktversion 3.0 zu mergen.

Bei WPF fehlen die XAML Browser Applications (XBAP). Patrick Smacchia hat in einer Analyse mit NDepend ermittelt, dass bei WPF nur 16 öffentliche Klassen (von 4 095) und 52 öffentliche Methoden fehlen [4]. Das ist nicht viel, kann im Einzelfall aber natürlich die Umstellung dennoch behindern. Und es fehlen natürlich in .NET Core 3.0 all diejenigen Techniken, die Microsoft nicht mehr auf .NET Core portieren will [5]:

  • .NET Remoting

  • Application Domains

  • ASP.NET Dynamic Data

  • ASP.NET Web Forms (ASPX)

  • ASP.NET Web Services (ASMX)

  • Click-once Deployment

  • LINQ to SQL

  • Windows Communication Foundation (WCF) als Server

  • Windows Workflow Foundation (WF)

Nicht in der Liste erscheint die Interoperabilität mit COM- und WinRT-Komponenten, denn sie ist in .NET Core 3.0 nun möglich – aber natürlich nur auf Windows. Leider ist die Dokumentation zur Umstellung von .NET Framework auf .NET Core sehr spärlich [6]. Weder das Problem mit den typisierten Data Sets noch die fehlende ReportViewer-Komponente wird erwähnt.

.NET Portability Analyzer

Bevor man eine Umstellung startet, sollte man den .NET Portability Analyzer [7] über seinen Quellcode laufen lassen. Das Werkzeug liefert eine Microsoft-Excel-Datei, die Auskunft über die Verfügbarkeit der verwendeten Klassen und Klassenmitglieder unter .NET Core gibt (Abb. 2 und 3). Die in Abbildung 1 genannten Platform Extensions bedeuten diverse Erweiterungen zu .NET Core, insbesondere die .NET Core Desktop Runtime und das Windows Compatibility Pack [8].

Die in Abbildung 2 gezeigte 99,77-Prozent-Kompatibilität gilt für ein echtes Windows-Forms-Projekt älteren Semesters. Die Zahl klingt gut, die restlichen 0,23 Prozent (in Abb. 3: „not supported“) haben aber im konkreten Fall dazu geführt, dass wesentliche Programmfunktionen (die dynamisch durch den Benutzer gestaltbaren Formulare auf alle (!) auf Microsoft Reports basierenden Berichte) umgeschrieben werden müssten. Das Projekt kann daher unter .NET Core 3.0 nicht in Betrieb gehen und muss auf Version 3.1 (geplant für Ende 2019) hoffen.

schwichtenberg_NETCore3_2.tif_fmt1.jpgAbb. 2: Zusammenfassungsseite des .NET Portability Analyzers
schwichtenberg_NETCore3_3.tif_fmt1.jpgAbb. 3: Detailseite des .NET Portability Analyzers

Migrationsschritte

Einige andere WPF- und Windows-Forms-Anwendungen aus der Praxis konnte der Autor bereits erfolgreich auf .NET Core 3.0 umstellen. Wer die Migration einer WPF- und Windows-Forms-Anwendung angehen will, muss beachten, dass es innerhalb von Visual Studio dafür bislang kein Migrationswerkzeug gibt. Am 4. Oktober 2019 hat Microsoft eine erste Version 0.1 eines auf dem .NET Core CLI basierenden Kommandozeilenwerkzeugs mit dem (nicht sehr vertrauenerweckenden) Namen „try-convert“ bereitgestellt. Das Werkzeug kann einzelne Projekte oder ganze Projektmappen übersetzen, aber leider nicht alle Projektarten. Ausgenommen werden zum Beispiel Unit-Test-Projekte und ASP. NET-Webprojekte. Leider ist das Konvertierungsergebnis noch schlecht: In mehreren Testfällen konnten zwar einzelne Klassenbibliotheken, nicht aber GUI-Projekte umgestellt werden. Die GUI-Projekte waren auch in der neusten Visual-Studio-Version 2019 v16.4 Preview nicht nutzbar (Abb. 4).

schwichtenberg_NETCore3_4.tif_fmt1.jpgAbb. 4: try-convert 0.1 zerstört Projektdateien

Grundsätzlich kann man die Migration auch händisch vornehmen. Zu beachten ist, dass sich das Projektformat der .csproj- bzw. vbproj-Dateien stark geändert hat. Insbesondere gilt in der neuen Welt...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang