Interprocess Kommunikation unter .NET ähnlich Win32 und DDE

Hallo. Ich suche Möglichkeiten um mit einem Prozess den ich aus einer Anwendung herraus gestartet habe, zu kommunizieren. Dabei soll die bidirektionale Kommunikation sehr einfach gehalten sein, ähnlich wie das früher mit DDE funktionierte. Hat jemand eine Anfang für mich, einen Namespace oder eine Klasse in der ich dann weitermache? Am besten wäre natülich wenn ich Funktionen in dem anderen Prozess steuern könnte, aber das wäre nur das Sahnehäubchen. 😉

Hallo tomaten,

Remoting/NamedPipe/WindowMessages (und dde geht natürlich weiterhin).

herbivore

Original von herbivore
Hallo tomaten,

Remoting/NamedPipe/WindowMessages (und dde geht natürlich weiterhin).

herbivore

Hallo. Schonmal danke. Das gute alte DDE war ja schon unter Win32 nur noch eine Notlösung und WindowsMessages sind doch zu einfach 😉 . Dann will ich mir mal die beiden anderen Teile ansehen. Ist schon wieder ein Chaos - Prozess starten "System.Diagnostics" - Prozess steuern "System.Remoting". 🙂

@herbivore

Habe mir das mal angesehen, aber das ist ja wie mit Atomraketen auf Spatzen geschossen. Gibt es denn nirgends einfachstes .NET Beispiel von 2 Mini Exen wo die eine "Hallo Du da" schickt und die andere synchron "Selber Du" o.ä. antwortet. Das kann doch nicht mit 200 Zeilen Code pro Seite verbunden sein? Da hab ich ja schneller nen HTTP-Server eingebaut und die Kommunikation gemacht. 🙁 Nur gehen mir da so viele Ports verloren.

Hallo tomaten,

in Dateiassoziation gibt es die gewünschten Codebeispiele (jedenfalls sind die ziemlich nah dran).

herbivore

Das macht doch schon mal einen schlanken Eindruck. Jetzt muss man das nur doch Synchron hinbekommen oder gibt es ein Beispiel wie ich beim Senden gleich eine Antwort bekomme?

Hallo tomaten,

ich würde denken, dass die Remote-Methoden auch einen Rückgabewert haben dürfen.

herbivore

Original von herbivore
Hallo tomaten,

ich würde denken, dass die Remote-Methoden auch einen Rückgabewert haben dürfen.

herbivore

Ist mir auch direkt nach dem schreiben des Post aufgefallen. 😉 Aber wer denkt schon so einfach, wenn er sich das erste mal mit .NET Remoting befasst. 🙂

Dank Deines Beispiel bin ich fast fertig. Habe nur eine Änderung gemacht, da ich verschieden Remoteobjekte gleichen Types aber unterschiedlicher Url habe/brauche:

...
        else
        {
            //-----------------------------------------------------------------------
            // Als weitere Instanz erzeugen wir den Client-Part
            //-----------------------------------------------------------------------
            /*RemotingConfiguration.RegisterWellKnownClientType(
               typeof(ArgsReceiver),
               strURLClient
            );*/

            //-----------------------------------------------------------------------
            // Und senden die Argumente an den Server/Service-Part
            //-----------------------------------------------------------------------
            ArgsReceiver argrecv = (ArgsReceiver)Activator.GetObject(typeof(ArgsReceiver), strURLClient);
            argrecv.SetNewArgs(astrArg);
        }
...

Im .NET Framework 2.0 steht Dir bei Remoting auch ein Kanal für lokale Interprozeßkommunikation (Named Pipes) zur verfügung (IpcChannel). Der funktioniert aber nur, wenn alle beteiligten Prozesse auf der selben Maschine laufen. Dafür ist er sehr schnell, da alles direkt im Hauptspeicher abgewickelt wird.

Hallo Rainbird,

ja, Marcel hat ja auch im o.g. Thread später ein Beispiel mit IpcChanel/NamedPipes angehängt (siehe Dateiassoziation). Als ich das Programm geschrieben hatte, war noch 1.1 aktuell. 🙂

herbivore

Ich habe mir gleich die Version mit IcpChannel rausgepickt. 😉

cdr hat doch da auch mal was tolles gebaut

http://www.cdrnet.ch/xt/products.asp#threadmsg

Original von Programmierhans
cdr hat doch da auch mal was tolles gebaut

>

Ja das ist gut, ich muss doch glatt mal testen ob es nicht reicht, wenn ich anstelle eines neuen Prozess einen Thread für mein Objekt verwende, dass nur einmal pro Prozess/Thread(?) erzeugt werden kann. Ich hatte mich bisher immer nur gefragt, wie ich mit dem Thread kommuniziere, aber auch das Problem hat sich dank der IPC-Hilfe hier damit geklärt. 🙂 Das Ganze ist der Fortsetzungskrimi dieses Thread:

Horror-Scenario

Jetzt hab ich noch ein anderes Problem. Da die Kommunikation von einer ASP.NET Anwendung zur einer Anwendung stattfindet die unter einem anderen Benutzer läuft, muss ich noch Security Informationen an der ServerChannel übergeben:

Dictionary<string, string> props = new Dictionary<string, string>();
props.Add("authorizedGroup", "Jeder"); // hier ist das Problem
props.Add("portName", strUniquePortName);
ChannelServices.RegisterChannel(new IpcChannel(props, null, null), false);

Dabei habe ich ein Problem mit der Gruppe "Jeder" die ja bekannterweise in englischen Windowsversionen "Everyone" heisst. Kann man den Namen auf dem aktuellen OS irgendwie elegant ermitteln? Ich kann ja das Programm nicht für jedes OS neu kompilieren! 😉 🙁

Das hier dürfte Dir weiterhelfen:

http://www.microsoft.com/germany/msdn/library/security/IntegrationInWindowsSecurityMitNET20Teil1.mspx

Original von Rainbird
Das hier dürfte Dir weiterhelfen:

>

Hallo und Danke. Der Tipp war erstmal gut, aber anscheinend kann man von jedem blöden Benutzer die SID herausfinden, aber den entsprechenden Namen zu ermitteln scheint unmöglich! 🤔

Nachtrag:

Nach vielen Nerven hab ich es nun doch gefunden:

SecurityIdentifier everyoneSid = new SecurityIdentifier(WellKnownSidType.WorldSid, null);
NTAccount Account = (NTAccount)everyoneSid.Translate(typeof(NTAccount));
MessageBox.Show(Account.Value);