WPF und sogar Windows Forms in .NET Core 3.0

Totgesagte leben länger: WPF und Windows Forms sind wieder da!
Keine Kommentare

Viele .NET-Entwickler hatten nicht nur Windows Forms, sondern auch WPF aufgegeben. Wer hätte das gedacht: Nun sind jetzt beide Desktop-Frameworks in .NET Core 3.0 neu erschienen, die Migration alter Anwendungen ist möglich.

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. Dort 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).

Abb. 1: Die .NET-Familie 2019

Abb. 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 dies 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. 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.

BASTA! 2020

Entity Framework Core 5.0: Das ist neu

mit Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

Memory Ownership in C# und Rust

mit Rainer Stropek (timecockpit.com)

Softwarearchitektur nach COVID-19

mit Oliver Sturm (DevExpress)

Auch die oft in Windows-Forms- und WPF-Anwendungen eingesetzte Microsoft-ReportViewer-Komponente gibt es noch nicht für .NET Core. 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. 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. Auch wenn 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 auch 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. 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 [1]:

  • .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. 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 .NET Portability Analyzer ü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.

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.

Abb. 2: Zusammenfassungsseite des .NET Portability Analyzers

Abb. 2: Zusammenfassungsseite des .NET Portability Analyzers

Abb. 3: Detailseite des .NET Portability Analyzers

Abb. 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).

Abb. 4: try-convert 0.1 zerstört Projektdateien

Abb. 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 das Prinzip, dass alle diejenigen Dateien automatisch zum Projekt gehören, die im Projektverzeichnis liegen und nicht explizit ausgeschlossen sind. In Listing 1 sieht man daher nicht einen einzigen Namen einer .xaml– oder .cs-Datei. Klassische .NET-Projekte haben eine Packages.config, in der nicht nur die referenzierten Pakete, sondern auch die transitiven Referenzen aufgeführt sind. Die neue Welt referenziert nur noch die Top-Level-Pakete per <PackageReference> direkt in der Projektdatei.

<!-- generated by MigrateMLLToCore.ps1 09/24/2019 09:31:06 -->
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

  <PropertyGroup>
    <OutputType>WinEXE</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <UseWPF>true</UseWPF>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
    <Deterministic>false</Deterministic>
    <RootNamespace>MiracleListLight_WPFUI</RootNamespace>
    <ApplicationIcon>Assets\favicon.ico</ApplicationIcon>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <PublishSingleFile>true</PublishSingleFile>
    <UseAppHost>true</UseAppHost>
  </PropertyGroup>

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

<!-- Nuget Packages -->
  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.6" />
    <PackageReference Include="Microsoft.Windows.Compatibility" Version="3.0.0" />
    <PackageReference Include="ITV.AppUtil.NETStandard.Core" Version="3.0.1" />
  </ItemGroup>

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

</Project>

Eine manuelle Migration umfasst folgende Schritte:

  • Man kopiert alle benötigen Projekte in ein neues Verzeichnis.
  • Zunächst einmal sollte man alle NuGet-Paketreferenzen auf den aktuellen Stand bringen.
  • Dann sollte man die alten Projekte schon auf <PackageReference>-Tags umstellen. Das ist in Visual Studio möglich durch den Kontextmenübefehl Migrate packages.config to PackageReference auf einer package.config-Datei (Abb. 5).
  • Nun kann man sich entscheiden, entweder die Projektdateien hinsichtlich der Tags manuell zu säubern oder eine neue Projektdatei anzulegen und dort die benötigten Einträge (NuGet-Referenzen, Projektreferenzen, DLL-Referenzen, Standardnamensraum, Anwendungssymbol etc.) wieder vorzunehmen. Die zum Projekt gehörenden Dateien muss man im neuen Format nicht mehr einzeln aufführen.
  • Für Ressourcendateien und andere Nicht-Code-Dateien (z. B. .xsd, .edmx) muss man aber die Build Action setzen (das kann man in Visual Studio per Klick; Listing 1).
  • Zu beachten ist, dass das neue Projektformat im Standard keine AssemblyInfo.cs/.vb-Datei mehr unterstützt, sondern die Metadaten in der Projektdatei selbst sucht. Das alte Konzept kann man in der Projektdatei ermöglichen durch <GenerateAssemblyInfo>false</GenerateAssemblyInfo>. Automatisch generierte Versionsnummern an der letzten Stelle schaltet man mit <Deterministic>false</Deterministic> wieder ein (Listing 1).
  • In der Regel wird man das NuGet-Paket Microsoft.Windows.Compatibility referenzieren müssen, allein schon, um das Laden von Konfigurationseinstellungen aus der app.config-Datei zu ermöglichen.
