+- 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: .NET 4.0 dll wird nicht gefunden (/Thread-NET-4-0-dll-wird-nicht-gefunden)
.NET 4.0 dll wird nicht gefunden - TheBoss - 15.06.2012 15:52
Hallo Zusammen
es geht prinzipell um einen 2d Code Scanner von Motorola (MS4407).
Leider lässt sich dieser von Werk aus nur über ein Windows Messager Service ansprechen. Da dies mit Labview echt kein Spaß ist habe ich mir eine VCS .NET 4 dll erstellt. Diese erledigt eigentlich alles für mich ... Form/Fenster öffnen, Windows messeaging aktivieren und auf Fenster richten, Grundkonfiguration an Scanner senden, Daten austauschen die im Speicherbereich der From liegen.
In einem Beispiel das ich in Labview geschrieben habe und auf der Dev Oberfläche ausführe funktioniert alles wunderbar.
Erstelle ich nun mit dem Builder eine Exe aus der Programm und starte es. Bekomme ich die Warnung das die Datei (MS4407.dll) nicht gefunden wurde. Ich solle auch bitte danach suchen.
Wenn ich in meinem Data Ordner suche finde ich sie auch promt und wähle sie aus. Dann bekomme ich folgenden Fehler -> Anhang LV_Fehler_Scanner_1.jpg
Egal aus welchem Verzeichnis (z.b. C:\MS4407.dll) oder im Data Ordner kann diese Datei nicht gefunden werden.
Bennen ich die Datei um ... bewirkt das auch nichts.
An was kann das liegen? Ich habe den EXEen Aufbau schon aug LV 8.XX gestellt um einen Strukturfehler auszuschließen. Was läuft falsch? Bzw was mache ich falsch?
Viele Grüß
Euer BOSS!
RE: .NET 4.0 dll wird nicht gefunden - rolfk - 15.06.2012 16:26
(15.06.2012 15:52 )TheBoss schrieb: Hallo Zusammen
es geht prinzipell um einen 2d Code Scanner von Motorola (MS4407).
Leider lässt sich dieser von Werk aus nur über ein Windows Messager Service ansprechen. Da dies mit Labview echt kein Spaß ist habe ich mir eine VCS .NET 4 dll erstellt. Diese erledigt eigentlich alles für mich ... Form/Fenster öffnen, Windows messeaging aktivieren und auf Fenster richten, Grundkonfiguration an Scanner senden, Daten austauschen die im Speicherbereich der From liegen.
In einem Beispiel das ich in Labview geschrieben habe und auf der Dev Oberfläche ausführe funktioniert alles wunderbar.
Erstelle ich nun mit dem Builder eine Exe aus der Programm und starte es. Bekomme ich die Warnung das die Datei (MS4407.dll) nicht gefunden wurde. Ich solle auch bitte danach suchen.
Wenn ich in meinem Data Ordner suche finde ich sie auch promt und wähle sie aus. Dann bekomme ich folgenden Fehler -> Anhang LV_Fehler_Scanner_1.jpg
Egal aus welchem Verzeichnis (z.b. C:\MS4407.dll) oder im Data Ordner kann diese Datei nicht gefunden werden.
Bennen ich die Datei um ... bewirkt das auch nichts.
An was kann das liegen? Ich habe den EXEen Aufbau schon aug LV 8.XX gestellt um einen Strukturfehler auszuschließen. Was läuft falsch? Bzw was mache ich falsch?
Viele Grüß
Euer BOSS!
Zwei Dinge fallen mir ein:
Bist Du sicher LabVIEW unterstützt .Net 4.0 voll oder hast Du den Manifest Hack gemacht den man auf der NI Seite finden kann? Wenn Du für LabVIEW diesen Hack gemacht hast wirst Du das auch angepasst für Dein Executable tun müssen. Windows weiss schliesslich nicht dass Deine App von LabVIEW kommt, und dass es magisch den LabVIEW manifest Hack verwenden soll.
Wenn das nicht das Problem ist dann hat es mit der DLL Suchfolge zu tun die Windwos verwendet beim Laden einer DLL. Der Data Folder funktioniert nur für DLLs die Du auch wirklich mit der LabVIEW Call Library Node in Deine Applikation einbindest. LabVIEW merkt sich den Pfad dieser DLL im VI und lädt ihn auch entsprechend. Deine famose .Net DLL ist nicht so schlau sondern bemüht ganz einfach Windows um die DLL zu finden und Windows sucht nur in folgenden Verzeichnissen:
1) Bereits im Speicher geladen mit dem entsprechenden DLL Namen
2) Im Verzeichnis wo das aktuelle Executable liegt, also dort wo Dein myapp.exe ist, nicht im Data Unterverzeichnis darin.
3) Im System directory
4) Im Windows directory
5) Alle Directories die in der PATH Umgebungsvariable aufgeführt sind
Ansonsten sucht Windows nirgends, nada, niente.
Und ich akzeptiere keinen anderen Boss, ich habe schon einen zuhause.
RE: .NET 4.0 dll wird nicht gefunden - TheBoss - 15.06.2012 16:38
Zitat: Bist Du sicher LabVIEW unterstützt .Net 4.0 voll oder hast Du den Manifest Hack gemacht den man auf der NI Seite finden kann? Wenn Du für LabVIEW diesen Hack gemacht hast wirst Du das auch angepasst für Dein Executable tun müssen. Windows weiss schliesslich nicht dass Deine App von LabVIEW kommt, und dass es magisch den LabVIEW manifest Hack verwenden soll.
Das war die Lösung. Schade das Labview nicht von alleine ein Unterstützung von NET 4 mitbringt. Durch den SP hätte ich mir das schon gewünscht.
Zum zweiten Hinweis. Klar sucht windows in den Paths ... jedoch will labview die dll haben. Windows hat rein garnichts damit zu tun beim laden.
Also vielen Dank ! War jetzt einfach der anstoß nach dem richtigen Keyword bei NI zu suchen! App läuft!
P.s.: Meine famose dll ermöglicht zumindest das einscannen von codes in labview
RE: .NET 4.0 dll wird nicht gefunden - rolfk - 15.06.2012 17:42
(15.06.2012 16:38 )TheBoss schrieb: Das war die Lösung. Schade das Labview nicht von alleine ein Unterstützung von NET 4 mitbringt. Durch den SP hätte ich mir das schon gewünscht.
Das ist ganau so gut das Problem von Microsoft als von NI. Um jeden Furz von MS folgen zu müssen ist kein Honigschlecken.
Zitat:Zum zweiten Hinweis. Klar sucht windows in den Paths ... jedoch will labview die dll haben. Windows hat rein garnichts damit zu tun beim laden.
Deine Erklärung war insofern undeutlich ob die MS4407.dll jetzt Deine .Net DLL war, oder die DLL vom Hersteller die Du mit Deinem Wrapper einbindest. Wenn es die .Net DLL ist dann weiss LabVIEW tatsächlich wo es sie finden soll. Wenn es aber die Hersteller DLL ist die Du mit Deinem .Net Wrapper einbindest hat LabVIEW rein gar nichts zu tun mit dem Laden dieser DLL.
Zitat:P.s.: Meine famose dll ermöglicht zumindest das einscannen von codes in labview
Das war zwar etwas ironisch ausgedrückt, aber ich wollte Dir nicht damit auf die Füsse treten. Persönlich würde ich aber lieber in Assembler programmieren dann eine .Net Lösung in Betracht zu ziehen.
