Befehle zur Laufzeit an eigenes Programm übermitteln?

  • VB.NET
  • .NET 4.0

Es gibt 21 Antworten in diesem Thema. Der letzte Beitrag () ist von RodFromGermany.

    Befehle zur Laufzeit an eigenes Programm übermitteln?

    Hallo,
    Ich entwickle gerade ein Plugin-System für meine Anwendung, und brauche eine Technik
    damit die Plugins mit der Hauptanwendung kommunizieren
    können.

    Kann man einem selbsterstellten Programm(prozess) zur Laufzeit Befehle übermitteln?

    Also z. B. :
    myapp.exe {backcolor=blue} (so ähnlich wie Kommandozeilenargumente beim Starten von Prozessen, nur zur Laufzeit)

    Dann könnte mein Programm, welches die Befehle empfängt, eine Art
    "Befehlsverzeichnis" enthalten, sodass es auf selbst festgelegte Befehle
    reagieren würde.

    Die Befehle zur Laufzeit direkt an den Prozess zu übergeben (falls das möglich ist)
    halte ich für besser, als globale Variablen für die Befehlübergabe zu definieren,
    weil sich das ganze leichter auf neue Projekte übertragen lässt und auch prozessunabhängig
    funktionieren würde (in diesem Fall müsste ja sonst mit Timern für die Abfrage gearbeitet werden.)

    Weiß jemand ob soetwas (oder etwas ähnliches) möglich ist? Oder gibt es Ideen?
    Visual Basic-Frager

    Das kommt ganz drauf an, was du erreichen willst. Willst du es mit einem eigenen Programm fernsteuern-> DLL.
    Ansonsten gibt es verschiedene Möglichkeiten zur IPC (danach kannst googlen). Z.b. kannst du den konsolen input auslesen
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Plugins als eigene Prozesse auszuführen, ist meist ein Designfehler. Normalerweise sind das DLLs, die geladen werden. Schau z. B. mal hier: Erstellen eines Plugin-Systems mit VB.NET und MEF ab .NET 3.5.
    Mit freundlichen Grüßen,
    Thunderbolt
    @VisualBasic-Frager Was genau willst Du?
    Ich sehe hier 2 disjunkte Problematiken.
    1. Plugin-System, da kannst Du kommunizieren was immer Du willst, so es implementiert ist,
    2. 2 eigenständige EXEn reden miteinander.
      Bidirektional: Gugst Du Sockets,
      monodirektional: Gugst Du hier.

    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!
    @RodFromGermany Named/UnnamedPipes sind für soetwas oftmals bereits optimiert und auch dafür gedacht. Und da die Kompatibilität mit >= Win XP reichen sollte hast du auch keine Nachteile dabei ;)
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    jvbsl schrieb:

    Named/UnnamedPipes
    Ups, da ist mir die falsche Buchstabenfolge in den Post-Editor geflossen. :whistling:
    @VisualBasic-Frager Sorry, selbstverständlich Pipes.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!
    @jvbsl: Danke für das Stichwort IPC, hab dadurch etwas gefunden, was funktioniert.
    @Thunderbold: ​Ich lade die Plugins auch zur Laufzeit aus DLLs, nur konnte ich
    zwischen dem Plugins und dem Hauptprogramm (beides der selbe Prozess :) ) keine
    Verbindung aufbauen.

    Das Problem habe ich dank IPC ja lösen können. Das Prinzip lässt sich auch auf andere
    Projekte mühelos übertragen :)
    Für andere: programmers-en.high-way.​info/vb/ipc.html
    Hier wird IPC gut beschrieben.

    Danke,
    VisualBasic-Frager

    Wenn du die DLLs lädst und dann innerhalb deiner Anwendung Interprocess Communication anwendest machst du gehörig was falsch. Hast du schonmal den Link besucht?

    Zur Erinnerung: Erstellen eines Plugin-Systems mit VB.NET und MEF ab .NET 3.5
    Mit freundlichen Grüßen,
    Thunderbolt
    @Vainamo V nur sehr begrenzt Möglich und eher zur Synchronisation(von Threads/Prozessen) gedacht als zur Kommunikation.
    @VisualBasic-Frager Vielleicht solltest du mal dein Problem anhand deines Projektes(oder ähnlicem) schildern, denn so wie es sich anhört wäre das alles Problemlos über direkte Kommunikation möglich, da DLLs nicht einmal einen eigenen Prozess benötigen/haben sollten. Und diese somit direkt Speicher(also Stack und Heap) und somit auch Speicher für den Code teilen. D.h. dieser kann aufgerufen werden, als wäre die DLL teil deines Projektes und nie getrennt gewesen.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Hallo,
    @jvbsl: Ich habe IPS ausprobiert, es würde halt funktionieren, nur sehr "unsauber".
    An eine direkte Kommunikation von Addon und Hauptanwendung hatte ich auch schon
    gedacht, aber wie ich das anstellen könnte weiß ich nicht genau.

    Ich brauche im Endeffekt ja Zugriff auf jedes Control und jede Methode von der
    Hauptanwendung vom Addon aus. Also das wäre die "Ideallösung" :)

    Weiß jemand wie das funktionieren könnte?

    Danke,
    VisualBasic-Frager

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VisualBasic-Frager“ ()

    Nein du brauchst eben nicht Zugriff auf jedes Control/usw. deiner Hauptanwendung. Wenn du auf etwas Zugriff hast, dann auf Daten deiner Hauptanwendung.
    Die Daten können dann, falls es nötig ist auch die GUI entsprechend anpassen. Ansonsten erstellt ein Plugin eigene Fenster bzw. stellt Daten zur Verfügung, aus welcher die Hauptanwendung einen Einstellungsdialog o.ä. macht.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    Hallo,
    nach langem Grübeln habe ich erkannt das sich die Theorie einfacher anhört,
    als es in meinem Fall ist. Das ich nur Daten "hin- und hiertransporieren"
    sollte, behalte ich dabei im Hinterkopf. Denn wennich zB einen String
    oder einen Integer übermittle, ist das kein Problem, weil beide Seiten
    wissen" was ein String/Integer ist. Ich habe aber eine Sammlung an
    eigenen Objekten, die auch voneinander erben
    (zB Objekt->Form->Kreis, Objekt->Seite, Objekt->Hintergrund)
    Damit die Hauptanwendung und die Addons meine Objekte "kennen",
    muss ich sie in eine extra DLL packen und beiden verlinken. Nun möchte
    ich (oder muss ich sogar) meine Objekte im Laufe der Programmierung meines
    Programms ändern. Wenn ich nun aber etwas an dieser Objektstruktur ändere,
    werden dann nicht alle Addons ungültig? Oder funktionieren sie weiterhin?
    (Ich ändere eine dem Interface verlinkte DLL)

    Und nochmal sorry das ich am Anfang so wenig von der (eigentlichen) Problematik
    gefragt habe, nächstes Mal frage ich genauer und mit mehr Bezug auf meine Projekte.

    VisualBasic-Frager

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VisualBasic-Frager“ ()

    VisualBasic-Frager schrieb:

    weil beide Seiten wissen" was ein String/Integer ist.
    Wenn sich das ändert, musst Du Dir eine entsprechende Syntax machen, die einen Start, einen Typ, bei Array die Anzahl der Werte und dann den Wert / die Werte sowie eien Ende-Kennung überträgt, sowas wie ein XML- oder JSon-Format.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!
    Was sollte sich den großartig ändern, außer während der Entwicklung selbst? Ein Kreis wird immer einen radius haben und das wird sich auch nie ändern.
    Und ja du kannst eine Basis DLL machen, die alle Typen enthält, die implementiert werden können, dann muss nicht zur kompletten Assembly gelinkt werden, außerdem ist dann das Linken in "beide" Richtungen möglich.
    Aber ich verstehe dein Problem nicht. erläutere das am besten mal mit explizitem Code.
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    VisualBasic-Frager schrieb:

    Wenn ich nun aber etwas an dieser Objektstruktur ändere,
    werden dann nicht alle Addons ungültig?
    Genau.

    Also man muss schon stichhaltige Gründe haben, warum man ausgerechnet was mit AddOns/PlugIns und dergleichen entwickeln will.

    In meinen Augen ist sowas erst sinnvoll, wenn die Hauptanwendung fertig ist, und es eine Gemeinde hochkompetenter User gibt.
    Dann kann man iwas coden, dass die Hauptanwendung eine API veröffentlicht, und die hochkompetenten User können iwelche Extras an die Anwendung dran-proggen, entweder für sich individuell oder auch OpenSource.
    Beispiele sinnvoller Plugin-Systeme wären etwa Firefox, oder auch die Woltlab-Forum-Software.

    Hingegen solange die Weiterentwicklung beim Hersteller verbleibt, bringt ein Plugin-System nichts als erhebliche Umständlichkeiten und Gefahren.
    @ErfinderDesRades PluginSystem zwingen einen oft zu einer guten Struktur, was etwas positives ist, außerdem hat eine Änderung am PluginSystem genau so viel Einfluss, wie eine Änderung in einem normalen Projekt, du musst entsprechende Codestellen ändern und solange die Entwicklung nur bei dir liegt ensteht bei einer Änderung kein Mehraufwand. Und wie viel Arbeit es ist von einem Projekt ohne PluginSystem zu refactorisieren und ein gescheites PluginSystem zu bauen wollen wir gar nicht anfangen, da kann man das Projekt meist neu schreiben(wenn man sich nicht bereits die entsprechende Architektur gebaut hat -> Dann wäre das PluginSystem sowieso keine Arbeit mehr).
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    also wenn ich irgendeinen Public Member einer Klasse änder, lösche oder zufüge - und sowas mach ich ständig - sagt mir die Fehlerliste im selben Moment, wo ich nachbessern muss. Mit Doppelklick drauf navigiere ich sofort dahin.
    Bei einem PlugInSystem meckert als erstes die KlassenDeklaration, weil dann das Interface nicht mehr stimmt. Dann muss ich das Interface aufsuchen - direkt zum Member hopfen geht da nicht, den Member ändern, und dann erst meckern andere Klassen, die dieses Interface implementieren. Und auch da ists bisserl mühsamer, die KlassenMember aufzufinden.

    Wie gesagt: bei ohne Interface navigiere ich direkt aus der Error-Liste.

    Zufügen ebenso: Einer Klasse füge ich was zu, und überall, wo die Klasse bekannt ist, kann ich das neue Feature nutzen.
    Mit Interface müsste ich dem das auch erst zufügen, und dann ist das neue Feature nicht mehr optional, sondern muss überall implementiert sein, und so Zeugs.

    nee - erzähl mir nicht, das wäre kein Mehr-Aufwand.

    ErfinderDesRades schrieb:

    Dann muss ich das Interface aufsuchen
    Dann musst Du eine gepflegte Projektmappe erstellen, wo alles drin ist.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!