+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: DLL & externer Code (/Forum-DLL-externer-Code)
+---- Thema: Eingebundene DLL zieht weitere DLLs an (/Thread-Eingebundene-DLL-zieht-weitere-DLLs-an)
Eingebundene DLL zieht weitere DLLs an - sima - 05.12.2008 11:06
Hallo,
Ich habe eine DLL, die ich in LabVIEW einbinden will. Diese zieht aber noch weitere DLLs an. Wie kann ich LabVIEW die weiteren DLLs bekannt machen? Im Tools->Import->Shared DLL-Wizard kann ich immer nur eine DLL auf dem Suchpfad angeben.
Wenn ich die DLL einbinde, bekomme ich auch die Funktionen als VIs, aber LV meckert, dass es die anderen DLLs nicht finden kann und somit sind die VIs nicht ausführbar.
Danke für Hilfe....
Gruß
Simon
Eingebundene DLL zieht weitere DLLs an - RoLe - 05.12.2008 14:33
' schrieb:Wenn ich die DLL einbinde, bekomme ich auch die Funktionen als VIs, aber LV meckert, dass es die anderen DLLs nicht finden kann und somit sind die VIs nicht ausführbar.
Ich vermute einmal, dass deine DLL's irgendwo auf der HD liegen.
LabVIEW sucht die DLL nach den Regeln, die hier beschrieben sind.
Eingebundene DLL zieht weitere DLLs an - sima - 05.12.2008 14:38
Hallo nochmal,
Mir wurde mittlerweile mitgeteilt, dass die DLL die ich einbinden will weitere DLLs automatisch an sich bindet, dass muss also LV doch eigentlich gar nicht interessieren?! So habe ich die anderen DLLs einfach mal unter Windows-Systemverzeichnis abgelegt, da sollte ja in aller Regel immer nach DLLs gesucht werden, aber LV meckert weiter fröhlich vor sich hin. Kann das Ganze eventl. auch an der DLL selbst liegen?
Bin dankbar für jegliche Hinweise, was hier falsch läuft.
Gruß
S.
Eingebundene DLL zieht weitere DLLs an - rolfk - 07.12.2008 10:06
' schrieb:Hallo nochmal,
Mir wurde mittlerweile mitgeteilt, dass die DLL die ich einbinden will weitere DLLs automatisch an sich bindet, dass muss also LV doch eigentlich gar nicht interessieren?! So habe ich die anderen DLLs einfach mal unter Windows-Systemverzeichnis abgelegt, da sollte ja in aller Regel immer nach DLLs gesucht werden, aber LV meckert weiter fröhlich vor sich hin. Kann das Ganze eventl. auch an der DLL selbst liegen?
Bin dankbar für jegliche Hinweise, was hier falsch läuft.
Gruß
S.
Das interessiert LabVIEW auch nicht wirklich. Die einzige Möglichkeit um diese Abhängigkeiten zu sehen wäre für LabVIEW um die Importtabellen, wie der dynamische Linker von Windows das auch macht, rekursiv zu durchsuchen. Eine sinnlose Arbeit da Windows das ja selbst schon macht.
Aber um eine DLL als ausführbare Datei laden zu können (und da die Call Library Node die Funktion in der DLL irgendwann ja auch afrufen will bleibt LabVIEW gar nichts anderes übrig als von Windows diese Variante zu verlangen) verlangt Windows, dass alle Abhängigkeiten aufgelöst werden können. Wenn auch nur eine davon nicht gelingt, verweigert Windows das Laden der DLL ganz.
DLLs von Hand ins Systemverzeichnis zu verschieben gibt Dir spätestens wenn Du die Applikation auf weiteren Computern installieren willst grosse Probleme.
Entweder hast Du einen Installer für Deine DLL's der das besorgt oder Du kopierst diese DLL's während der Entwicklung besser in ein Verzeichnis, das Du an die PATH Umgebungsvariable Deiner Entwicklungsmaschine hinzugefügt hast. Sobald Du denn ein Executable machst fügst Du diese DLLs als Supportfiles ins Projekt und stellst sicher dass sie im selben Verzeichnis landen wo auch Dein EXE File hinkommt.
Rolf Kalbermatter
Eingebundene DLL zieht weitere DLLs an - sima - 09.12.2008 10:25
Hallo,
Ich glaube, dass das Problem kein "Pfadproblem" ist. Das Finden der DLLs ist scheinbar kein Problem mehr, denn es kommt mittlerweile eine andere Fehlermeldung. Die DLL, die ich einbinden will ist eine Debug-DLL und zieht andere Debug-DLLs an, die alle auf anderen Rechnern erstellt wurden. Eine zu den DLLs gehörige EXE-Datei (MFC), erstellt mit Visual Studio, läßt sich auch nicht auf meinem Rechner ausführen und wirft die gleiche Fehlermeldung, wie LV:
"Diese Anwendung konnte nicht gestartet werden, weil die Anwendungskonfiguration nicht korrekt ist. Zur Problembehandlung sollten sie die Anwendung neu installieren"
Kann es sein, das LV mit Debug-DLLs nicht zurecht kommt?
Gruß
Simon
Eingebundene DLL zieht weitere DLLs an - rolfk - 09.12.2008 14:01
' schrieb:Hallo,
Ich glaube, dass das Problem kein "Pfadproblem" ist. Das Finden der DLLs ist scheinbar kein Problem mehr, denn es kommt mittlerweile eine andere Fehlermeldung. Die DLL, die ich einbinden will ist eine Debug-DLL und zieht andere Debug-DLLs an, die alle auf anderen Rechnern erstellt wurden. Eine zu den DLLs gehörige EXE-Datei (MFC), erstellt mit Visual Studio, läßt sich auch nicht auf meinem Rechner ausführen und wirft die gleiche Fehlermeldung, wie LV:
"Diese Anwendung konnte nicht gestartet werden, weil die Anwendungskonfiguration nicht korrekt ist. Zur Problembehandlung sollten sie die Anwendung neu installieren"
Kann es sein, das LV mit Debug-DLLs nicht zurecht kommt?
Gruß
Simon
NEIN!!!
Aber DLLs mit Debug Einstellungen gelinkt, linken normalerweise auch auf die DebugVersion der C Runtime Library. Und wenn Du das mit Visual C machst sind es halt die MSVC runtime libraries. Die non-debug Libraries sind meist schon installiert weil sie entweder schon mit Windows mitkommen oder durch später installierte Applikationen (IE, MSN, 3rd Party Applikationen).
Die Debug Runtime Libraries sind eben normalerweise nur auf dem Rechner installiert wo auch die Visual C Umgebung drauf installiert ist. Das geht eigentlich auch gar nicht anders. Für die Non-Debug Versionen bekommt man von MS ein redistributable right, so dass man den redistributable Installer von VC in die Applikationionsinstallation mitnehmen kann. Für die Debug Versionen hat man dieses Recht nicht. Macht auch nicht viel Sinn da die Debug Versionen nur viel grösser und langsamer sind, weil sie Code enthalten der im Debugger hilfreiche Informationen geben kann. Ohne installierten Debugger macht die Debugversion einer Applikation/DLL wenig Sinn.
Die Verwendung von MFC macht das Ganze noch etwas komplizierter da das wieder eine Anzahl von weiteren (Non-) Debug runtime libraries mit reinzieht.
Rolf Kalbermatter