VI mit .net dll's funktioniert nur als exe, nicht im Entwicklungsmodus

Hallo LabViewgemeinde,

ich habe hier ein echt großes Problem mit einem VI. Hoffentlich ist einer von euch "LabViewgott" . Folgendes.

Ich muß mit Hilfe von Labview eine Verbindung zu einem externen Server herstellen. Von der Firma, wo der Server sich befindet, habe ich zum einrichten der Verbindung einige .net dll's erhalten. Diese werden einfach in .net Eigenschafts und Methodenknoten eingebunden und dann zusammen geknöpert. Um nun eine Verbindung zu dem besagten Server herzustellen, muß man lediglich als Inputparameter einen Objektnamen, Port und IP-Nummer eintragen.
Das Testen dieses VI's in der normalen Entwicklungsumgebung funktioniert nicht. Ab dem zweiten Knoten hängt sich das VI komplett auf, sodass es über den Taskmanager beendet werden muß. Wandel ich dieses VI in eine Execution-Datei um, so gibt es keinerlei Probleme. Verbindung hergestellt.
Meine Frage an Euch lautet,"Warum läuft das VI nicht im Entwicklungsmodus und wie bekomme ich es dort zum Laufen?".
Ich habe Nachforschungen betrieben und vermute entweder:
1. Die eingebundene dll im zweiten Knoten kann eventuell nicht auf andere benötigte .net dll's zugreifen. Das VI ist ja noch nicht durch den Compiler gelaufen. oder
2. Die Internetverbindung läuft über TCP/IP. LabView benötigt beim TCP/IP Verkehr ein sende VI und dynamisches Empfangs VI. Ich besitze aber nur die dll's .

Habe heut schon den ganzen Tag erfolglos hin und her experimentiert . Komme mir schon vor wie ein Pixelschubbser
Falls irgendjemand des Rätselslösung kennt -> "Please I need Help!!!"

Vielen Dank im Voraus

lv10
   

Anzeige

Zwar bringst Du selber die Vermutung nach vorne, dass es sich um ein Pfadproblem mit den DLLs handeln könnte, aber dann lieferst Du keinerlei Informationen dazu wie denn dieses Pfad Layout im Project und im Executable aussieht.

.Net hat sehr spezifische Ideen wo eine DLL sein muss dass es sie selber finden kann. Das ist nämlich entweder im Global Assembly Cache (GAC) oder im Ordner, in dem das Executable liegt, das den aktuellen Prozess gestartet hat. LabVIEW fügt da innerhalb der Entwickelumgebung selber noch explizit den Ordner hinzu in dem das aktuelle Projectfile liegt. Im Executable Fall, ist dies der data Folder in dem normalerweise alle nicht VI Files abgespeichert werden.

Wenn Du also im Project alle Deine zig DLLs einfügst aber irgendwo in der VI Hierarchy belässt, wird LabVIEW zwar von .Net verlangen um die direkt in LabVIEW Nodes aufgerufenen .Net DLLs von dem absoluten Path zu laden den Du beim Erstellen der Node angegeben hast, aber alle indirekt abhängigen DLLs muss .Net selber finden und laden, und kann sie nicht finden. Dass die Top Level Komponente sich dabei aufhängt statt einen Fehler zu produzieren ist allerdings ein Programmierfehler in der Top Level Komponente.

Und Deine Vermutung dass es etwas mit dem LabVIEW Compiler zu tun hat ist garantiert falsch. LabVIEW VIs werden vor der ersten Ausführung und nach jeder Änderung automatisch kompiliert. Der Applikation Builder ist eigentlich nur ein Linker/Packer. Er nimmt alle VIs, stript die nicht mehr benötigten Diagramme, Frontpanel und andere Dinge, packt diese in ein File, das dann mit einem Executable Wrapper versehen wird. Dazu kopiert er auch noch alle anderen vorgebenen nicht VI FIles, wie Dokumente, DLLs und dergleichen in die in der Buildkonfiguration angegebenen Ordner. Zudem werden eventuelle Anpassungen an Pfadverweise gemacht um VIs dahingehende anzupassen, dass sie zum Beispiel DLLs von dem Ordner lädt, wo der Builder sie im Executable hinkopiert.

Da Du wahrscheinlich alle DLLs in Deinem Project aufführst kopiert LabVIEW sie beim Erstellen eines Executables ALLE in den Data Folder, et voila! .Net kann sie plötzlich finden, wenn Du das Executable startest.

Hallo rolfk,

vielen Dank für die Antwort. Die Ordnerstruktur war wirklich das Problem. Das VI läuft nun auch im Entwicklungsmodus.
Durch deinen GAC Hinweis habe ich noch einen sehr ähnlichen Beitrag von dir gefunden http://www.labviewforum.de/archive/index...-1530.html. Der war das " i " Tüpfelchen zu meiner Lösung.

----

