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.

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.

**.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.

@Abt
Das Egoismus-Argument ist - finde ich - eine Killerphrase, weil man dagegen praktisch nichts mehr einwenden kann.
Das Egoismus-Argument kommt auch beim Klimaschutz. Ich muss mir z.B. von manchen anhören, dass ich egoistisch bin, weil ich Fleisch esse, ein Auto mit Benzin-Motor fahre und unnötigerweise einen Hund halte, der eine schlechte CO²-Bilanz hat. Ich würde mit meinem Egoismus den zukünftigen Generationen die Lebensgrundlage entziehen.
Beim Rassismus ist es genauso. Es wird unterstellt, dass Menschen, die nicht weiss sind, leiden müssen und benachteiligt werden, weil ich so egoistisch bin.

Wenn wir diese Debatte führen, kommen wir irgendwann an den Punkt, wo man verbindlich festlegen muss, was noch okay ist und ab wann es widerlich egoistisch wird. Und dann ist die Frage, wer darüber entscheidet.

Ich habe intensiv darüber nachgedacht, warum es auch mir persönlich so schwer fällt, eine Umbenennung von master/slave einfach so zu akzeptieren.

Für mich fühlt sich das irgendwie erzwungen an.
Ich weiss, dass es gut gemeint und eigentlich auch richtig ist, aber dieses "Gute" wird irgendwie von außen "verordnet".
Bei anderen Themen habe ich das selbe Gefühl. Z.B. beim Essen, also die Fleisch / kein Fleisch Geschichte, beim Gendering oder bei allem was mit dem Thema Klima zu tun hat. Dieses "Aufgezwungene" erzeugt bei mir den Widerstand (oder ist es Trotz?) dagegen.

Es fühlt sich für mich teilweise an, wie im Film "Demolition Man".

Hallo Stefan,

im DuplexChannel, der unter der Haube verwendet wird, ist leider kein Timeout definiert. Deshalb bietet auch das entsprechende ProtocolSetup keine Property dafür an.

Man müsste in die Zyan.Communication.Protocols.Tcp.DuplexChannel.Connection-Klasse einen einstellbaren Timeout einbauen. In dieser Klasse wird der Socket erzeugt, über den die Netzwerkkommunikation läuft. Die Socket-Klasse hat die Eigenschaften SendTimeout und ReceiveTimeout. Die müssen praktisch nur "durchgeschleift" werden.

Ich kann das gerne einbauen. Kann aber ein paar Tage dauern, bis ich dazu komme.

Beste Grüße
Rainbird

Hallo Stefan,

welches Protocol Binding verwendest Du?

Beste Grüße
Rainbird

Hallo GigaMann,

das geht auch mit Katana. Das ist die Microsoft-Implementierung der OWIN-Schnittstelle.
Damit kann man sich einen eigenen Webserver basteln.

schau mal hier:
ASP.NET self hosting mit Katana

Gruß
Rainbird

Hallo nickname8,

Dokumentation zu Zyan findest Du hier: Zyan Dokumentation (deutsch)

Code-Beispiele findest Du hier: Codeplex: Zyan Code-Beispiele (Examples)

Nun zu Deinem Probelm. Sowohl Tasse als auch Schrank sind auf einem Zyan-Server veröffentlichte Remote-Komponenten. Du versuchst, einen clientseitigen Verweis auf die entfernte Komponente Tasse an die entfernte Komponente Schrank zu übergeben. Das wird so nicht unterstützt.

Zyan trennt strikt zwischen Client und Server. Der Server bietet Funktionalität an, der Client konsumiert sie. Wenn Client und Server Daten austauschen, dann muss dies über Typen gemacht werden, die serialisierbar sind (Also alle Typen, die ISerializable implementieren oder mit [Serializable] gekennzeichnet sind, und primitive Typen wie int, string, byte, etc.)

Es gibt deshalb grundsätzlich zwei Kategorien von Klassen:*Komponenten, die Funktionalität anbieten *Datenklassen, welche zum verseden von Daten übers Netzwerk eingesetzt werden

Damit Dein Beispiel funktioniert, müsste Tasse eine serialisierbare Datenklasse sein und NICHT als Remote-Komponente am Zyan-Server veröffentlicht werden. Es könnte z.B. eine Komponente "TassenFabrik" geben, welche Tassen produziert und die fertigen Tassen als Datenklassen zurückgibt. Die kann man dann mit proxySchrank.StelleRein(datenTasse) auch an den entfernten Schrank schicken.

Hallo Stefan,

klingt so, als würde ein asynchroner Callback vom Zyan Server versuchen auf GUI Objekte zuzugreifen. Zugriffe auf GUI Objekte dürfen nur im GUI Thread erfolgen. Du musst im Callback auf den GUI Thread umleiten. Unter Windows.Forms ist dafür Invoke/InvokeRequired das Stichwort. In WPF gibt es auch etwas Vergleichbares, weiss es nur gerade nicht auswendig.

Gruß Rainbird