Laden...

COM DLL mit GUI für ein Drittsystem

Erstellt von BlackEye vor 9 Jahren Letzter Beitrag vor 9 Jahren 2.446 Views
B
BlackEye Themenstarter:in
5 Beiträge seit 2014
vor 9 Jahren
COM DLL mit GUI für ein Drittsystem

Hallo liebe Community,

meine Kenntnisse in c# beschränken sich bisher auf den reinen Standalone-Bereich.
DLLs habe ich bisher nur C geschrieben. Also reine als

extern "C" __declspec(dllexport) void fooBar();

gekennzeichnete Funktionen ohne GUI, welche in einer anderen von uns programmierten Umgebung eingebunden werden. Funktioniert bisher bestens.

Nun muss ich für ein Drittsystem eine "COM DLL" entwickeln, welche dort für unsere Belange eine Erweiterung bringen soll. Das Drittsystem kommt von einem anderen Lieferanten und ist AFAIK in Visual Basic geschrieben. Die Erweiterung ist auch nur eine ganz simple Angelegenheit. Quasi soll ich nur eine Oberfläche darstellen, die der Benutzer aufüllen kann und aufgrund der entsprechenden Auswahl des Benutzers dann eine Zahl zurück liefert. Das war es auch schon. Für jemand der sich mit der ganzen Thematik auskennt in ein paar Stunden aus dem Ärmel geschüttelt.
Für mich allerdings ergeben sich hier nun mehrere neue Themengebiete in die ich mich erst mühsam einarbeiten muss. Ich erhoffe mir hier auch nur einen kleinen Input, der mir das Gros der Sucherei, Austesterei und in die Fettnäpfchentreterei vielleicht ersparen kann.

Wie man eine COM-DLL mit c# entwickelt weiß ich eigentlich schon - hoffe ich zumindest =)
->
Ich erstelle einfach eine Klassenbibliothek mit Visual Studio, schaffe mir ein Interface für die zu exportierende Klasse mit seiner einzigen Methode und kennzeichne das Interface mit einem GUID und ComVisible Attribut. Dasselbe mache ich dann nochmal für die Klasse, welche dieses Interface implementiert. Dann stelle ich im Projekt für das Assembly noch ein: "Assembly COM-sichtbar machen" und das sollte es dann auch schon im Groben gewesen sein.
Solch eine erstellte DLL müsste doch jetzt als COM DLL einsetzbar sein oder? Dann wäre hier noch die Frage zu klären, ob der Verwender dieser DLL das .NET Framework installiert haben muss oder nicht. Ich vermute aber mal schon.

Nun die noch wichtigere Frage.
Bei meinen bisherigen GUI-Anwendungen die ich in C# geschrieben habe steht exemplarisch so etwas in der Main-Methode:

Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new MainPanel());

Damit startet das Programm durch Darstellung des Haupt-Frames. Mit Application.Run() wird quasi die GUI-Verarbeitung gestartet. Muss ich dieses Vorgehen dann ebenfalls in der DLL realisieren? Die Master-Anwendung welche diese DLL verwenden soll hat ja bereits eine GUI laufen. Daher frage ich..
Dem Gefühl nach würde ich sagen ich muss das Application.Run() selbst ebenfalls veranlassen weil es zwei getrennte Systeme sind.. Aber ich frage lieber mal..

Besten Dank schon einmal für jede Art Input 🙂

Schöne Grüße
Martin

C
1.214 Beiträge seit 2006
vor 9 Jahren

Dann wäre hier noch die Frage zu klären, ob der Verwender dieser DLL das .NET Framework installiert haben muss oder nicht.

Ja. Das war einfach zu beantworten 😉

Die andere Frage zu beantworten würde ich mich jetzt nicht trauen, habe schon seit Jahren nicht mehr mit .NET programmiert. Ich kann mich dunkel erinnern, dass ich sowas schon mal gemacht habe, dürfte jetzt aber schon 7-8 Jahre her sein. Ich vermute, dass du Application.Run irgendwo aufrufen müssen wirst. Probiers am besten mal aus.

49.485 Beiträge seit 2005
vor 9 Jahren

Hallo BlackEye,

in dem Thread, in dem die Komponente läuft, muss Application.Run laufen. Wenn man die Komponente also in einem Thread erzeugt, in dem schon Application.Run läuft(*), darf/sollte man es nicht erneut aufrufen. Es sollte nur einen Thread geben, in dem Application.Run läuft (nur ein GUI-Thread).

herbivore

(*) Wenn man die Komponente z.B. in einem Button-Click-EventHandler erzeugt, wird wohl Application.Run laufen. Wenn man sie alles erstes im Main erzeugt, wohl (noch) nicht.

B
BlackEye Themenstarter:in
5 Beiträge seit 2014
vor 9 Jahren

Danke für die Antworten!

Kann man denn irgendwie überprüfen ob der GUI-Thread bereits läuft? Also ob ich Application.Run() noch aufrufen muss oder nicht?

Nur um nochmal die Situation zu erklären:
Meine DLL wird aus einem Fremdprogramm heraus aufgerufen. Das Fremdprogramm hat bereits eine GUI laufen, aber eben seine eigene. Das Fremdprogramm ist in VB geschrieben und wird meine DLL via COM nutzen (zumindest wurde mir das so gesagt). Meine Intuition sagt mir das die Programme getrennt voneinander ablaufen und das ich Application.Run() in jedem Fall aufrufen muss. Das Fremdprogramm könnte ja z.B. auch ein in c++ oder Brainfuck geschriebenes Programm sein... Aber wenn eine Abfrage, ob Application.Run() noch aufgerufen werden muss oder nicht, möglich ist, dann wäre ich ja auf der sicheren Seite.

Beste Grüße
Martin

4.221 Beiträge seit 2005
vor 9 Jahren

Mach doch ein ActiveX-Control und lasse das in einem VB(6) Form hosten... dann hast Du schon alles rundherum.

Creating an ActiveX control in .Net using C#

Wichtig aus eigener Erfahrung: ein ActiveX-Control MUSS von UserControl ableiten (also nicht von Panel oder sonstwas)... sonst werden die Events deines UserControls versenkt.

Früher war ich unentschlossen, heute bin ich mir da nicht mehr so sicher...

M
198 Beiträge seit 2010
vor 9 Jahren

Hallo!

Also bei mir war diese Aufgabe nicht so schwer...

  • Ich habe ein neues Klassenbibliothek Projekt erstellt.

  • Es so konfiguriert, wie von Dir beschrieben ...

  • Im Zielprogramm muss ich nur als Host localhost wählen, die richtige DLL auswählen und dann noch meine Methode... und schon läuft es.

  • Wichtig ist nur, dass Du die DLL auf dem Zielrechner registrierst per RegAsm.exe

Gruss Mike

B
BlackEye Themenstarter:in
5 Beiträge seit 2014
vor 9 Jahren

Scheint genau so zu laufen. Schönen Schrank an alle 😃
Funktioniert!