Grundsatzfragen: DLL (C++/.Net/grundsätzlich) mit der Möglichkeit mehrerer Instanzen

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von jvbsl.

    Grundsatzfragen: DLL (C++/.Net/grundsätzlich) mit der Möglichkeit mehrerer Instanzen

    Hi zusammen,

    ich brüte grade über einem Problem und würde mich freuen, wenn mir der
    eine oder andere mit Erfahrung in dem Bereich vielleicht mal seine Einschätzung gibt.

    Kann man kurz zusammengefasst sagen, ob man eine DLL erstellen kann,
    die es erlaubt aus VB2013 mehrere Instanzen einer dort hinterlegten Klasse zu erzeugen
    und aus verschiedene Threads auf jeweils eine Instanz aus dieser DLL zuzugreifen ?

    Hintergrund:
    Die(/Das) DLL soll unter Win7 Kommunikationskanäle zu virtuellen Com-Ports (USB-Geräte) bereitstellen.
    Diese Kommunikationskanäle sollen sich nicht gegenseitig behindern (kein Multiplexing)
    sondern threadsicher parallel arbeiten und Daten übertragen können.

    Fragen dazu:
    - ist das grundsätzlich möglich oder gibt eine DLL das mit den threadfähigen Instanzen nicht her
    - steuerndes Programm : VB2013 / DLL in C++ : möglich ?
    - steuerndes Programm : VB2013 / DLL in ??? : möglich ?

    Falls es nicht mit einer DLL funktioniert alternative Möglichkeiten ?
    - Klasse direkt in VB (ohne DLL) sollte keine Problem sein ist - der Entwickler der DLL hat aber kaum Erfahrung in VB (Zeit/Kosten.. nix gut)
    und für mich selber kommt es aus zeitgründen eher auch nicht in Frage
    - DLL in VS2013 - evtl. C# - könnte sowas die Funktion abilden (Zeit/Kosten, durch Erfahrungsmangel müsste hinterfragt werden)
    - andere Ideen ?

    Danke für eure Einschätzung und Gruß
    Natürlich geht das mit einer Dll, diese kapselt ja nur den Code.
    Aber wenn die Dll nicht in .Net ist machst du dir nur unnötig Arbeit.
    Bau alles auf die SerialPort-Klasse auf, dort muss nur noch das senden in einen Thread.(wenn in unterschiedlichen Projekten von nutzen kannst du das natürlich auch in eine Dll auslagern)
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---
    @Duke Kein Problem.
    Wenn Du C++-Code hast, mach Dir eine CLI-DLL, die als .NET.Wrapper dafür dient, da funktioniert einfach alles.
    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).
    Programmierfragen über PN / Konversation werden ignoriert!

    jvbsl schrieb:

    Natürlich geht das mit einer Dll, diese kapselt ja nur den Code.
    Aber wenn die Dll nicht in .Net ist machst du dir nur unnötig Arbeit.
    Bau alles auf die SerialPort-Klasse auf, dort muss nur noch das senden in einen Thread.(wenn in unterschiedlichen…


    Aus Zeitgründen soll das ja derjenige machen, der auch die Firmware der angesteuerten Geräte schreibt.
    Derjenige ist aber leider eher "nur" in C/C++ zu Hause.

    RodFromGermany schrieb:

    <a href="http://www.vb-paradise.de/index.php/User/5400-Duke/">@Duke</a> Kein Problem.
    Wenn Du C++-Code hast, mach Dir eine CLI-DLL, die als .NET.Wrapper dafür dient, da funktioniert einfach alles.


    Danke für den Tipp. Ich habe mir mal grob diese Seite angeschaut:
    codeproject.com/Articles/65151…d-Cplusplus-CLI-vs-P-Invo

    Ich bin mir aber noch nicht ganz sicher, ob meine Problematik damit gelöst ist. Und zwar:

    Wenn ich das richtig sehe läuft das alles über einen gemeinsamen Wrapper. Über eine ID
    wird über den Wrapper die entsprechende Instanz angesprochen. Das heisst, der Wrapper
    stellt aber auch ein Bottleneck dar. Denn jeder Thread, der über den Wrapper auf "seine eigene" Instanz der DLL-Klasse
    zugreifen will, muss warten, bis die Komunikation des anderen Threads beendet und der
    Wrapper wieder frei ist für die nächste Kommunikation.

    Wenn man nur kurze Signale absetzen will oder kleine Informationen haben will fällt das wohl nicht ins Gewicht, aber
    ich muss über die Kommunikationskanäle Firmwareupdates der angeschlossenen Geräte machen - d. h. auf den einzelnen Kanälen herrscht
    annähernd eine Dauer-Datenstrom - und das gleichzeitig auf (geplant) 4 bis 5 Kanälen.

    Sind meine Befürchtungen gerechtfertigt oder ist das eher Blödsinn mit dem Wrapper als Daten-Bottleneck ?

    Duke schrieb:

    ob meine Problematik damit gelöst ist.
    Offensichtlich nicht.
    Ohne mich dort einarbeiten zu wollen:
    Mach Deinen eigenen Wrapper, der macht dann genau das, was Du programmiert hast.
    Das dürfte schneller gehen, als wenn Du einen unvollkommenen vorgefertigten nimmst und dessen Macken rausbügeln musst. :D
    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).
    Programmierfragen über PN / Konversation werden ignoriert!
    ein solcher Wrapper kostet ansich aufjedenfall etwas Zeit nun muss man unterscheiden:
    Die funktionen, welche in der nativen DLL laufen sind sehr Zeitanspruchsvoll und geben nur hin und wieder Signale an dein .Net Projekt, oder wir haben auch im .Net Projekt ständigen Datenaustausch mit der DLL und umgekehrt, denn dann ist der Wrapper aufjedenfall ein Flaschenhals.

    Das Problem ist dabei aber nicht das Threading.

    Die Frage ist was genau sollst denn du jetzt implementieren? Soll in der C++ DLL die komplette Kommunikation auf Basis eines Kommunikationsprotokoll geschrieben werden oder nur die serielle Anbindung?
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---