© FLUTES/Shutterstock.com, © S&S Media
.NET Core 2.1, 2.2 und 3.0 bringen viele neue Funktionen

Der Schweizer Käse schließt Löcher


Bisher war .NET Core für viele Szenarien kein Thema, einfach weil die notwendigen Klassen fehlten. In .NET Core 2.1 hat Microsoft massiv in der Klassenbibliothek nachgerüstet. Mit .NET Core 3.0 kommen sogar WPF und Windows Forms nach .NET Core – aber nur für Windows. Was das im Detail bedeutet, wird im Folgenden erklärt.

Nachdem .NET Core 2.0 am 14. August 2017 erschienen war, hatte Microsoft die Version 2.1 für das erste Quartal 2018 angekündigt. Dass dieser Termin nicht zu halten sein wird, wurde dann im Februar 2018 verkündet und als neues Ziel der Sommer 2018 angegeben. Aus dem Sommer wurde dann der Frühsommer: .NET Core 2.1 und damit einhergehend ASP.NET Core 2.1 und Entity Framework 2.1 sind am 30. Mai 2018 erschienen.

Windows Compatibility Pack for .NET Core

Ein wesentliches Thema in den 2.1-Versionen ist die Erweiterung der Funktionen, insbesondere durch die Übernahme weiterer Klassen aus dem klassischen .NET Framework. Das Windows Compatibility Pack for .NET Core bringt viele Hundert Klassen aus der bisherigen .NET Framework Class Library als Nuget-Paket in die .NET-Core-Welt. Das Nuget-Paket Microsoft.Windows.Compatibility [1] ist ein Metapaket über viele andere Nuget-Pakete. Enthalten sind folgende Einzelpakete:

  • Microsoft.Win32.Registry (≥ 4.5.0)

  • Microsoft.Win32.Registry.AccessControl (≥ 4.5.0)

  • Microsoft.Win32.SystemEvents (≥ 4.5.0)

  • Microsoft.Windows.Compatibility.Shims (≥ 2.0.0)

  • System.CodeDom (≥ 4.5.0)

  • System.ComponentModel.Composition (≥ 4.5.0)

  • System.Configuration.ConfigurationManager (≥ 4.5.0)

  • System.Data.DataSetExtensions (≥ 4.5.0)

  • System.Data.Odbc (≥ 4.5.0)

  • System.Data.SqlClient (≥ 4.5.0)

  • System.Diagnostics.EventLog (≥ 4.5.0)

  • System.Diagnostics.PerformanceCounter (≥ 4.5.0)

  • System.DirectoryServices (≥ 4.5.0)

  • System.DirectoryServices.AccountManagement (≥ 4.5.0)

  • System.DirectoryServices.Protocols (≥ 4.5.0)

  • System.Drawing.Common (≥ 4.5.0)

  • System.IO.FileSystem.AccessControl (≥ 4.5.0)

  • System.IO.Packaging (≥ 4.5.0)

  • System.IO.Pipes.AccessControl (≥ 4.5.0)

  • System.IO.Ports (≥ 4.5.0)

  • System.Management (≥ 4.5.0)

  • System.Runtime.Caching (≥ 4.5.0)

  • System.Security.AccessControl (≥ 4.5.0)

  • System.Security.Cryptography.Cng (≥ 4.5.0)

  • System.Security.Cryptography.Pkcs (≥ 4.5.0)

  • System.Security.Cryptography.ProtectedData (≥ 4.5.0)

  • System.Security.Cryptography.Xml (≥ 4.5.0)

  • System.Security.Permissions (≥ 4.5.0)

  • System.Security.Principal.Windows (≥ 4.5.0)

  • System.ServiceModel.Duplex (≥ 4.4.1)

  • System.ServiceModel.Http (≥ 4.4.1)

  • System.ServiceModel.NetTcp (≥ 4.4.1)

  • System.ServiceModel.Primitives (≥ 4.4.1)

  • System.ServiceModel.Security (≥ 4.4.1)

  • System.ServiceModel.Syndication (≥ 4.5.0)

  • System.ServiceProcess.ServiceController (≥ 4.5.0)

  • System.Text.Encoding.CodePages (≥ 4.5.0)

  • System.Threading.AccessControl (≥ 4.5.0)