Zitat:Zwar bringst Du selber die Vermutung nach vorne, dass es sich um ein Pfadproblem mit den DLLs handeln könnte, aber dann lieferst Du keinerlei Informationen dazu wie denn dieses Pfad Layout im Project und im Executable aussieht.

Sorry, hatte ich wohl vergessen. Die dll's muß ich auf jeden Fall dem Projekt hinzufügen, sonst bekomm ich eine Fehlermeldung das bestimmte dll's nicht gefunden werden.

Zitat:Und Deine Vermutung dass es etwas mit dem LabVIEW Compiler zu tun hat ist garantiert falsch.

Stimmt! Ich habe an den Linker gedacht, aber Compiler geschrieben

Vielen Dank für Eure Bemühungen.

Ein schönes Wochenende

Gruß Markus

PS: rolfk

Eine Frage habe ich doch noch. Das VI lässt sich zwar im Entwicklungsmodus starten, jedoch nur wenn sich die dll's am Anfang des Projektpfades befinden. Sobald der Ordner mit den dll's tiefer in die Unterverzeichnisse geschoben wird funktioniert es nicht mehr. Ich habe zwar gelesen das .net bestimmte Voraussetzung benötigt, aber das es sich hierbei schon aufhängt versteh ich nicht .
Lässt sich .net, oder welchem Prozess auch immer, der Pfad des Ordners zuweisen(dll Pfade sind im Projekt eingebunden)? Finde leider auch keine richtige Hilfe im Netz dazu.

MfG

(30.01.2012 12:14 )markus321 schrieb:  Eine Frage habe ich doch noch. Das VI lässt sich zwar im Entwicklungsmodus starten, jedoch nur wenn sich die dll's am Anfang des Projektpfades befinden. Sobald der Ordner mit den dll's tiefer in die Unterverzeichnisse geschoben wird funktioniert es nicht mehr. Ich habe zwar gelesen das .net bestimmte Voraussetzung benötigt, aber das es sich hierbei schon aufhängt versteh ich nicht .
Lässt sich .net, oder welchem Prozess auch immer, der Pfad des Ordners zuweisen(dll Pfade sind im Projekt eingebunden)? Finde leider auch keine richtige Hilfe im Netz dazu.

MfG

.Net selber kennt nur zwei Directories, wo es automatisch nach .Net Assemblies sucht: der GAC und das Applikation Directory wo das Executable File des aktuellen Prozesses liegt. LabVIEW macht sich die Mühe um das Directory in dem das aktuelle Project gespeichert ist ebenfalls bei .Net als Suchpfad anzumelden. Das schliesst aber keine Unterverzeichnisse ein. Die Restriktionen von .Net sind hauptsächlich um DLL Hell zu vermeiden. Meiner Meinung ist das nur halbwegs gelungen, trotz dieser grossen Einschränkungen aber was solls.

Hallo rolfk,

habe das mit dem GAC nun auch kapiert . Mit Hilfe der Microsoftpage Dateianzeige des GAC habe ich mir Zugriff auf den GAC Ordner verschafft. Leider musste ich feststellen das das hinzufügen der dll's nicht ausreichend ist. Zusätzlich ist wohl die Registrierung der Daten nötig (Regsrv32 or RegAsm). Die Prozedur führt anscheinend aber nur zu einem lokalen Erfolg und ist für mich daher unbrauchbar. Muss mich wohl damit abfinden die dll's im Projektpfad abzulegen.

Danke für die Hilfe

Mfg

Anzeige

(31.01.2012 12:37 )markus321 schrieb:  Hallo rolfk,

habe das mit dem GAC nun auch kapiert . Mit Hilfe der Microsoftpage Dateianzeige des GAC habe ich mir Zugriff auf den GAC Ordner verschafft. Leider musste ich feststellen das das hinzufügen der dll's nicht ausreichend ist. Zusätzlich ist wohl die Registrierung der Daten nötig (Regsrv32 or RegAsm). Die Prozedur führt anscheinend aber nur zu einem lokalen Erfolg und ist für mich daher unbrauchbar. Muss mich wohl damit abfinden die dll's im Projektpfad abzulegen.

Danke für die Hilfe

Mfg

Grundsätzlich sollte das Hinzufügen der DLLs in den GAC Ordner genügen. Aber!!!!! .Net akzeptiert nur DLLs die "strongly named" sind. Die genauen Details sind mir nicht mehr ganz present aber es geht darum dass eine DLL eine Namen hat in dem auch die vierteilige Versionsnummer vorkommt, und wenn ich mich nicht irre muss die DLL auch "signed" sein.

Zitat:Aber!!!!! .Net akzeptiert nur DLLs die "strongly named" sind.

Hatte vorhin einen Gedankenblitz. Wollte den die Eigenschaft "strong name" =false mit VB auf auf true setzten bzw. die dll zurechtbiegen. Hat aber nicht funktioniert.