LV erkennt .Net-.dll nicht

Hallo miteinander,
nachdem ich hier im Forum viele Antworten auf meine Anfängerfragen gefunden habe begebe ich mich nun auf die nächste Stufe und stelle meine Anfängerfragen aktiv:

Ich versuche eine .Net .dll in Labview ein zu binden. Hierfür erstelle ich einen Konstruktorknoten, mache einen Doppelklick drauf und wähle unter "Durchsuchen" meine .dll aus. Hierauf bekomme ich von LV die Antwort:
"Die ausgewählte Datei ist keine .NET-Assembly, Typbibliothek oder Automations-EXE."

Ich habe keine Erfahrung im Programmieren oder Einbinden von .dll-Dateien, aber nach allem was ich im Internet gelesen habe denke ich, dass er zumindest die Datei akzeptieren sollte (auch wenn u.U. kein öffentlicher Konstruktor vorhanden ist). Das Tutorial mit dem Systemmonitor auf NI.com konnte ich erfolgreich umsetzen. Im Anhang ist eine Beispiel-.dll, bei der das selbe Problem auftritt.

Viele Grüße und vielen Dank im Voraus
lg

PS: Ich hoffe keine Forenregel grob verletzt zu haben

Mglw. ist das eine .NET 4.0 Assembly?

Dann schau mal hier:
http://digital.ni.com/public.nsf/allkb/2...enDocument
http://digital.ni.com/public.nsf/allkb/3...2600737DE9
oder hier:
http://digital.ni.com/public.nsf/allkb/3...2600737DE9

Gruß, Jens

Hallo Jens,
erstmal Danke für die Antwort.
Jetzt habe ich doch eine wichtige Information vergessen: Ja, es ist ein .Net 4.0 Assembly.
Ich konnte die Lösungen zwar noch nicht ausprobieren, aber ich denke dass das Problem damit (unter vorbehalt ) gelöst ist.
Viele Grüße
lg

(03.11.2011 08:21 )lg schrieb:  Hallo Jens,
erstmal Danke für die Antwort.
Jetzt habe ich doch eine wichtige Information vergessen: Ja, es ist ein .Net 4.0 Assembly.
Ich konnte die Lösungen zwar noch nicht ausprobieren, aber ich denke dass das Problem damit (unter vorbehalt ) gelöst ist.
Viele Grüße
lg

Absolut! Eine .Net Assembly ist halt keine normale DLL, sondern hat nur die gleiche Fileendung. Das geht noch einen Schritt weiter dann ActiveX Libraries wo zumindest die Registrierungsfunktion und die Zugriffsfunktion der ClassFactory noch als normale Funktionen exportiert wurden.

Ich habe Labview mittels eines Config-Files dazu gebracht .Net 4.0 zu akzeptieren. Somit konnte ich auch ein Objekt der Klasse erzeugen. Die Methoden der Klasse wollte Labview dennoch nicht verwenden.
Da ich leider unter Zeitdruck stehe habe ich vorerst das Problem mit einem Kommandozeilenaufruf gelöst (LV ruft über Kommandozeile das Programm auf und bekommt die Werte ebenso zurück).
Die Lösung ist nicht gerade die schönste, aber sie ist zweckdienlich.
Ich hoffe, dass sich diese Bequemlichkeit nicht rächt wenn ich aus dem Programm eine Application basteln will, aber ich habe da schon eine Einstellung im Application Builder gesehen, dass man die Konsolenausgaben an LV weiterleiten lassen kann...man wird sehen.

(10.11.2011 08:10 )lg schrieb:  Ich habe Labview mittels eines Config-Files dazu gebracht .Net 4.0 zu akzeptieren. Somit konnte ich auch ein Objekt der Klasse erzeugen. Die Methoden der Klasse wollte Labview dennoch nicht verwenden.
Da ich leider unter Zeitdruck stehe habe ich vorerst das Problem mit einem Kommandozeilenaufruf gelöst (LV ruft über Kommandozeile das Programm auf und bekommt die Werte ebenso zurück).
Die Lösung ist nicht gerade die schönste, aber sie ist zweckdienlich.
Ich hoffe, dass sich diese Bequemlichkeit nicht rächt wenn ich aus dem Programm eine Application basteln will, aber ich habe da schon eine Einstellung im Application Builder gesehen, dass man die Konsolenausgaben an LV weiterleiten lassen kann...man wird sehen.