Abb. 5: Visual-Studio-Dialog zur Umstellung der Paketreferenzen auf -Tags

Abb. 5: Visual-Studio-Dialog zur Umstellung der Paketreferenzen auf -Tags

Diese Schritte kann man selbst automatisieren, z. B. per PowerShell-Skript.

Danach gibt es typischerweise noch eine Reihe von Kompilierungsfehlern für Fälle, in denen einzelne APIs in der .NET-Core-Welt fehlen. Manchmal findet man NuGet-Pakete, die das ausgleichen, manchmal muss man die Programmierung ändern. Leider gibt es dazu bislang keine systematische Dokumentation, und die Google-Suchmaschine ist der beste Helfer.

Auch an anderen Stellen zeigt Microsoft weiterhin Dokumentationsschwäche: Einige sehr zentrale Klassen wie z. B. Microsoft.EntityFrameworkCore.DbContext sind in dem .NET-API-Browser Anfang Oktober 2019 noch auf dem Stand der .NET-Core-Version 2.1 von Mai 2018. Weiterhin findet man in dem .NET-API-Browser zu den neueren Klassen und Klassenmitgliedern oft weder Beispiel noch Beschreibungstext.

ADO.NET Entity Framework 6.3

Um die Migration zu .NET Core zu vereinfachen, gibt es nun auch das klassische ADO.NET Entity Framework für .NET Core. Eigentlich hat Microsoft ja seit Juli 2016 mit dem Entity Framework Core einen Nachfolger auf dem Markt. Allerdings sind die Unterschiede zwischen beiden Implementierungen so groß, dass die Migration von Datenzugriffscode aufwendig ist. Auch in Entity Framework Core 3.0 fehlen zum Beispiel die Unterstützung für Table-per-Type-Vererbungsabbildungen und die Abstraktion von den N:M-Zwischentabellen sowie die Codegenerierung für Stored Procedures (immerhin kann die Version 3.0 nun Codegenerierung für Datenbanksichten). Mit dem neuen ADO.NET Entity Framework 6.3 können Entwickler nun vorhandenen Datenzugriffscode in die Core-Welt übernehmen. Bedauerlicherweise fehlt aber in Visual Studio derzeit auch noch die Unterstützung für den Betrieb des EDMX-Designers in .NET-Core- und .NET-Standard-Projekten. Wer bisher den Designer genutzt hat, muss sich mit dem gleichen Verlinkungstrick behelfen wie bei Windows Forms.

ADO.NET Entity Framework 6.3 sollte man aber nicht mehr für neue Projekte verwenden, denn neue Funktionen will Microsoft dort nicht einbauen. Die Version 6.3 kann man auch in klassischen .NET-Framework-Projekten installieren.

Ende für das klassische .NET Framework

Anders übrigens als Entity Framework Core 3.0 und ASP.NET Core 3.0: Bisher liefen diese beiden Core-Produkte nicht nur auf .NET Core, sondern auch auf dem klassischen .NET Framework. Damit ist nun leider Schluss: Ab Version 3.0 erfordern diese Bibliotheken .NET Standard 2.1, den es nur ab NET Core 3.0, Mono 6.4, Xamarin iOS 12.16, Xamarin Mac Version 5.16 und Xamarin Android 10.0 gibt. Für UWP und Unity ist die Unterstützung für .NET Standard 2.1 geplant, nicht aber für das klassische .NET Framework, das hatte Microsoft schon im November 2018 klargestellt.

Immerhin hat Microsoft in einem Nebensatz angekündigt, den Support für ASP.NET Core 2.1 inklusive Entity Framework Core 2.1 auf .NET Framework abweichend von der Supportrichtlinie verlängern zu wollen. Für die 2.1er-Versionen gibt es eigentlich Long-Term-Support bis zum 21. August 2021. Man wird dann sehen müssen, bis wann Microsoft den Support für die .NET-Framework-Basis verlängern wird. Der Support für die 2.2er-Version, die nur den Current-Status hatte, läuft bereits am 23. Dezember 2019 aus.

