Einbindung einer .NET dll-Kette in LV

Hallo allerseits,

ich möchte eine .NET dll in LV einbinden. Wie das geht, weiß ich, und es wäre ja auch gar kein Problem, wenn es nur diese eine dll geben würde. Aber leider hängt diese Haupt-dll wiederum von weiteren dlls ab. Alle diese dlls sind im selben Verzeichnis wie das LV vi. Doch bei der Ausführung der Constructor node in LV kommt es immer zu einer FileNotFound exception. Ich vermute das liegt daran, dass LV die Haupt-dll in einem anderen Kontext (Application Domain, Pfad, ...) ausführt, wo sie ihrerseits ihre Sub-dlls nicht findet. Die ganze dll-Kette kann ich jedoch problemlos aus dem Visual Studio (mit einer .NET-Test-App, die das vi ersetzt) starten. Es muss also an LV liegen. Meine Version von LV ist 2012. Hoffentlich weiß jemand einen Rat, denn ich komme hier nicht weiter. Auch die Verwendung eines LV-Projekts half nichts. Oder muss ich wirklich die .NET dll ihre Unter-dlls dynamisch mit Reflection laden lassen oder alle in einen monolitischen dll-Block reinhauen?

Gruß

Johannes

(24.02.2015 19:54 )JEble schrieb:  Hallo allerseits,

ich möchte eine .NET dll in LV einbinden. Wie das geht, weiß ich, und es wäre ja auch gar kein Problem, wenn es nur diese eine dll geben würde. Aber leider hängt diese Haupt-dll wiederum von weiteren dlls ab. Alle diese dlls sind im selben Verzeichnis wie das LV vi. Doch bei der Ausführung der Constructor node in LV kommt es immer zu einer FileNotFound exception. Ich vermute das liegt daran, dass LV die Haupt-dll in einem anderen Kontext (Application Domain, Pfad, ...) ausführt, wo sie ihrerseits ihre Sub-dlls nicht findet. Die ganze dll-Kette kann ich jedoch problemlos aus dem Visual Studio (mit einer .NET-Test-App, die das vi ersetzt) starten. Es muss also an LV liegen. Meine Version von LV ist 2012. Hoffentlich weiß jemand einen Rat, denn ich komme hier nicht weiter. Auch die Verwendung eines LV-Projekts half nichts. Oder muss ich wirklich die .NET dll ihre Unter-dlls dynamisch mit Reflection laden lassen oder alle in einen monolitischen dll-Block reinhauen?

Gruß

Johannes

.Net hat grundsätzlich nur folgende Directories wo es nach .Net DLLs sucht:

1) Das Applicationsdirectory (dort wo das aufrufende Executable liegt)
2) Die GAC (Global Assembly Cache)

2) erfordert aber spezifisch dass eine .Net DLL "strongly named" ist, das heisst einen Namen und vollständigen Versionsnummer Eintrag in den assembly properties hat.

LabVIEW fügt zu diesen zwei Directories auch noch das Directory hinzu wo das Projektfile liegt.

Alles andere ist grundsätzlich nicht automatisch unterstützt und muss jeweils entweder von der Assembly selber expliziet getan werden oder von der Applikation die Du schreibst indem to entsprechende Directories in den .Net Pfad einfügst, aber das Letzte habe ich nie versucht und erscheint mir ohnehin ein Pfusch.

Hallo Rolf,

vielen Dank für deine Antwort.

Allerdings denke ich, dass ich das Problem habe, dass ich nicht "die Executable" selbst aufrufen, sondern das Haupt-vi (und damit mit der Windows-Assotiation der Dateiendung *.vi LabView selbst). D.h. ich arbeite nicht mit dem Application Builder, das LabView-Programm wird garnicht kompiliert, und auf dem Zielrechner befindet sich immer LabView. Mein Partner möchte das explizit so, da er das LabView-Programm auch selbst schreibt und immer wieder modifiziert, da sei es laut ihm zu umständlich, dauernd die Vi's in eine exe zu compilieren. Ich komme eigentlich aus der C#-Programmierung (habe zwar mal LV programmiert, ist aber schon 10 Jahre her) und bin "nur" für die Einbindung der dlls in LabView zuständig).
Offenbar muss dann der "Application-Pfad" von LabView (oder was auch immer das Main-vi aufruft) zunächst, bei der 1. dll, das Verzeichnis des vi sein, denn diese 1. dll wird gefunden und geladen. Das gilt aber nicht mehr für die Sub-dlls, die von der 1. dll benutzt werden sollen, denn natürlich habe ich diese auch in das Verzeichnis des vi kopiert. Er findet sie aber trotzdem nicht.

Gruß

Johannes

Beim Aufruf in der Entwicklungsumgebung ist die aufrenden Executable die LabVIEW.exe.

Edit: An welcher Stelle hat er den fälschlicherweise deine anderen Assemblies erwartet? Hast ja immerhin eine FileNotFound exception erhalten.

(09.03.2015 07:03 )JEble schrieb:  Hallo Rolf,

vielen Dank für deine Antwort.

Allerdings denke ich, dass ich das Problem habe, dass ich nicht "die Executable" selbst aufrufen, sondern das Haupt-vi (und damit mit der Windows-Assotiation der Dateiendung *.vi LabView selbst). D.h. ich arbeite nicht mit dem Application Builder, das LabView-Programm wird garnicht kompiliert, und auf dem Zielrechner befindet sich immer LabView. Mein Partner möchte das explizit so, da er das LabView-Programm auch selbst schreibt und immer wieder modifiziert, da sei es laut ihm zu umständlich, dauernd die Vi's in eine exe zu compilieren. Ich komme eigentlich aus der C#-Programmierung (habe zwar mal LV programmiert, ist aber schon 10 Jahre her) und bin "nur" für die Einbindung der dlls in LabView zuständig).
Offenbar muss dann der "Application-Pfad" von LabView (oder was auch immer das Main-vi aufruft) zunächst, bei der 1. dll, das Verzeichnis des vi sein, denn diese 1. dll wird gefunden und geladen. Das gilt aber nicht mehr für die Sub-dlls, die von der 1. dll benutzt werden sollen, denn natürlich habe ich diese auch in das Verzeichnis des vi kopiert. Er findet sie aber trotzdem nicht.

Gruß

Johannes

In dem Fall ist LabVIEW das Executable und gilt zudem die Bemerkung über das Projektdirectory, obwohl ich jetzt nicht sicher bin ob man über ActiveX ein Projekt öffnen kann. Das ActiveX Interface stammt noch aus der Zeit bevor LabVIEW Projekte kannte.