Umstieg auf .NET Core: Desktop-Anwendungen mit WPF und Windows Forms umstellen

Nach den grundsätzlichen Überlegungen im ersten Teil der Serie, geht es jetzt um die konkrete Migration von WPF- und Windows-Forms-Anwendungen nach .NET Core.

Lesezeit: 8 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 20 Beiträge

(Bild: Shutterstock)

Von

Inhaltsverzeichnis

Anhand eines Vergleichs der grundsätzlichen Vor- und Nachteile von .NET Core gegenüber dem klassischen .NET Framework bot der einleitende Artikel zur Serie "Umstieg auf .NET Core" eine Entscheidungshilfe für die Migration. Nun geht es darum, wie sich in der Folge WPF- und Windows-Forms-Anwendungen auf .NET Core umstellen lassen.

Mit den ersten beiden Versionen 1.x und 2.x von .NET Core konnten Entwickler nur Konsolenanwendungen und Windows 10 Universal Apps sowie Webserveranwendungen und REST-basierte Webservices erstellen. Erst seit Version 3.0 vom 23. September 2019 ermöglicht Microsoft auch klassische Desktop-Anwendungen mit der Windows Presentation Foundation (WPF) und dessen Vorgänger Windows Forms im Rahmen der sogenannten .NET Core Windows Desktop Runtime. In der Anfang Dezember veröffentlichten Version .NET Core 3.1 hat der Softwarehersteller schließlich weitere Punkte vervollständigt, aber auch wieder einige Features entfernt.

Daher ist auch nach Version 3.1 der Status der beiden GUI-Frameworks auf .NET Core unterschiedlich: WPF auf .NET Core 3.1 ist fast vollständig und für die meisten Kunden sicherlich einsatzreif. In Windows Forms auf .NET Core 3.1 gibt es hingegen eine gewaltige Lücke: Der Designer für Windows Forms in .NET-Core-Projekten ist nicht einsatztauglich.

Sowohl für WPF als auch Windows Forms auf .NET Core gilt: Sie durchbrechen die Plattformunabhängigkeit von .NET Core: Anwendungen, die diese GUI-Frameworks einsetzen, laufen nur auf Windows.

In WPF auf .NET Core fehlen gegenüber WPF auf dem klassischen .NET Framework folgende Funktionen:

  • WPF im Browser alias: XAML Browser Application (XBAP)
  • Click-Once-Deployment
  • Microsoft-Report-Viewer-Komponenten

Die beiden letzten Funktionen gehören im engeren Sinne nicht zu WPF, werden aber häufiger in Verbindung mit WPF verwendet.

In einer Detailanalyse der übrigen Klassen hat Patrick Smacchia ermittelt, dass nur 16 von insgesamt 4095 der Kernklassen von WPF fehlen.

Für WPF-Projekte bietet Visual Studio eine .NET Core-Projektvorlage und den visuellen GUI-Designer, der aus klassischen .NET-Framework-Projekten bekannt ist. Wie in .NET Core üblich, lassen sich Projekte auch mit dem .NET Core Command Line Interface (CLI) mit dotnet new wpf anlegen, und auch die Projektdateien (.csproj) für WPF unter .NET Core sind im Vergleich zu den alten Projektdateien im klassischen .NET Framework ausgesprochen prägnant, wie das nachfolgende Listing zeigt. Insbesondere sind nicht mehr alle Codedateien einzeln aufgeführt. Denn entgegen des bisher üblichen Prinzips müssen nur noch Dateien genannt werden, die nicht kompiliert werden sollen.

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

  <PropertyGroup>
    <OutputType>WinEXE</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <UseWPF>true</UseWPF>
    <RootNamespace>MiracleListLight_WPFUI</RootNamespace>
    <ApplicationIcon>Assets\favicon.ico</ApplicationIcon>
  </PropertyGroup>

<!-- Assets -->
  <ItemGroup>
    <Resource Include="assets\favicon.ico" />
    <Resource Include="assets\MiracleListLogo.jpg" />
  </ItemGroup>

<!-- Nuget Packages -->
  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="3.1.0" />
    <PackageReference Include="Microsoft.Windows.Compatibility" Version="3.1.0" />
  </ItemGroup>

<!-- Projects -->
   <ItemGroup>
   <ProjectReference Include="..\MiracleListLight_BO\MiracleListLight_BO.csproj" />
   <ProjectReference Include="..\MiracleListLight_DAL\MiracleListLight_DAL.csproj" />
   </ItemGroup>

<!-- DLLs -->
  <ItemGroup>
    <Reference Include="ITV_AppUtil">
      <HintPath>..\_Libs\ITV_AppUtil.dll</HintPath>
    </Reference>
  </ItemGroup>
</Project>