Laden...

Projektvorstellung: CoreRemoting

Erstellt von Rainbird vor 2 Jahren Letzter Beitrag vor einem Jahr 1.778 Views
Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor 2 Jahren
Projektvorstellung: CoreRemoting

**.NET Remoting **ist leider nicht mehr in .NET Core bzw. .NET 5 enthalten.
Microsoft verweist auf gRPC und WebAPI als Alternative.

Wer eine größere Codebasis hat, die auf .NET Remoting aufgebaut ist, für den bedeutet das trotzdem große Teile der Applikation komplett neu zu schreiben,
wenn die Anwendung auf .NET 5 zum Laufen gebracht werden soll.

Für solche Migrationsszenarien und auch für alle, die vom Solgan "Embrace HTTP" nicht ganz so begeistert sind, möchte ich mit dem neuen Projekt CoreRemoting eine Alternative anbieten. CoreRemoting ist kein 1:1 .NET Remoting-Nachbau und auch vom Netzwerkprotokoll her nicht binär-kompatibel, aber die API ist so ähnlich, dass sich Client/Server-Anwendung mit geringem Aufwand migrieren lassen.
Da CoreRemoting mit moderner Technologie und nach modernen Entwurfsmustern gebaut ist, eignet es sich natürlich auch für neue Projekte und nicht nur für Migrationsszenarien. Allerdings nur in reinen .NET-Anwendungen. CoreRemoting ist für möglichst komfortable entfernte Methodenaufrufe von .NET zu .NET. Man kann damit keine REST-Server für Javascript-Clients bauen. Wer das möchte, sollte lieber WebAPI verwenden. In Blazor Server-Anwendungen funktioniert CoreRemoting aber auch (falls man doch einmal einen Webclient braucht).

CoreRemoting wird als .NET Standard 2.0 Assembly kompiliert und lässt sich deshalb sowohl in .NET Framework 4.x als auch in .NET Core / .NET 5 Umgebungen gleichermaßen nutzen. Es läuft auf jeden Fall unter Windows und Linux. Mac sollte auch gehen, aber da ich selbst keinen Mac habe, konnte ich es da leider noch nicht testen.
Die Netzwerkkommunikation läuft über Websockets.
Für die nötige Sicherheit der Netzwerkaufrufe sorgt die integrierte Verschlüsselung und Nachrichtensignierung mit RSA und AES.
Eine Authentifizierungsschrittstelle ist ebenfalls eingebaut.
Für Authentifizierung mit Benutzername und Passwort gegen lokale Betriebssystembenutzer (Windows / Linux wird automatisch erkannt) gibt es bereits einen fertigen Authentifizierungsanbieter: https://www.nuget.org/packages/CoreRemoting.Authentication.GenericOsAuthProvider/
Zur Serialisierung der Aufrufe kommt standardmäßig BSON (Binary JSON) zum Einsatz. Alternativ kann auch der klassische BinaryFormatter verwendet werden, um die größt mögliche Kompatibilität zum klassischen .NET Remoting zu erreichen.

Netzwerktransportschicht, Serialisierer und Authentifizierung sind austauschbar (auch gegen Eigenkreationen).

Der Quellcode steht unter MIT Lizenz und ist auf GitHub verfügbar: https://github.com/theRainbird/CoreRemoting
Ein NuGet-Paket gibt es natürlich auch: https://www.nuget.org/packages/CoreRemoting/

Quellcode für eine einfache Hello World-Client/Server-Anwendung findet ihr hier: https://github.com/theRainbird/CoreRemoting/tree/master/Examples/HelloWorld

Eine Dokumentation und einen Migrations-Guide für .NET Remoting bin ich gerade am schreiben: theRainbird/CoreRemoting

Die Migration kann man sich aber bereits jetzt in Form einer kleinen Beispielanwendung ansehen, welche im Original mit .NET Remoting implementiert ist und in einer zweiten Version auf CoreRemoting migriert wurde: theRainbird/CoreRemoting

Ich hoffe das Projekt ist für den einen oder anderen nützlich und beschert vielleicht einem altgedienten .NET Remoting Projekt ein zweites Leben unter .NET 5.
Falls ihr Bugs findet, meldet diese bitte über die GitHUb-Projektseite direkt: theRainbird/CoreRemoting
Viel Spaß mit CoreRemoting.

G
2 Beiträge seit 2020
vor 2 Jahren

Im Beispiel sieht man gar nichts von MarshalByRefObject. Wie kann das sein? 😁

Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor 2 Jahren

Bei CoreRemoting bestimmt nicht die Abstammung einer Klasse, ob sie aus der Ferne aufrufbar ist.
Stattdessen werden Klassen serverseitig als Services registriert.
Einzige Voraussetzung dafür ist, dass sie eine Schnittstelle implementieren, welche in einer gemeinsamen Assembly definiert ist, welche sowohl dem Server als auch dem Client bekannt ist.

O
2 Beiträge seit 2022
vor 2 Jahren

Ist es denkbar das mit CoreRemoting folgendes Szenarion bewerkstelltigt werden könnte:
https://ikriv.com/dev/wpf/BaktunShell/

Hier wird in einem anderen Prozess ein UserControl instanziert welches dann über .net remoting über das INativeHandleContract-Interface an den aufrufenden Prozess zurückgeliefert wird.


class NativeHandleContractInsulator : MarshalByRefObject, INativeHandleContract
   {
      private readonly INativeHandleContract _source;

      public NativeHandleContractInsulator(INativeHandleContract source)
      {
         _source = source;
      }

      .....

}

Könnte das mit CoreRemoting auch funktionieren?

Rainbird Themenstarter:in
3.728 Beiträge seit 2005
vor einem Jahr

Hallo obi111,

ja grundsätzlich schon. Das UserControl im anderen Prozess würde dann via CoreRemoting ferngesteuert.
Der ferngesteuerte Prozess (in dem das UserControl eigentlich lebt) wäre der Server, der andere Prozess der Client.
CoreRemoting kommuniziert standardmäßig über Websockets.
Das heißt, dass der Server-Prozess einen festen TCP-Port belegt.

Auf einem normalen Windows PC sollte das kein Problem sein.
Auf einer Remotedesktopserver (RDS) sieht das allerdings anders aus.
Da würden ja dann mehrere Instanzen der Prozesse laufen (1 pro User, der die Anwendung geöffnet hat). Jeder Instanz des Servers brauchte einen eigenen TCP-Port.

Auf einem RDS Server würde es deshalb nicht funktionieren.

Es sei denn, man implementiert einen CoreRemoting-Kommunikationskanal, der keine TCP-Ports braucht.
Also eine zusätzliche Implementierung für IServerChannel und IClientChannel schreiben. Z.B. mit dem Named Pipes-Protokoll.

O
2 Beiträge seit 2022
vor einem Jahr

Leider gibt es immer eine Sendefehler (An error occured while Sending data) ... die Schnittstelle des Service ist:

INativeHandleContract LoadPlugin(pluginSettings);

Die Verbindung zum RemoteServer wird erfolgreich aufgebaut ... ich denke INativeHandleContract (System.AddIn) wird einfach nicht unterstützt da nicht serialisierbar?