In den folgenden Monaten hatte Microsoft immer weitere Sargnägel in das klassische .NET Framework getrieben. So kann man dort nun auch nicht mehr den kompletten Sprachumfang von C# 8.0 verwenden. Schließlich stellte Microsoft im Mai 2019 klar, dass die im April 2019 erschienene Version .NET Framework 4.8 die letzte Version war.

Es besteht aber kein Grund zur panischen Umstellung auf .NET Core, denn Microsoft schrieb gleichwohl:

  • „.NET Framework 4.8 will be the last major version of .NET Framework.“
  • „It will continue to ship with Windows (much of Windows depends on .NET Framework).“
  • „.NET Framework will always be a part of Windows.“
  • „We will continue to both service and support .NET Framework, which includes bug-, reliability- and security fixes.“
  • „We will continue to improve the tooling support for .NET in Visual Studio (Visual Studio is written on .NET Framework).“
  • „If you have existing .NET Framework applications that you are maintaining, there is no need to move these applications to .NET Core.“

Deutliche Vorteile von .NET Core

Niemand ist folglich zum Umstieg auf .NET Core gezwungen, doch es gibt natürlich von Microsoft Anreize für eine solche Migration:

  1. Neuere Funktionalitäten und Innovationen gibt es nur noch in .NET Core. Dazu gehören C#-Sprachfeatures wie Index und Range sowie Schnittstellen mit Standardimplementierungen. Aber auch für Windows Forms gibt es ein neues API für die Anpassung auf hochauflösende Geräte nur in .NET Core.
  2. Die Performance von .NET-Core-Anwendungen ist besser, da Microsoft sowohl am Just-in-Time-Compiler und dem Garbage Collector als auch an den Basisbibliotheken wesentliche Verbesserungen vorgenommen hat.
  3. Die Werkzeuge sind einfacher geworden, vgl. das kompakte Projektformat in Listing 1. Mehr Kommandozeilenwerkzeuge bedeuten gleichzeitig eine bessere Unterstützung für die DevOps-Automatisierung.
  4. Beim Deployment gibt es neue Optionen.

.NET-Core-Anwendungen einfacher verbreiten

In .NET Core gibt es schon seit Version 1.0 das Self-contained Deployment (SCD). Eine Self-contained App (SCA) erfordert nicht mehr die vorherige Installation einer Runtime. Die SCA bringt selbst im Anwendungsverzeichnis neben der .exe-Datei alles mit, was sie zum Betrieb auf einem konkreten Betriebssystem braucht (also CLR und Basisklassen). Zudem können beliebig viele .NET-Core-Runtime-Versionen im Anwendungsverzeichnis parallel auf einem System existieren. Alternativ kann man auch das aus dem .NET Framework bekannte Verfahren Portable App weiterhin nutzen, indem man eine .NET Core Runtime zentral auf dem System getrennt installiert. So weit zu dem, was es in .NET Core 1.x und 2.x schon gab, was aber nun eben auch für Windows-Forms- und WPF-Anwendungen nutzbar ist. Darüber hinaus bietet .NET Core 3.0 neue Deployment-Optionen:

  • Zum beschleunigten Start einer Anwendung kann der Entwickler parallel zu der Intermediate Language (IL) auch schon den zugehörigen Maschinencode in das Kompilat einbetten. Diese Nachfolgefunktion von ngen.exe nennt Microsoft ReadyToRun Images (R2R). Sie basiert auf dem neuen Werkzeug CrossGen, das intern den Just-in-Time-Compiler RyuJIT verwendet. Noch ist IL zusätzlich zum Maschinencode in dem Kompilat notwendig. Die schon lange in der Entwicklung feststeckende Ahead-of-Time-Kompilierung (AOT), die es bisher nur für Mono und die Windows 10 Universal App Platform gibt, hat Microsoft nun für .NET 5.0 (November 2020) angekündigt.
  • Der aus Mono stammende .NET Core IL Linker entfernt alle nicht benötigten DLLs aus einem SCA-Deployment-Paket und verringert die so verbreitende Dateimenge. Allerdings entfernt er auch DLLs, die nur dynamisch via Reflection aufgerufen werden. In diesem Fall muss der Entwickler manuell in der Projektdatei oder einer getrennten XML-Datei die benötigten DLLs auflisten, damit die Anwendung auch nach dem Linking noch voll funktionsfähig ist. Ein komplettes Tree Shaking für Unterroutinen soll es auch erst in .NET 5.0 geben.
  • In einem Single-file Executable (siehe <PublishSingleFile6gt; in Listing 1) bündelt der Entwickler alle für eine Anwendung notwendigen DLLs und weitere Dateien zu einem selbstextrahierenden Archiv zur vereinfachten Weitergabe. Die Dateien werden entpackt nach C:\Users\Benutzername\AppData\Local\Temp\.net\Anwendungsname. Der erste Start der Anwendung wird dadurch merklich verlangsamt. Beim zweiten Start greift .NET Core auf das entpackte Ergebnis zu. In .NET Core 5.0 soll es dann ein echtes Single-file Executable mit Tree Shaking und AOT geben.
  • Auch mit dem neueren MSIX-Installationspaketformat (dem Nachfolger von MSI) können .NET-Core-Entwickler nun Anwendungen verpacken. MSIX ist der Nachfolger des Click-once Deployment und unterstützt die Installation von Netzlaufwerk und Webserver sowie die automatische Aktualisierung von Anwendungen.