Die Paketnamen sind angelehnt an die bisherigen Namensräume aus der .NET Framework Class Library. Funktionen wie Registry-Zugriff, Datenbankzugriffe per ODBC, LINQ für DataSets, das Code Document Object Model (CodeDOM), Zugriff auf serielle Ports und LDAP-Server wie das Active Directory sowie die Windows Management Instrumentation (WMI), mit der man Informationen aus dem Betriebssystem und einigen Anwendungen auslesen und verändern kann, halten damit Einzug in die Welt von .NET Core. Freilich sind viele dieser Klassen nur auf Windows möglich, daher auch der Name „Windows“ im Compatibility Pack.

Man kann in jedem Fall eine Self-contained Application (Abb. 1) auch für Linux und macOS erstellen, auch wenn manche Klassen aus dem Windows Compatibility Pack, die für diese Betriebssysteme nicht von Microsoft implementiert wurden bzw. dort zum Teil keinen Sinn machen (z. B. die Registry-Klassen). Wenn man die Self-contained Application dann auf diesen Betriebssystemen startet, erhält man Laufzeitfehlermeldungen wie z. B.:

schwichtenberg_netcore3_1.tif_fmt1.jpgAbb. 1: Erstellen einer Self-contained App für Linux für eine Konsolenanwendung, die Linux verwendet
  • System.PlatformNotSupportedException: Windows Principal functionality is not supported on this platform.

  • System.TypeInitializationException: The type initializer for 'Microsoft.Win32.Registry' threw an exception. ---> System.PlatformNotSupportedException: Registry is not supported on this platform.

  • System.PlatformNotSupportedException: System.Management currently is only supported for Windows desktop applications.

Man sieht hier an den unterschiedlichen Fehlerklassen und Meldungstexten deutlich, dass verschiedene Entwickler am Werk waren. Einige Klassen aus dem Windows Compatibility Pack laufen auch außerhalb von Windows. Leider schweigt sich die offizielle Dokumentation [2] dazu aus; es gibt jedoch dazu einen Blogeintrag [3].

So läuft zum Beispiel System.Runtime.Caching problemlos unter Linux und macOS, denn diese Bibliothek hat keine Abhängigkeiten von Betriebssystemteilen. Im Einzelfall wird man dann aber feststellen, dass mehr notwendig ist, als das Windows Compatibility Pack in die Self-contained Application zu packen. So scheitert ein ODBC-Zugriff mit der .NET-Klasse System.Data.Odbc.OdbcConnection auf Linux auf einen Microsoft-SQL-Server mit dem Fehler „System.DllNotFoundException: Dependency unixODBC with minimum version 2.3.1 is required. Unable to load shared library 'libodbc.so.2' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibodbc.so.2.so: cannot open shared object file: No such file or directory”. Die Lösung ist, dass man erstmal den ODBC-Treiber für Microsoft-SQL-Server auf Linux installieren muss [4].

Auch für System.Drawing braucht man unter Linux und macOS eine Zusatzinstallation von libgdiplus, einer Open-Source-Implementierung des GDI+ API aus dem Mono-Projekt [5].

Mit dem NuGet-Paket Microsoft.DotNet.Analyzers.Compatibility [6] bietet Microsoft immerhin einen Visual-Studio-Analyzer an, der alle Klassen und Klassenmitglieder markiert, die nicht plattformneutral sind, siehe z. B. Registry.LocalMachine.OpenSubKey() in Abbildung 2. Auch auf veraltete APIs (z. B. System.Net.WebClient, System.Sec...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang