Native Interoperabilität in der fünften Vorschauversion von .NET 5.0

Microsoft öffnet .NET 5.0 weiter für den Aufruf durch andere Programmiersprachen. Auch JIT-Compiler und OR-Mapper erhalten weitere Verbesserungen.

Lesezeit: 3 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 5 Beiträge

(Bild: Ken Wolter/Shutterstock.com)

Von
  • Dr. Holger Schwichtenberg

Vier Wochen nach seiner Build-Konferenz 2020 und der dort erschienenen vierten Preview liefert Microsoft weitere Verbesserungen für .NET 5.0.

Eine fundamentale Neuerung in .NET 5.0 Preview 5 ist die Möglichkeit, dass Entwickler nun .NET-Methoden direkt aus anderen Programmiersprachen auf nativem C-/C++-Weg aufrufen können – eine Variante dieses Wegs beherrschen die meisten Programmiersprachen. Dazu markieren .NET-Softwareentwickler eine statische Methode in einer .NET-Klasse mit der neuen Annotation UnmanagedCallersOnlyAttribute. Dabei stehen fünf Aufrufkonventionen zur Auswahl: WinAPI, Cdecl, StdCall, ThisCall und FastCall. Die Methodenparametertypen sind allerdings begrenzt auf sogenannte "Blittable Types" – darunter Ganzzahlen (Byte, Int, Long), Fließkommazahlen (Single und Double) sowie Zeiger. "Blittable" ist offenbar ein Kunstwort, das sich von der Kurzform "bit blit" für eine Speicheroperation vom Typ Block Transfer ableitet.

Seit .NET Framework 1.0 ist Interoperabilität zu anderen Programmiersprachen über das Component Object Model (COM) möglich. Dazu können sich .NET-Entwickler einen COM Callable Wrapper (CCW) für .NET-Klassen mit der Annotation ComVisible erzeugen. Das COM-basierte Verfahren funktioniert im klassischen .NET Framework (ab Version 1.0) sowie in .NET Core (ab Version 3.0), ist allerdings auf Windows und Programmiersprachen mit COM-Unterstützung beschränkt.

Das neue native Interoperabilitätsverfahren hingegen funktioniert auf allen .NET-Core-Plattformen (Windows, Linux und macOS) und mit deutlich mehr Programmiersprachen. Allerdings gibt es auch bisher schon Zusatzprojekte zu .NET, die native Interoperabilität auch mit älteren .NET-Versionen ermöglichen, wie beispielsweise Unmanaged Exports und DllExport. Darüber hinaus gibt es noch den von Microsoft-Entwickler Aaron Robinson für .NET 5.0 entworfenen Ansatz .NET Native Exports.

Mit Blick auf die kommende sechste Vorschauversion von .NET 5.0 hat Microsoft zudem weitere Arbeiten im Bereich der Interoperabilität angekündigt. So soll die eingebaute Unterstützung für den Aufruf von Windows-Runtime-(WinRT)-Bibliotheken entfallen. Ein neuer Code-Generator C#/WinRT soll sie ersetzen. Statt der Referenzierung von .winmd-Dateien müssen Softwareentwickler, die WinRT nutzen, dann das NuGet-Wrapper-Paket für WinRT "Windows SDK .NET Package" auf NuGet.org einbinden, das einen Runtime Callable Wrapper (RCW) für die WinRT-APIs bereitstellt.

Während die Interoperabilität zu WinRT im .NET Framework schon seit dessen Erstvorstellung im Jahr 2011 besteht, findet sie sich in .NET Core erst seit Version 3.0 vom September 2019. Vom neuen Verfahren profitiert primär Microsoft selbst: das Unternehmen konnte dadurch rund 60.000 Zeilen Programmcode aus der .NET Core Runtime entfernen. Die WinRT-Interoperabilität soll nun getrennt und in gleicher Weise wie die Integration der APIs von Android und iOS weiterentwickelt werden. Sie ist ein Baustein der angekündigten Vereinheitlichung der drei .NET-Varianten (.NET Framework, .NET Core, Mono/Xamarin) zu "One .NET". Mit einer ersten Version des einheitlichen .NET ist laut Ankündigung auf der Build-Konferenz nicht vor November 2021 in .NET 6.0 zu rechnen.