Neue Klassen

In .NET Core 3.0 hat Microsoft mit neuen Klassen weitere Anreize geschaffen. Da ist zum einen die bessere Unterstützung für Plug-in-/Add-in-Architekturen. Mit der Klasse MetadataLoadContext kann ein Entwickler von einer Assembly nur die Metadaten laden, ohne die Assembly selbst in den aktuellen Prozess zu laden. Geladene Assemblies kann man nun mit dem AssemblyLoaderContext auch wieder entladen. Das funktionierte im Test auch noch nach 15 000 Entladungen in einem Prozess (was sicher mehr ist, als in der Praxis benötigt wird). Zu beachten ist aber, dass das nur außerhalb des Debuggers funktioniert. Der Visual-Studio-Debugger (Version 2019 16.3) stürzt nach rund 150 Entladungen ab.

Die Klasse System.Net.Http.HttpClient unterstützt nun HTTP/2. Auch TLS 1.3 ist implementiert, aber bisher nur auf Linux. Die seriellen Schnittstellen, die bisher nur unter Windows programmierbar waren, sind jetzt auch unter Linux nutzbar. Zur Ansteuerung von IoT-Geräten gibt es die neuen Pakete System.Device.GPIO und Iot.Device.Bindings.

Neu bei der Verschlüsselung sind die Verfahren Advanced Encryption Standard Galois/Counter Mode (AES-CGM, Klasse System.Security.Cryptography.AesGcm) und Advanced Encryption Standard Counter mit CBC-MAC (AES-CCM, Klasse System.Security.Cryptography.AesCcm).

In der Mathebibliothek System.Math gibt es einige neue Funktionen wie BitIncrement(Double), BitDecrement(Double), MaxMagnitude(Double, Double), MinMagnitude(Double, Double), ILogB(Double), ScaleB(Double, Int32) und CopySign(Double, Double).

Zurück auf den eigenen JSON-Weg

Noch lange vor der Zeit, in der Microsoft selbst Open Source produziert hat, entschloss sich das ASP.NET-Entwicklungsteam, auf die JSON.NET-Komponente von James Newton-King zu setzen statt auf die in .NET Framework 3.5 fest eingebaute Klasse System.Runtime.Serialization.Json.DataContractJsonSerializer. Nun, im Jahr 2019, geht Microsoft wieder eigene Wege, nachdem man sich mit James Newton-King nicht auf eine Neuimplementierung der Innereien von JSON.NET mit Hilfe der performanten Speicherzugriffsklasse Span<T> einigen konnte. James Newton-King dazu: „Supporting new technologies like Span would require fundamental breaking changes to the library and would disrupt existing applications and libraries that depend on it“.

