Ich habe in meine LabVIEW 8.6 Anwendung eine externe .NET-DLL eingebunden. Dies funktioniert soweit auch wunderbar. Diese DLL liegt mit in meinem Projekt-Verzeichnis und ich habe sie auch in die Projektstruktur aufgenommen.
Wenn ich nun eine Applikation aus dem Projekt erstelle, funktioniert das beim ersten Mal und er kopiert die Dateien wie gewünscht in ein Verzeichnis (inkl. der besagten DLL). Darauf hin scheint LabVIEW allerdings diesen Pfad für die DLL zu bevorzugen und ich kann die Anwendung nicht noch einmal erstellen, weil der Fehler auftritt, dass "eine Quelldatei im Zielverzeichnis liegt". Wenn ich den Applikationsordner lösche nimmt er wieder die alte DLL und es funktioniert.
Mein Problem ist nun, dass ich einen Installer erstellen will. Dazu muss ich vorher die Applikation erstellen und dann hat der Installer aus mir unbekannten Gründen das selbe Problem.
Meine Frage ist nun, ob jemand schon einmal ein ähnliches Problem hatte und mir vielleicht einen Tip zur Beseitigung geben kann??
Vielen Dank im Vorraus, T.J
Hat denn wirklich keiner eine Idee?? Es muss doch irgendwo die Möglichkeit geben den Pfad für die DLL so festzulegen, dass LabView ihn nicht selbstständig wieder verändert.
Ich hatte in einem anderen Beitrag gelesen, dass DLLs die im Systemverzeichnis liegen nicht extra eingebunden werden. Aber auch das funktioniert bei mir nicht. Dann hätte ich die DLL später hinzugefügt, aber hätte zumindest einen Installer erstellen können.
Wenn es wirklich keine Möglichkeit gibt muss ich wohl die Run-Time-Engine manuell installieren und die Anwendung von Hand auf den Ziel-PC kopieren.
Falls noch jemandem was einfällt, ich bin für jeden Tip dankbar.
' schrieb:Hat denn wirklich keiner eine Idee?? Es muss doch irgendwo die Möglichkeit geben den Pfad für die DLL so festzulegen, dass LabView ihn nicht selbstständig wieder verändert.
Ich hatte in einem anderen Beitrag gelesen, dass DLLs die im Systemverzeichnis liegen nicht extra eingebunden werden. Aber auch das funktioniert bei mir nicht. Dann hätte ich die DLL später hinzugefügt, aber hätte zumindest einen Installer erstellen können.
Wenn es wirklich keine Möglichkeit gibt muss ich wohl die Run-Time-Engine manuell installieren und die Anwendung von Hand auf den Ziel-PC kopieren.
Falls noch jemandem was einfällt, ich bin für jeden Tip dankbar.
DotNet DLLs sind keine gewöhnlichen DLLs sondern sogenannte Assemblies. Dort spielen die Systemordner keinerlei Rolle beim Finden und Laden davon. Die DotNet Runtime hat da ganz ihre eigenen Gesetze. Grundsätzlich gibt es nur zwei eindeutige Orte wo eine DotNet DLL für eine Applikation liegen kann. Das ist der Global Assembly Chache (GAC) (wobei diese Assembly dann sogenannt strong named sein muss um darin abgelegt zu werden) und das Verzeichnis der Applikation die diese Assembly benützt. DotNet sucht erst im Applikationsverzeichnis unter Berücksichtigung der Version und danach im GAC. Eine Applikation kann extra Search Direcotries registrieren und das macht LabVIEW indem es in der Entwickelumgebung den Ordner in dem das Project liegt hinzufügt. Leider hat Microsoft es auch hier nicht geschafft um das was "DLL Hell" genannt wird wirklich zu vermeiden und eventuel pfuscht da LabVIEW mit dem Cachen von DotNet Assembly Pfaden auch noch etwas hinein. Tatsache ist aber das die DotNet Assemblies in vielen Hinsichten noch an den selben Problemen kränkeln als das mit DLLs der Fall war. Nur war es bei normalen DLLs alles noch einigermassen überschaubar aber mit dem Einführen von Manifesten, Overwrites, usw. wurde das Ganze beinahe ad absurdum geführt.
Ich habe eine Lösung gefunden:
Habe die DLL jetzt in den Stammordner des Projekts gelegt (dort liegen auch die *.lvproj und das main.vi). Damit liegt sie eine Ebene höher als die Applikation und wird dort scheinbar auch eher gefunden. Zumindest kann ich jetzt Applikation und Installer erstellen.
Vielen Dank an alle, die sich Gedanken gemacht haben.