DLL mit niedrigerer Versionsnummer einbinden

Hallo @ all

Mit Hilfe des Constructor Node binde ich eine DLL ein, die mir die Kommunikation mit den verschiedenen Datenbanken abnimmt und den .NET Datentyp "Datatable" umwandelt.
Wenn ich z.B. mit Version 1.0.3.0 arbeite und nun eine ältere DLL (V.1.0.1.0) einbinden möchte bekomme ich immer die Meldung, dass die neuere Version verwendet wird. Schließe ich LabVIEW komplett, dann kann ich wieder die ältere DLL verwenden.
Gibt es eine Einstellungsmöglichkeit, die die Abfrage der Versionsnummer ausschaltet, damit ich nicht immer die Entwicklungsumgebung schließen muss?

Im Anhang ist ein Bild der Meldung.
Danke für eure Antworten.

Gruß
Stefan

' schrieb:Hallo @ all

Mit Hilfe des Constructor Node binde ich eine DLL ein, die mir die Kommunikation mit den verschiedenen Datenbanken abnimmt und den .NET Datentyp "Datatable" umwandelt.
Wenn ich z.B. mit Version 1.0.3.0 arbeite und nun eine ältere DLL (V.1.0.1.0) einbinden möchte bekomme ich immer die Meldung, dass die neuere Version verwendet wird. Schließe ich LabVIEW komplett, dann kann ich wieder die ältere DLL verwenden.
Gibt es eine Einstellungsmöglichkeit, die die Abfrage der Versionsnummer ausschaltet, damit ich nicht immer die Entwicklungsumgebung schließen muss?

Im Anhang ist ein Bild der Meldung.
Danke für eure Antworten.

Gruß
Stefan

Das ist Windows selber. LabVIEW macht denke ich mal keine Versionschecks. Das Problem kommt daher das die DLL schon im Speicher liegt und wenn Du dann die alte Version laden willst merkt Windows das und linkt anstelle davon zu der bereits im Speicher vorhandenen. Solange Du also schon ein VI geladen hast das von der selben DLL Gebrauch macht ist da nichts zu machen. Ansonsten kommen zwei mögliche Dinge ins Spiel. LabVIEW macht zumindest bei herkömmlichen DLLs (nicht sicher ob das bei .Net auch so ist) dass eine einmal geladene DLL im Speicher bleibt bis das letzte VI das sie anspricht völlig ausgeladen wurde.
Die andere Ursache ist wahrscheinlich ein Caching von Windows selber für .Net DLLs per Prozess. In dem Falle hilft tatsächlich nur noch das Abschliessen des Prozesses, sprich der Applikation.

Rolf Kalbermatter

' schrieb:Die andere Ursache ist wahrscheinlich ein Caching von Windows selber für .Net DLLs per Prozess. In dem Falle hilft tatsächlich nur noch das Abschliessen des Prozesses, sprich der Applikation.

Hallo Rolf
Danke für deine Antwort.
Ich weis es ist ein wenig spät für eine Rückmeldung, doch besser spät als nie.
Es liegt wie du sagst wohl an Windows, da ich LabVIEW komplett schließen muss und nach erneutem Start geht es ohne Probleme.


Nun hab ich eine neue Frage.

Ist es möglich die von mir verwendete DLL auf einen Server im Netzwerk zu legen, wo die Applikation nur Leserechte hat, und dies dann einbinden und korrekt verwenden?

Es sind ja weitere LabVIEW Prüfstände geplant und bei einer Änderung an der DLL müsste ich dann nur diese ändern und nicht zu jedem Prüfstand rennen und die neue Version lokal abseichern.

Vielen Dank für eure Erkläuterungen.

Gruß Stefan

P.S. Wünsche noch dem ganzen LabVIEWforum-Team und allen Nutzern ein frohes neues Jahr.

' schrieb:Ist es möglich die von mir verwendete DLL auf einen Server im Netzwerk zu legen, wo die Applikation nur Leserechte hat, und dies dann einbinden und korrekt verwenden?

Kenne mich mit .Net wirklich nicht aus aber von dem bischen Erfahrung dass ich im Zusammenhang mit der Einbindung von .Net in LuaVIEW habe scheint es mir dass .Net grundsätzlich nur zwei Lokationen vorsieht. Die eine ist die Global Assembly Cache (GAC) wo nur Assemblies hinterlegt werden können die sogenannt "strongly named" sind.
Der andere Platz ist das Applikationsdirectory selber also dort wo das Executable liegt. Theoretisch kann eine Applikation eine Assembly auch noch von einem spezifischen absoluten Path laden aber MSDN rät die Verwendung dieser Möglichkeit sehr vehement ab.

Rolf Kalbermatter

Danke dir für deine Erläuterung.

Ich habe vom NI Support diesen Link zugesandt bekommen: http://digital.ni.com/public.nsf/allkb/F32...19?OpenDocument

Momentan bin ich in der Endfase meiner Diplomarbeit und habe leider keine Zeit diesen Lösungsweg zu testen.
Mir wurde nur gesagt, wenn dieser Link nicht zur Problemlösung hilft müssen die Jungs von Amerika ran.

Habe diesen Link hier trotzdem eingestellt, damit er vielleicht einem anderen User hilft.

Gruß
Stef