Neue Abhängigkeiten nach Umstellung von LV12 nach LV14

Hallo zusammen,
vielleicht kann mir wer von euch das beantworten. Ich habe ein Projekt von nach umgestellt.
Nachdem habe ich festgestellt das im Projekt Explorer unter Anhängigkeiten zwei neue DLL eingebunden wurden.
Am Quellcode wurden keine Änderungen durchgeführt.
Es ist Advapi32.dll und kernel32.dll.
Für was oder von wem werden diese im Projekt bzw. unter benötigt?
Zudem fand ich diese Links ?:
http://www.file.net/prozess/advapi32.dll.html
http://www.heise.de/tp/artikel/5/5274/1.html

(18.12.2014 16:40 )Hubert R. schrieb:  Hallo zusammen,
vielleicht kann mir wer von euch das beantworten. Ich habe ein Projekt von nach umgestellt.
Nachdem habe ich festgestellt das im Projekt Explorer unter Anhängigkeiten zwei neue DLL eingebunden wurden.
Am Quellcode wurden keine Änderungen durchgeführt.
Es ist Advapi32.dll und kernel32.dll.
Für was oder von wem werden diese im Projekt bzw. unter benötigt?
Zudem fand ich diese Links ?:
http://www.file.net/prozess/advapi32.dll.html
http://www.heise.de/tp/artikel/5/5274/1.html

Die Links, vor allem der zweite, sind vollkommen irrelevant (schau mal das Datum an! 1999).

Diese zwei DLLs sind standard DLLs von Windows und sollten NIE mit einer Application distributiert werden.

1) ist das illegal weil ein Bestandteil von Windows
2) ist es in allen Fallen eine Katastrophe! LabVIEW wird dann die private Kopie laden die in den meisten Fällen völlig inkompatibel mit dem Rest der Windwos Installation ist, aber selbst wenn die Versionen stimmen, kommt es zu katastrophalen Fehlern, weil die zwei seperaten DLLs die gleichen Systemresourcen zu verwalten versuchen und sich dabei hässlich in die Quere kommen.

Der Grund warum diese DLLs in Deine Abhängigkeiten gekommen sind ist nicht ganz einfach zu eruieren (wahrscheinlich hat es mit Pfadänderungen im Zusammenhang mit 32 Bit Windows zu 64 Bit Windows zu tun) aber relative einfach zu beheben.

- Im Projekt (das Du ja offensichtlich verwendest) suche unter den Abhängigkeiten (Dependencies) diese zwei DLLs.
- Lass Dir mit der rechten Maustaste anzeigen wo die alles benützt werden.
- Öffne diese VIs und suche die Call Library Nodes.
- Öffne die Konfiguration der Call Library Nodes und schaue ob dort der Library Path eine Referenz zu diesen zwei DLLs enthält.
- Wenn dem so ist, ändere den Pfad dahingehend, dass nur der DLL Name ohne irgendwelchen Pfad dort steht.
- Schliesse den Konfigurationsdialog und speichere das VI ab.
- Wenn Du den Konfigurationsdialog wieder öffnest wirst Du zwar wiederum den ganzen Pfad zu der DLL im Systemdirecotry sehen, aber LabVIEW hat intern nur den DLL Namen gespeichert, so dass es auch auf anderen System wo ein anderer Systempfad gilt noch gut geht. Aber wenn Du nun an diesem Pfad etwas editierst ohne ihn wieder auf nur DLL Namen zu setzen speichert LabVIEW wieder den ganzen Pfad und das Problem kehrt zurück.

Der Hintergrund ist der, dass LabVIEW Library Path Namen die nur den Library Namen enthalten als System Libraries behandelt. Diese müssen an einer der Standardorten liegen wo Windows nach DLLs sucht. Aber LabVIEW kopiert diese DLLs nicht in einen Application Build. Wenn der complete Pfad angegeben wird, selbst wenn der im Systemdirectory liegt, behandelt LabVIEW diese Abhängigkeit als applikationsprivat und fügt Sie in den Applikation Build mit ein.

Hallo Rolf,
erst mal danke für deine ausführliche Beschreibung.
Ich werden das wie du es vorgeschlagen hast überprüfen.

LG. Hubert

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

(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.

Das mit der Advapi32.dll unter den Dependencies kenne ich auch (auch schon unter LabVIEW 2013). Beim Erstellen einer Exe wird diese DLL aber trotzdem nicht mitkopiert. Auch in einem erstellen Installer ist sie nicht enthalten.

Ich hatte zumindest bisher keine Probleme.

Gruß, Jens

Hallo Jens,
ich bin von LV2012 auf LV2014 umgestiegen da mir das LV2013 kaum Vorteile gebracht hat. Ich werde mich diesbezüglich mal bei NI erkundigen. Wenn ich dann mehr weiß poste ich es.

Gruß Hubert

(09.01.2015 13:01 )jg schrieb:  Das mit der Advapi32.dll unter den Dependencies kenne ich auch (auch schon unter LabVIEW 2013). Beim Erstellen einer Exe wird diese DLL aber trotzdem nicht mitkopiert. Auch in einem erstellen Installer ist sie nicht enthalten.

Ich hatte zumindest bisher keine Probleme.

Gruß, Jens

Wenn ein VI von einer DLL Gebrauch macht, ist diese immer in den Dependencies sichtbar. Ob sie aber in den Applicationbuild mitgenommen wird hängt davon ab ob sie mit komplettem Pfad oder nur mit Namen in der Call Library Node referenziert wird.

Ich habe gerade einen Test gemacht und ein Projekt, welches auf Grund von Registry-VIs die Advapi32.dll verwendet, mit verschiedenen LabVIEW-Versionen geöffnet. Ergebnis:

LabVIEW 2010: Advapi32.dll ist unter den Dependencies gelistet.
LabVIEW 2011: Advapi32.dll ist unter den Dependencies gelistet.
LabVIEW 2012: Advapi32.dll ist NICHT unter den Dependencies gelistet.
LabVIEW 2013: Advapi32.dll ist unter den Dependencies gelistet.

Sieht für mich also so aus, als ob da ein Bug in LabVIEW 2012 vorliegt. Die Advapi32.dll wird übrigens in den Registry-VIs nicht mit dem Namen (ohne vollen Pfad) aufgerufen, weshalb sie auch nicht mit in einen Installer gepackt wird (wie Rolf geschrieben hat).

Fazit: Ich würde mir keine großen Gedanken machen und das Ganze als Unschönheit von abtun.

Gruß, Jens

Hallo Jens,
nach Rücksprache mit NI hat sich das bestätigt was du geschrieben hast.

Gruß Hubert