Neben den Änderungen bei der Interoperabilität verspricht Microsoft abermals eine Reihe von Leistungsverbesserungen im Just-In-Time-Compiler "RyuJIT" in .NET 5.0 Preview 5. Der Blogeintrag verlinkt zu den einzelnen GitHub-Issues.

Die Bibliothek System.DirectoryServices.Protocols, die das Lightweight Directory Access Protocol (LDAP) Version 3.0 und die Directory Services Markup Language (DSML) Version 2.0, realisiert, läuft nun auch auf Linux. Unterstützung für das Betriebssystem macOS soll in Preview 6 folgen.

Das Webframework ASP.NET Core 5.0 Preview 5 bietet als einzige neue Funktion, dass der in das Framework integrierte Webserver "Kestrel" nun auf Konfigurationsänderungen reagieren kann, ohne den Webserverprozess neu zu starten. Anders als im Blogeintrag ist diese neue Funktion auf GitHub aber noch als offener Punkt für Preview 7 gelistet.

In Entity Framework Core 5.0 Preview 5 können Datenbankzugriffsentwickler nun beim Forward Engineering von Datenbanken schon im Programmcode der Kontextklasse die Database Collation für Sortierungen und Vergleiche festlegen, beispielsweise mit modelBuilder.UseCollation("German_PhoneBook_CI_AS"). Auch beim Reverse Engineering berücksichtigt der Codegenerator die eingestellte Collation. Zur Ausführungszeit des Programms können Entwickler in LINQ-Abfragen vom Standard abweichende Vergleichsarten mit EF.Functions.Collate() verwenden, was aber die Abfragegeschwindigkeit negativ beeinflusst.

Für berechnete Datenbankspalten, die Entwickler bisher schon über HasComputedColumnSql() festlegen konnten, existiert nun der Zusatzparameter "stored" mit dem sich die Datenbank anweisen lässt, berechnete Werte nicht Ad-hoc zu berechnen, sondern zu persistieren, sofern das Datenbankmanagementsystem diese Speicherung unterstützt.

Mit dem Zusatz PerformIdentityResolution() für No-Tracking-Queries (deklariert mit dem Aufruf AsNoTracking()) können Entwickler nun Duplikate in der Ergebnismenge aussortieren, was bei normalen Tracking-Abfragen automatisch passiert. Beim Forward Engineering lassen sich Parameter der Kommandozeilenbefehle nun zur Kontextklasse durchreichen.

Zur Verbesserung der Transparenz der Entwicklung von .NET 5.0 veröffentlicht Microsoft auf GitHub nun sogenannte ".NET 5.0 Runtime Epics". Microsoft-Blog-Autor Richard Langer allerdings betont, dass es selbst ihm als Program Manager bei Microsoft schwer fällt, in den GitHub-Issues zu verfolgen, welche Neuerungen es in den Vorschauversionen gibt. Ein "Epic" ist dabei eine größere Neuerung, die aus mehreren Features bestehen kann.

Langer gibt aber auch zu, dass ".NET 5.0 Runtime Epics" nicht vollständig alle neuen Funktionen verlinken. Interessant ist, dass man bei den Epics das Thema "Ahead-of-Time"-Kompilierung (AOT) nicht findet. Die im Mai 2019 für .NET 5.0 angekündigte Ausdehnung von AOT auf alle .NET-Anwendungsarten scheint nun endgültig für dieses Jahr gestrichen zu sein. AOT gibt es bisher nur für .NET-Anwendung, die auf der Universal Windows Platform (UWP) und Xamarin für iOS laufen. Dazu passt die Aussage "We will continue evolving the native AOT as an experimental project" im GitHub-Eintrag ".NET Runtime Form Factors".

Die Preview 5-Version mit der internen Versionsnummer 5.20278 steht kosten- und registrierungsfrei in den Varianten .NET Runtime, ASP.NET Core Runtime, Desktop Runtime und SDK zum Download bereit. Die stabile Version soll am 10. November 2020 im Rahmen der virtuellen Konferenz ".NET Conf 2020" erscheinen.

(map)