Die Einstellung im Application Builder ist hier wahrscheinlich nicht von Bedeutung. Das geht darum das man ein LabVIEW Programm mit Kommandozeilenparametern aufrufen kann, und Dein HauptVI diese Parameter auch zu sehen bekommt. Was Du tust ist aber gerade das Umgekehrt mittels SystemExec und das geht sowohl in der Entwicklungsumgebung als auch in einem Executable auf dieselbe Weise. Natürlich musst Du sicherstellen, dass Du den richtigen Pfad zum Kommmandozeilentool verwendest, falls es kein Systemkommando ist das Windows auch ohne Pfad findet.

Ok, so genau hatte ich mir diese Sache noch nicht angesehen. Ich spiele mit dem Gedanken später einen Installer zu erstellen. Der könnte dann das aufgerufene Programm an einem definierten Ort ablegen, so dass ich mit einem relativen Pfad da sicher hin komme.
Wie unsauber ist so einen Kommandozeilenaufruf denn überhaupt? Ich schreibe momentan an meiner Bachelorthesis und insofern sollte das keine völlig verwefliche Methode sein. Ist das die Kategorie "Sollte man nicht so oft machen" oder eher die Kategorie "goto-Todsünde"?

PS: Ich möchte keine Diskussion über gotos anfangen, aber wahrscheinlich ist die Gefahr in einem Labviewforum da auch nicht so groß.

(10.11.2011 08:57 )lg schrieb:  Ok, so genau hatte ich mir diese Sache noch nicht angesehen. Ich spiele mit dem Gedanken später einen Installer zu erstellen. Der könnte dann das aufgerufene Programm an einem definierten Ort ablegen, so dass ich mit einem relativen Pfad da sicher hin komme.
Wie unsauber ist so einen Kommandozeilenaufruf denn überhaupt? Ich schreibe momentan an meiner Bachelorthesis und insofern sollte das keine völlig verwefliche Methode sein. Ist das die Kategorie "Sollte man nicht so oft machen" oder eher die Kategorie "goto-Todsünde"?

PS: Ich möchte keine Diskussion über gotos anfangen, aber wahrscheinlich ist die Gefahr in einem Labviewforum da auch nicht so groß.

In Unix/Linux ist der Kommandozeilenaufruf die allgemein übliche Art um externe Funktionalität aufzurufen. Unter Windows ist es etwas weniger gebräuchlich aber genau so legitim. Einige der Gründe warum das unter Windows weniger oft getan wird sind folgende:

- Windows kam von Anfang an mit einem Standard Shared Library Format. Unix hatte in früherer Zeit keine Shared Libraries und die ersten Implementationen die erschienen, waren für jede Unixumgebung wieder anders und teilweise extrem buggy.
- Unix Prozesserzeugung war besser omptimalisiert so dass die Erzeugung eines neuen Prozesses zur Ausführung einer Kommandozeile nicht so ein grosses Problem war. Unter Windows war und ist die Erzeugung eines Prozesses eine relativ kostbare Angelegenheit, so dass es nicht praktisch ist um ein Kommandozeilentool sehr häufig immer wieder aufzurufen. Eine DLL wird normalerweise im bestehenden Prozess einmal geladen und danach ist die Ausführung von Funktionen aus der DLL ein sehr fixer Vorgang.

Aber Aufruf eines Kommandozeilentools an sich ist auch unter Windows keine Schande. Einziges mögliches Problem ist das Format der Eingabe/Ausgabe. Microsoft Applikation und solche die sich Microsoft als Vorbild nehmen, wollen alles lokalisieren. Dann wird das Parsen einer Antwort oft ein Ratespiel.