App "fernstarten"

[TheBigW]

Also doch: Einen kleinen Exe - Server, mit dem ich die App, die ich eigentlich will starte.

Erstmal Danke euch allen, so wirds wohl werden.

Das Hauptproblem ist das unterschiedliche Verhalte der App zu realisieren, wenn sie nun an den Client bindet oder alleine arbeiten soll. Um also für definierte Ausgangszustände zu sorgen, ist es das Einfachste einfach alle laufenden Server "abzuschießen" und dann sauber neu zu starten, sobald der Client an Bord kommt.

[-King-]

Also doch: Einen kleinen Exe - Server, mit dem ich die App, die ich eigentlich will starte.

Das versteh ich nicht so ganz. Ich versteh aber auch nicht, warum Du RPC direkt verwendest. Erstelle doch einfach einen DCOM-Exe Server und gut ist's. Wenn Du über die Kommandozeile den switch /Embedding bekommst, registrierst Du Dein Klassenobjekt (CoRegisterClassObject). Ansonsten ist eben der Client verlangt und Du startest das UI.

Oder hast Du in Deinem Buch bisher nur das RPC-Kapitel gelesen? Scheidet DCOM deswegen aus?

@RenéG
Du kannst die Dlls auch in einem Surrogat-Process anlegen, damit laufen sie dann auch Out-Of-Process. Du kannst dann sogar Interfaces von Remote anfordern.

[TheBigW]

Oder hast Du in Deinem Buch bisher nur das RPC-Kapitel gelesen? Scheidet DCOM deswegen aus?

DCOM scheidet aus, weil:

a)
nach meinem derzeitigen Kenntnisstand dann immer eine DLL oder OCX benötigt wird, was zusätzlich mit eingebunden wird (zusätzliches Projekt zu ohnehin schon Client, Server App).
Einmal registrierte Interfaces nicht mal eben verändert werden können -> siehe

b)
DCOM für mich Neuland ist, was ich so "learning by doing" in eine bestehende Software einpflege -> deshalb sind mir die starren Interface Registrierungen bei DCOM zu gruselig.

c)
Alle Beispiele zu DCOM ohne reines RPC für mich eher kompliziert gewirkt haben (z.B. bei Codeproject) und in dem Buch das das einzige Beispiel zu DCOM überhaupt war. Informationen zu dieser Thematik sind allgemein recht dünn gesäht (oder ich hab falsch gesucht..).

Ich lasse mich gerne vom Gegenteil überzeugen und bin für interessante Informationsquellen stets zu haben. Für dieses Projekt ist der "point of no return" leider schon vorbei -> da muß ich jetzt wohl durch.

[-King-]

nach meinem derzeitigen Kenntnisstand dann immer eine DLL oder OCX benötigt wird,

Ein ActiveX-Control wird garantiert nicht benötigt, nur die extra Dll. Aber wenn Du beim Entwurf der Schnittstellen ein wenig auf die Datentypen achtest, kannst Du die Dlls des Systems verwenden (TypeLib-Marshalling, steht alles in Deinem Buch).

DCOM für mich Neuland ist

Aber dafür hast Du doch nun ein schlaues Buch.

Alle Beispiele zu DCOM ohne reines RPC für mich eher kompliziert gewirkt haben

Das kann ich nun gar nicht nachvollziehen. Im besten Falle bekommst Du noch nichtmal mit, wo sich der Server befindet (Inproc, Local-Out-Of-Process, Remote). Du rufst lediglich die Methoden der Schnittstelle auf. Nichts weiter.

Ich lasse mich gerne vom Gegenteil überzeugen und bin für interessante Informationsquellen stets zu haben.

Du hast doch ein gutes Buch. Da steht alles gut und einfach beschrieben drin.

[:-)]

Welches Buch hat er denn?

[TheBigW]

@<:-)> : Das steht alles oben im Link :p -> "Inside Distributed COM"

@-King-

das stimmt wohl. Ich hatte vorne angefangen, hab dann die Mitte übersprungen und bin somit am Ende des Buches bei RPCs rausgekomen.
Womit wieder bewiesen wäre: "Wenn man denkt man spart Zeit, spart man am Ende meist gar nichts...."

Danke auch allen

[WebFurzi light]

Da sich eine DLL oder OCX nicht automatisch starten, sondern nur an Prozesse binden kann, musst Du schon einen EXE-Server erstellen.

Das ist natürlich absoluter Blödsinn! Wohl keine Ahnung was?

[RenéG]

ja

[RenéG]

@King

Du kannst die Dlls auch in einem Surrogat-Process anlegen,

Ist ein Surrogat-Prozess kein Prozess?

Ich habe meine fernaktivierbaren COM-Server bisher mit der ATL erstellt, 5 Mausklicks, danach noch ein COM-Objekt erstellen mit ClassFactory und Interface, und das wars schon. Funktionierte bisher ohne Probleme. Da muss ich mich nicht mit Surrogat-Prozessen auseinandersetzen, sondern komme schnell zum Ziel, und das war es doch, was TheBigW will.

[-King-]

Ist ein Surrogat-Prozess kein Prozess?

Doch, sicher. Trotzdem muß ich keinen EXE-Server erstellen. Wenn die Dll entsprechend registriert ist, funktioniert sie eben auch Remote.

Ich habe meine fernaktivierbaren COM-Server bisher mit der ATL erstellt, 5 Mausklicks, danach noch ein COM-Objekt erstellen mit ClassFactory und Interface, und das wars schon. Funktionierte bisher ohne Probleme.

TheBigW verwendet den VC/ATL? Das wusste ich nicht.

Da muss ich mich nicht mit Surrogat-Prozessen auseinandersetzen, sondern komme schnell zum Ziel, und das war es doch, was TheBigW will.

Damit muß ich mich auch nicht auseinandersetzen. Es reicht, wie gesagt, daß die Dll entsprechend registriert ist.

BTW: Ich erstelle normalerweise ebenfalls EXE-Server für solche Sachen. Nur ist es falsch zu behaupten, daß man das muss.