.NET Error 1172

Hallo zusammen,
ich beschäftige mich erst seit wenigen Wochen mit LabVIEW, komme an sich mittlerweile gut zurecht.
Jetzt habe ich von der Firma AUTOLAB ein Software-Development-Kit runtergeladen um ein Messgerät mit LabVIEW ansteuern und auslesen zu können. Vorteil dieses Kits ist, dass dort schon einige Beispielprogramm SubVi´s und Messsequenzen integriert sind, so dass man eigentlich sofort darauf aufbauen könnte.

Bevor das Ganze aber lief, musste unsere LabVIEW Version von 7.1 auf 2011 gebracht werden (was mich schon graue Haare gekostet hat ).
Dann irgendwann konnte ich ein Beispielprogramm starten und die Kommunikation mit dem Messgerät stand auch, Werte kommen und gehen. ABER: Sobald ich bei diesen Programmen z.B. Prozeduren laden will, oder Messwerte in einen Folder abspeichern möchte, kommt ein Fehler. Klicke ich zweimal auf "weiter" kommt eine weitere Fehlermeldung. Ich hoffe ihr könnte die Fehler lesen. Auf dem Screenshot sieht man auch den "load" Button, der auch solch einen Fehler auslöst.

Woran kann das liegen? Findet LabVIEW vielleicht etwas nicht? Habe öfters gelesen, dass bestimmte Dateien im gleichen Ordner liegen müssen?!
Und dann habe ich, im Zusammenhang mit dem Fehler 1172, was von ".NET Full Trust" gelesen. Was bedeutet das?

Achso, .Net Framework 4.0 habe ich auch schon mal aktualisiert, hat nichts gebracht. Muss ich LabVIEW irgendwie sagen, dass es das .NET 4.0 voll unterstützen soll?

Ich hoffe ihr könnt mir da auf die Sprünge helfen!

Danke und Grüße,
Christian

(05.07.2012 10:16 )Woodie schrieb:  Klicke ich zweimal auf "weiter" kommt eine weitere Fehlermeldung. Ich hoffe ihr könnte die Fehler lesen. Auf dem Screenshot sieht man auch den "load" Button, der auch solch einen Fehler auslöst.

Den Fehler kann man lesen, sagt aber nicht viel aus...Der CallStack wäre da interessant...

Etwas in der Art:

Code:

