Neue Abhängigkeiten nach Umstellung von LV12 nach LV14

(08.01.2015 13:29 )Hubert R. schrieb:  Hallo Rolf,
ich habe mal 2 Bilder angehängt mit dem Aufrufer und der Konfiguration. Das sieht dann bei mir entsprechend aus, wenn ich dich richtig verstanden habe.
Einen Pfad bekommen ich nicht angezeigt. Würde das dann heißen das ich die Abhängigkeiten im Projekt löschen kann?
Im übrigen mache ich in meiner Applikation keine Reg.-zugriffe. Was ich aber mache, ist das ich mit den Report Vi's arbeite. Diese scheinen dann auch den Reg.-zugriff zu machen.

LG Hubert

Hmm, scheint dass sie irgendwann mal in einer der letzten Versionen die Anzeige des Pfades geändert haben um nur den Namen sehen zu lassen. Nice!
Aber man muss alle VIs einzeln checken in denen diese DLL aufgerufen wird. Eine einzige Referenz mit vollem Pfad ist schon genug um die DLL doch in den Applicationbuild mitnehmen zu lassen.

Man kann Abhängigkeiten nicht einfach löschen. Auch wenn LabVIEW die DLL vom Systemdirectory lädt hat es einen entsprechenden Eintrag in den Dependencies. Das Prinzip is ungefähr so:

Alles was an ausführbarem Code (VIs, externe DLLs, etc) von irgendeinem Item in Deinem Projekt referenziert wird muss entweder explizit im Projekt aufgelistet sein oder wird von LabVIEW in die Dependencies aufgenommen. Wenn etwas in den Dependencies ist dann denkt LabVIEW das es irgendwie notwendig ist. Dinge dort kann man nur entfernen indem man alles was davon direkt oder indirekt Gebrauch macht aus dem Projekt selber entfernt (oder sie explizit ins Projekt einfügt, aber dann sind sie ja ausdrücklich Bestandteil des Projekts und werden auch in den Build mitgenommen).

ADVAPI32.DLL ist aber nötig in Deinem Projekt und deshalb kannst Du das nicht entfernen. Was geändert werden muss ist die eine Referenz die die DLL mit vollem Pfad referenziert und das muss man von Hand machen.

Am besten wäre wenn LabVIEW grundsätzlich alles was aus dem Systemdirectory kommt, nicht in den Applikationbuild mitnehmen würde, aber das wäre nur ein halber Pfusch. Es gibt leider etliche solcher Directories die von Windows alle als Systemdirectory gesehen werden können und um es noch interessanter zu machen kann der User (oder Systemadministrator) da beliebig viele hinzufügen, da alle Directories die in der PATH Environment Variablen stehen auch dazu zählen. Das gründlich und korrekt zu implementiere würde einiges an extra Laufzeit zum Buildprozess hinzufügen und einfach die eine automatische Intelligenz durch eine andere, ineffizientere und viel unflexiblere automatische Intelligenz ersetzen.

PS: Falls Du so auf die Art scheinbar kein VI findest dass einen vollen Pfad zu der DLL hat, musst Du es mal versuchen indem Du jeweils nur jedes einzelne VI direkt öffnest ohne irgendwelche anderen VIs offen zu haben. Eine DLL kann ohne komplizierte Side by Side Architektur (was nicht mal die meisten Programmer bei Microsoft beherrschen) nur einmal in einer Applikation geladen werden. LabVIEW scheint dann den Pfad anzuzeigen von der DLL so wie das erste VI, das in den Speicher geladen wurde, diese referenziert. Sollte aber auch zur Folge haben, dass das oder die VIs die eigentlich einen anderen Pfad haben, dann den angezeigten, nach dem Öffnen des Call Library Node configuration dialogs als modifiziert angesehen werden und wenn man sie dann abspeichert, sollten sie mit dem korrekten Pfad gespeichert werden.