Laden...

[gelöst] Infos über .NET 5: Änderungen bei der Interoperabilität (Bericht auf heise.de)

Erstellt von pollito vor 3 Jahren Letzter Beitrag vor 3 Jahren 678 Views
pollito Themenstarter:in
314 Beiträge seit 2010
vor 3 Jahren
[gelöst] Infos über .NET 5: Änderungen bei der Interoperabilität (Bericht auf heise.de)

Hallo,

unter heise.de las ich u. a. folgende Passage:

Eine fundamentale Neuerung in .NET 5.0 ist die Möglichkeit, dass Entwickler nun .NET-Code direkt aus anderen Programmiersprachen auf nativem C/C++-Weg aufrufen können, was die meisten Programmiersprachen beherrschen. Somit sind .NET- 5.0-Module nun fast in beliebige Sprachen einbindbar.

Ich habe gestern vergeblich versucht, mehr Infos darüber zu bekommen. Vielleicht habe ich die falschen Suchbegriffe verwendet. Daher meine kurze Frage: Weiß jemand, wo ich Infos darüber bekomme?

Vielen dank und ein schönes Wochenende!

René

6.911 Beiträge seit 2009
vor 3 Jahren

Hallo pollito,

falschen Suchbegriffe

mit ".net 5 native exports" wirst du fündig.

Ganz trivial ist die Sache aber nicht, da die CLR selbst gehostet werden muss, anders kann JIT-kompilierter IL-Code auch nicht ausgeführt werden.
Die Pakete, die du finden wirst, machen das nicht anders, nur teilweise eben für dich.

Ich finde die zitierte Aussage vom Artikel ein wenig irreführend bzw. verspricht sie mehr als es ist.

Der "klassische Weg" mit nativen Anwendungen zu kommunizieren bleibt dass .NET eine native Bibliothek aufruft und der native Teil per Callback wieder in .NET zurückrufen kann.
Der Callback war bisher ein Delegate, das wird sich aber mit "function pointers" (von C# 9) ändern.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

pollito Themenstarter:in
314 Beiträge seit 2010
vor 3 Jahren

Danke! Das hilft mir weiter.

LG

René

6.911 Beiträge seit 2009
vor 3 Jahren

Hallo dannoe,

danke für den Link zum Artikel. Aber dieser ist wirklich schlecht recherchiert und suggiert dass es genügt UnmanagedCallersOnlyAttribute auf eine statische Methode zu setzen und gut ist es. Das ist bei Weitem nicht so (und der Autor sollte sich besser mit anderen Themen beschäftigen).

UnmanagedCallersOnlyAttribute teilt dem JIT mit, dass die so markierte Methode ausschließlich von nicht-verwaltetem Code (~ nativen Code) aufgerufen wird. Somit wird als "function pointer" (erwähnt auch in voriger Antwort) eine leichtgewichtigere Version erstellt, als wenn die Methode auch von managed Code aufgerufen werden würde.

Der wesentliche Hinweis zu Write a custom .NET Core host to control the .NET runtime from your native code fehlt im Artikel, denn somit sind die "native exports" möglich (aber auch schon vor .NET 5, ich glaube fast ab .NET Fx 1.0, also seit Beginn an nur wurde es "vereinfacht" und performanter gemacht).

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

6.911 Beiträge seit 2009
vor 3 Jahren

Hallo nochmal,

das muss ich noch ergänzen.

Aaron Robinson, der Autor dieses Features in .NET, hat https://github.com/AaronRobinsonMSFT/DNNE erstellt und baut auf dem Vorgenannten auf. Hier ist es möglich per UnmanagedCallersOnlyAttribute den nativen Export zu erzeugen, aber nicht in .NET 5 selbst.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

H
48 Beiträge seit 2020
vor 3 Jahren

bei heise kann man sehr schnell die qualität vom artikel anhand des autors erkennen und hier hätte ich nicht weiter gelesen