(System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
    Inner Exception: CouldNotVerifyException: ReceiveCommand_Hex failed
(status: SI_SUCCESS, error: 0x00000000)
...

(05.07.2012 10:16 )Woodie schrieb:  Woran kann das liegen? Findet LabVIEW vielleicht etwas nicht? Habe öfters gelesen, dass bestimmte Dateien im gleichen Ordner liegen müssen?!

ni.com - Laden von .NET Assemblies
Meiner Ansicht nach (sofern es die Ferndiagnose zulässt) sind deine Assemblies an einer mehr oder weniger richtigen Stelle, andernfalls hätte LabVIEW dir angezeigt,
dass es die Assemblies nicht laden kann.

(05.07.2012 10:16 )Woodie schrieb:  Und dann habe ich, im Zusammenhang mit dem Fehler 1172, was von ".NET Full Trust" gelesen. Was bedeutet das?

Das brauchst du nur, wenn du Assemblies von einem Server laden willst

msdn.com - Running Intranet Applications in Full Trust

(05.07.2012 10:16 )Woodie schrieb:  Achso, .Net Framework 4.0 habe ich auch schon mal aktualisiert, hat nichts gebracht. Muss ich LabVIEW irgendwie sagen, dass es das .NET 4.0 voll unterstützen soll?

ni.com - Laden von .NET 4.0 Assemblies
Die Assemblies scheinen nicht mit .NET 4.0 framework erstellt worden zu sein, andernfalls hätte dir LabVIEW mitgeteilt, dass die Assemblies nicht geladen werden können (schon beim Konstruktor).

Danke für deine Mithilfe!

Also ein "error out" hat mir folgendes ausgegeben, keine Ahnung ob das der Call Stack ist?!

Error calling method EcoChemie.Autolab.Sdk.Instrument.LoadProcedure, (System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht.
Inner Exception: System.Runtime.Serialization.SerializationException: Die Assembly "EcoChemie.Shared70, Version=7.0.3727.18958, Culture=neutral, PublicKeyToken=null" kann nicht gefunden werden.) <append><b>System.Runtime.Serialization.SerializationException</b> in Load Procedure.vi->[TN#5] Measuring Complete Example(A).vi

Da steht, dass er die Assembly "Eco...." nicht finden kann, die liegt aber in dem gleichen Ordner wie das ausgeführte .vi ??! In dem Ordner liegen alle Dateien, die in dem SDK vorhanden waren. So müsste LV doch eigentlich alles finden?

(05.07.2012 13:40 )Woodie schrieb:  Also ein "error out" hat mir folgendes ausgegeben, keine Ahnung ob das der Call Stack ist?!

ja, das ist schon besser, respektive gibt mehr an Info her.

(05.07.2012 13:40 )Woodie schrieb:  Da steht, dass er die Assembly "Eco...." nicht finden kann, die liegt aber in dem gleichen Ordner wie das ausgeführte .vi ??! In dem Ordner liegen alle Dateien, die in dem SDK vorhanden waren. So müsste LV doch eigentlich alles finden?

Ja, eigentlich sollte er jetzt alles finden.
Was jetzt noch sein kann: die verwendete dll (die in deinem VI) wurde mit der CLR 2.0 erstellt, weswegen dein Program zur Kompilierzeit keinen Fehler ausgibt. Wenn jetzt aber die "Eco.." dll mit der CLR4.0 erstellt wurde, dann müsstest du dein LabVIEW so konfigurieren, dass es das .NET 4.0 framework verwendet.

Sollte das nicht das Problem lösen, dann kann's haarig werden....
Dann besteht noch die Möglichkeit, dass die "Eco..." dll weitere "unmanaged" dlls benötigt. Die kannst du mit dem Dependency Walker ausfindig machen.
Gerne fehlt das "Microsoft Visual C++ 2008 Redistributable Package" oder das "Microsoft Visual C++ 2010 Redistributable Package"...

Wenn das auch nichts hilft, na dann wird's noch haariger...

(05.07.2012 14:14 )&amp;lt;&amp;lt;oenk&amp;gt;&amp;gt; schrieb:  Was jetzt noch sein kann: die verwendete dll (die in deinem VI) wurde mit der CLR 2.0 erstellt, weswegen dein Program zur Kompilierzeit keinen Fehler ausgibt. Wenn jetzt aber die "Eco.." dll mit der CLR4.0 erstellt wurde, dann müsstest du dein LabVIEW so konfigurieren, dass es das .NET 4.0 framework verwendet.

Damit meinst du die "labview.exe.config" aus deinem letzten Link oben? Die habe ich schon zu Beginn erstellt, als es Probleme gab, bei der Umstellung LV7.1->2011.... Also daran dürfte es dann eigentlich auch nicht mehr liegen.

(05.07.2012 14:14 )&amp;lt;&amp;lt;oenk&amp;gt;&amp;gt; schrieb:  Dann besteht noch die Möglichkeit, dass die "Eco..." dll weitere "unmanaged" dlls benötigt. Die kannst du mit dem Dependency Walker ausfindig machen.
Gerne fehlt das "Microsoft Visual C++ 2008 Redistributable Package" oder das "Microsoft Visual C++ 2010 Redistributable Package"...

Dann guck ich mal was der dependency walker so kann,... die Hoffnung stirbt ja zu letzt, oder so
Und nach dem "Microsoft Visual C++ 2008 Redistributable Package" suche ich auch, was auch immer das mit LV zu tun hat, man muss ja nicht alles verstehen

Ich dreh ab, warum muss das immer so ein HickHack werden...

Sooo,
also die C++ Redistributable Packages habe ich installiert, Fehlanzeige...
Mit dem Dependency Walker habe ich die paar .dlls kontrolliert und da fehlten tatsächlich irgendwelche dlls. Die habe ich, bis auf zwei, installiert. Die letzten beiden API-MS-WIN-SECURITY-BASE-L1-1-0.DLL und API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL habe ich aber bei keiner vertrauenswürdigen Seite gefunden und daher erstmal weggelassen. Bei Microsoft habe ich gesucht und die beiden dlls immer nur im Zusammenhang mit Vista und Win 7 gefunden. Habe aber hier XP auf dem Messrechner...

Wie auch immer... LabView schmeißt immer noch den Fehler aus. Morgen früh werde ich mal das SDK löschen, nochmal runterladen und installieren. Vielleicht hilfts

Ich hoffe ja noch auf weitere Ideen von euch!!!

Anzeige

(05.07.2012 10:16 )Woodie schrieb:  Hallo zusammen,
ich beschäftige mich erst seit wenigen Wochen mit LabVIEW, komme an sich mittlerweile gut zurecht.
Jetzt habe ich von der Firma AUTOLAB ein Software-Development-Kit runtergeladen um ein Messgerät mit LabVIEW ansteuern und auslesen zu können. Vorteil dieses Kits ist, dass dort schon einige Beispielprogramm SubVi´s und Messsequenzen integriert sind, so dass man eigentlich sofort darauf aufbauen könnte.

Bevor das Ganze aber lief, musste unsere LabVIEW Version von 7.1 auf 2011 gebracht werden (was mich schon graue Haare gekostet hat ).
Dann irgendwann konnte ich ein Beispielprogramm starten und die Kommunikation mit dem Messgerät stand auch, Werte kommen und gehen. ABER: Sobald ich bei diesen Programmen z.B. Prozeduren laden will, oder Messwerte in einen Folder abspeichern möchte, kommt ein Fehler. Klicke ich zweimal auf "weiter" kommt eine weitere Fehlermeldung. Ich hoffe ihr könnte die Fehler lesen. Auf dem Screenshot sieht man auch den "load" Button, der auch solch einen Fehler auslöst.

Woran kann das liegen? Findet LabVIEW vielleicht etwas nicht? Habe öfters gelesen, dass bestimmte Dateien im gleichen Ordner liegen müssen?!
Und dann habe ich, im Zusammenhang mit dem Fehler 1172, was von ".NET Full Trust" gelesen. Was bedeutet das?

Achso, .Net Framework 4.0 habe ich auch schon mal aktualisiert, hat nichts gebracht. Muss ich LabVIEW irgendwie sagen, dass es das .NET 4.0 voll unterstützen soll?

Ich hoffe ihr könnt mir da auf die Sprünge helfen!

Danke und Grüße,
Christian

Ist der Fehler mit der Nummer 1 zuerst? Denn das besagt ganz einfach dass die Referenz zu der "Zu Mehr Spezifischer Klasse" ungültig ist. Wenn das als erstes Auftritt, dann kann danach schon einiges nicht so korrect funktionieren. Wenn es nach dem anderen Fehler auftritt, ist es einfach ein Folgefehler und kann vorläufig ignoriert werden.

Zum Suchen von Assemblies: Windows sucht Assemblies nur im GAC und im Verzeichnis des aktuellen Prozesses. LabVIEW fügt hier noch das Verzeichnis des Projekts hinzu, aber nicht des aktuellen VIs. Dies gilt nur für Assemblies die von anderen Assemblies referenziert werden. Assemblies die Du direkt mit LabVIEW .Net Nodes referenzierst findet LabVIEW schon, oder wenn die verschoben wurden seit dem letzten Mal, moniert es das schon beim Laden.

Installieren von DLLs: die von Dir angesprochenen DLLs sind UnterDLLs von Windows Kernel32.dll. Da etwas zu murksen an Deinem Computer ist die einfachste Weise um ihn vollkommen unbrauchbar zu machen. Windows DLLs können NICHT zwischen Computern ausgetauscht werden, selbst nicht wenn beide Computer dieselbe Betreibssystemversion installiert haben, und bei unterschiedlichen Versionen ist die Katastrophe garantiert vorprogrammiert.
kernel32, user32, gdi32, und Friends sind so mit anderen im System vorhandenen DLLs gekoppelt, dass das Auswechseln von einer davon sehr leicht zu hässlichen Problemen führen kann. Und alles was der Dependency Walker als Abhängigkeiten dieser DLLs sieht sollte man tunlichst ebenfalls die Finger von lassen.

Zudem sind beinahe alle Sites wo man diese "hilfreichen" Windows DLLs downloaden kann nicht nur unzuverlässig, sondern beinahe garantiert verseucht. Entweder handelst Du Dir durch einen Click auf den falschen Knopf (der eigentlich Download Button ist meist gut versteckt zwischen unzähligen anderen, viel grösseren Download Buttons, wenn überhaupt vorhanden) eine Spamware, einen Trojan oder Schlimmeres ein. Zudem ist die Wahrscheinlichkeit dass die entsprechende DLL selber etwas anderes ist dann was sie vorgibt ziemlich gross. Auch versuchen einige dieser Sites durch Lecke im Browser versteckte Dinge auf Deinen Computer zu laden. Selbst wenn Du keinen falschen Button klickst und keine DLL herunterlädst kann Dein Computer noch verseucht werden.

(06.07.2012 08:04 )rolfk schrieb:  Ist der Fehler mit der Nummer 1 zuerst? Denn das besagt ganz einfach dass die Referenz zu der "Zu Mehr Spezifischer Klasse" ungültig ist. Wenn das als erstes Auftritt, dann kann danach schon einiges nicht so korrect funktionieren. Wenn es nach dem anderen Fehler auftritt, ist es einfach ein Folgefehler und kann vorläufig ignoriert werden.

Ja, der Fehler kommt zuerst! Was heißt, die Referenz ist ungültig?

(06.07.2012 08:04 )rolfk schrieb:  Zum Suchen von Assemblies: Windows sucht Assemblies nur im GAC und im Verzeichnis des aktuellen Prozesses. LabVIEW fügt hier noch das Verzeichnis des Projekts hinzu, aber nicht des aktuellen VIs. Dies gilt nur für Assemblies die von anderen Assemblies referenziert werden. Assemblies die Du direkt mit LabVIEW .Net Nodes referenzierst findet LabVIEW schon, oder wenn die verschoben wurden seit dem letzten Mal, moniert es das schon beim Laden.

Ja das sehe ich beim Laden, wenn er sich alles notwendige zusammensucht. Wenn er was nicht im vermuteten Ordner findet, dann zeigt er mir an, wo er es stattdessen hergeladen hat. Wenn er beim Laden alles gefunden hat, dann dürfte er doch später beim Ausführen eigentlich keine Probleme mit den Bezügen haben oder?

(06.07.2012 08:04 )rolfk schrieb:  Installieren von DLLs: die von Dir angesprochenen DLLs sind UnterDLLs von Windows Kernel32.dll. Da etwas zu murksen an Deinem Computer ist die einfachste Weise um ihn vollkommen unbrauchbar zu machen. Windows DLLs können NICHT zwischen Computern ausgetauscht werden, selbst nicht wenn beide Computer dieselbe Betreibssystemversion installiert haben, und bei unterschiedlichen Versionen ist die Katastrophe garantiert vorprogrammiert.
kernel32, user32, gdi32, und Friends sind so mit anderen im System vorhandenen DLLs gekoppelt, dass das Auswechseln von einer davon sehr leicht zu hässlichen Problemen führen kann. Und alles was der Dependency Walker als Abhängigkeiten dieser DLLs sieht sollte man tunlichst ebenfalls die Finger von lassen.

Zudem sind beinahe alle Sites wo man diese "hilfreichen" Windows DLLs downloaden kann nicht nur unzuverlässig, sondern beinahe garantiert verseucht. Entweder handelst Du Dir durch einen Click auf den falschen Knopf (der eigentlich Download Button ist meist gut versteckt zwischen unzähligen anderen, viel grösseren Download Buttons, wenn überhaupt vorhanden) eine Spamware, einen Trojan oder Schlimmeres ein. Zudem ist die Wahrscheinlichkeit dass die entsprechende DLL selber etwas anderes ist dann was sie vorgibt ziemlich gross. Auch versuchen einige dieser Sites durch Lecke im Browser versteckte Dinge auf Deinen Computer zu laden. Selbst wenn Du keinen falschen Button klickst und keine DLL herunterlädst kann Dein Computer noch verseucht werden.

Ja, sowas dachte ich mir schon, weswegen ich erstmal die Finger davon gelassen habe...

Also was kann ich noch probieren?

Hast du beim SDK ein Beispielprogramm, dass als exe ausführbar ist?
Wenn ja, läuft das ohne Probleme?

Zum Referenzieren:
was du mal probieren kannst: kopiere dir die SDK-dlls ins LabVIEW-Programmverzeichnis (dort wo die LabVIEW.exe ist) und merke dir was du kopiert hast, damit du's nachher wieder löschen kannst. Wenn es dann funktioniert werden die dlls nicht richtig erkannt und du kannst dir entweder einen C#Wrapper schreiben, der dir die Assemblies dynamisch in deine AppDomain lädt (so wie zB hier beschrieben stackoverflow.com). Oder du schreibst dir einen Wrapper, der dir für den aktuellen Prozess die Umgebungsvariablen um den aktuellen Pfad erweitert.

(06.07.2012 09:19 )Woodie schrieb:  Ja, der Fehler kommt zuerst! Was heißt, die Referenz ist ungültig?

Ja!

(06.07.2012 09:19 )Woodie schrieb:  Ja das sehe ich beim Laden, wenn er sich alles notwendige zusammensucht. Wenn er was nicht im vermuteten Ordner findet, dann zeigt er mir an, wo er es stattdessen hergeladen hat. Wenn er beim Laden alles gefunden hat, dann dürfte er doch später beim Ausführen eigentlich keine Probleme mit den Bezügen haben oder?

So einfach ist das nicht. Wenn Du eine Assembly in LabVIEW referenzierst, weiss LabVIEW das und probiert sie zu laden, und wenn es die Assembly nicht findet sagt es Dir das. Wenn die Assembly aber anwesend ist aber ihrerseits eine andere Assembly benötigt weiss LabVIEW nichts davon. Es muss sich auf Windows verlassen dass es die Assembly lädt. Wenn Windows da nichts findet dann schlägt entweder das Laden der ersten Assembly fehl, wobei Windows nicht sehr mitteilsam ist sondern LabVIEW nur sagt, sorry Deine Assembly konnte nicht geladen werden, oder wenn es eine dynamische Referenz ist die erst zur Laufzeit geladen werden soll, bekommst Du einen Runtime Fehler. Was für ein Fehler das ist ist ganz der Fantasie des ursprünglichen Assemblyprogrammierers überlassen.

(06.07.2012 09:19 )Woodie schrieb:  Also was kann ich noch probieren?

Rasufinden welche Assemblies noch indirekt benötigt werden und diese ins LabVIEW oder Projekt Verzeichnis legen. Windows sucht nicht im aktuellen Verzeichnis oder im Verzeichnis der referenzierenden Assembly.