Folglich gibt es jetzt mit dem Paket System.Text.Json eine neue JSON-Implementierung mit Reader, Writer, Document Object Model sowie Serializer und Deserializer. Das Paket ist im Standard aktiv in ASP.NET Core 3.0 und – das beweist leider die Praxis – tatsächlich nicht zu 100 Prozent kompatibel zu JSON.NET. Die Datumsformathandhabung ist strenger. Während JSON.NET eine Datumsangabe der Form 2019-07-15T15:04:05.00+0100 und 2019-07-15T15:04:05.000 +01:00 auch akzeptiert, gelingt eine Deserialisierung bei System.Text.Json nur ohne Punkt und mit Doppelpunkt: 2019-07-15T15:04:05:000+01:00.

System.Text.Json wirkt in vielen Teilen von ASP.NET Core 3.0, z. B. in Web APIs und der Authentifizierung. Zum Glück kann man auf JSON.NET in der Start-up-Klasse zurückschalten: services.AddMvc().AddNewtonsoftJson() mit dem neuen NuGet-Paket Microsoft.AspNetCore.Mvc.NewtonsoftJson.

Die Geschwindigkeit von System.Text.Json ist in den meisten Fällen etwas besser als bei JSON.NET, aber die auf dem DevBlog erklärten Ziele, bis zu doppelt so schnell zu sein, lassen sich nicht nachmessen (Abb. 6).

Wer will, kann System.Text.Json auch außerhalb von .NET Core 3.0 verwenden, in .NET Core 2.0, .NET Standard ab 2.0, .NET Framework ab 4.6.1, UWP ab 10.10.16299 und Xamarin.

Abb. 6: Geschwindigkeit bei Serialisierung und Deserialisierung von „System.Text.Json“ im Vergleich zu JSON.NET

Abb. 6: Geschwindigkeit bei Serialisierung und Deserialisierung von „System.Text.Json“ im Vergleich zu JSON.NET

Versionsnummer endlich richtig

Last, but not least: Microsoft hat die Versionsnummernausgabe in .NET Core 3.0 endlich korrekt implementiert. In .NET Core 1.x und 2.x antworteten die Properties System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription oder System.Environment.Version jeweils immer mit einer 4er-Nummer vorne. Nun bekommt der Entwickler die korrekte 3.0.0 zurückgeliefert. Das wir das noch erleben durften!

Fazit und Ausblick

Das klassische .NET Framework lebt in Windows weiter, wenn auch als Zombie (nicht ganz tot, nicht ganz lebendig). Mit .NET Core 3.0 kann man nun WPF- und Windows-Forms-Anwendungen auch auf .NET Core betreiben. Für neue Anwendungen sollte man diesen Weg auch unbedingt wählen.

Eine Migration bestehender Anwendungen von .NET Framework auf .NET ist nicht zwingend, denn die Umstellung kann aufwendig sein, da Werkzeuge und auch einige funktionale Bausteine noch fehlen. Gleichwohl hat der Beitrag aufgezeigt, dass sich eine Migration lohnen kann. Es gibt aber keinen Grund zur Eile. Die meisten Projekte können auf .NET Core 3.1 (November/Dezember 2019) oder .NET 5.0 (November 2020) warten, und manche Projekte, die man nur noch selten pflegt, wird man niemals auf .NET Core migrieren wollen.

In diesem Beitrag unbehandelt blieb ASP.NET Core Blazor, von dem es in .NET Core 3.0 mit der Blazor Server App einen ersten fertigen Teil gibt. Da es sich dabei um eine komplett neue Anwendungsart handelt, werden wir diesem Thema in der nächsten Ausgabe des Windows Developer einen eigenen Beitrag widmen.

Links & Literatur

  • [1] Schwichtenberg, Holger: „R. I. P. .NET ‚Core‘. .NET Framework, .NET Core und Mono sind tot – lang lebe .NET 5.0!“, in: Windows Developer 7.2019

Windows Developer

Windows DeveloperDieser Artikel ist im Windows Developer erschienen. Windows Developer informiert umfassend und herstellerneutral über neue Trends und Möglichkeiten der Software- und Systementwicklung rund um Microsoft-Technologien.

Natürlich können Sie den Windows Developer über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. Außerdem ist der Windows Developer weiterhin als Print-Magazin im Abonnement erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -