Aplikacja LabView i użycie DLL - problem z umiejscowieniem

[Goraith]

Witam Wszystkich,

W swojej aplikacji korzystam z wielu DLL zgromadzonych w jednym katalogu. Jeżeli aplikację umieszczę w tym samym katalogu co DLL'ki wszystko działa.
Jeżeli natomiast umieszczę aplikację poza tym katalogiem - to pomimo że w LV w sekcji Tools/Advance/.NET Assembly References położenie bibliotek jest określone prawidłowo - aplikacja zgłasza błąd "Could not load file or assembly xxx.
Nie spotkaliście się z czymś podobnym?
Czy możliwe jest aby błąd był spowodowany błędną kompilacją dll a nie ustawieniami aplikacji w LV ?

Pozdrawiam i dziękuję za wszelkie wskazówki.
Goraith

[mac_671]

Czy jestes pewny ze
DLL ktore uzywaz to DLL .NETowe? Czy tez sa to DLL stworzone "old-schoolowo" ( czyli np tworzone w standardowym C++ przez kompilator np Borlanda )?
wbrew pozorom nie sa to takie same DLL i dzialaja zupelnie inaczej
Najlepszy byl by jakis przyklad tego VI'a.

[Nowszy]

Witam

Czy te DLL-ki tworzysz sam? Napisz dokładnie, w którym przypadku nie działa - kiedy przenosisz vi, zostawiasz biblioteki, przenosisz biblioteki zostawiasz vi-a, czy oba na raz?

Rozumiem, że wywołujesz te biblioteki korzystając z Call Library Function - może po prostu nie zmieniasz ścieżki do DLL-ki?

[Goraith]

Czy jestes pewny ze
DLL ktore uzywaz to DLL .NETowe? Czy tez sa to DLL stworzone "old-schoolowo" ( czyli np tworzone w standardowym C++ przez kompilator np Borlanda )?
wbrew pozorom nie sa to takie same DLL i dzialaja zupelnie inaczej
Najlepszy byl by jakis przyklad tego VI'a.

Na 100% są pisane w .NETu. Standardowo korzystam w aplikacji z palety Communication/.NET/Property Node oraz Invoke Node

Witam
Czy te DLL-ki tworzysz sam? Napisz dokładnie, w którym przypadku nie działa - kiedy przenosisz vi, zostawiasz biblioteki, przenosisz biblioteki zostawiasz vi-a, czy oba na raz?
Rozumiem, że wywołujesz te biblioteki korzystając z Call Library Function - może po prostu nie zmieniasz ścieżki do DLL-ki?

Nie działa w przypadku kiedy przeniosę vi do innego katalogu - pomimo tego że w menu Tools / Advanced / .NET Assembly References ścieżki do assemblies są ustawione prawidłowo.
Kiedy przerzucę dll do innego katalogu to też nie działa - vi i dll muszą byc w tym samym katalogu - jedynie wtedy wszystko działa poprawnie.
Dzięki,
pozdrawiam, Goraith

[Nowszy]

Szczerze mówiąc nie wiem gdzie zmieniasz ścieżki do .NET assemblies - jakiej wersji LV używasz? U mnie (8.6 i 8.5.1) w Tools->Advanced nie ma opcji .Net Assembly References. Chociaż nie da się ukryć, że specem od .NET to ja nie jestem
Może to pomoże:
- Cytat z helpa: Using .NET Assemblies with LabVIEW (..) Assemblies can be public or private. Private assemblies are usually located in the same directory as the application directory. Public assemblies are located in a system-wide global cache called the Global Assembly Cache (GAC). The developer of the application typically writes private assemblies for use by that application. The developer of the assembly also decides the version control. The assembly name is the filename, minus any file extension, of the file that contains the manifest. (..) Referencing Private .NET Assemblies To create a reference to a private .NET assembly, place a Constructor Node on the block diagram and specify the desired .NET assembly. LabVIEW automatically stores the relative path from the assembly to the VI that contains the .NET object so no manual registration is necessary.
File Management with .NET Assemblies LabVIEW .config files can apply to a saved project, shared library, or stand-alone application. Refer to Configuring a .NET Client Application for more details about using configuration files with .NET.
If you move a VI that uses a private assembly to a different folder or computer, you must keep the assembly in the same location relative to the VI. If LabVIEW cannot find an assembly file in the GAC, the directory that contains the project, or the relative path stored in the VI, LabVIEW prompts you to find the assembly file.
If you build a VI that uses a private assembly into a shared library or stand-alone application, LabVIEW copies the associated private .NET assembly files to the data subdirectory in the same directory as the library or application.
I jeszcze ten dokumencik: http://digital.ni.com/public.nsf/allkb/ ... enDocument

[Goraith]

Szczerze mówiąc nie wiem gdzie zmieniasz ścieżki do .NET assemblies - jakiej wersji LV używasz? U mnie (8.6 i 8.5.1) w Tools->Advanced nie ma opcji .Net Assembly References. Chociaż nie da się ukryć, że specem od .NET to ja nie jestem
Może to pomoże:
- Cytat z helpa: Using .NET Assemblies with LabVIEW (..) Assemblies can be public or private. Private assemblies are usually located in the same directory as the application directory. Public assemblies are located in a system-wide global cache called the Global Assembly Cache (GAC). The developer of the application typically writes private assemblies for use by that application. The developer of the assembly also decides the version control. The assembly name is the filename, minus any file extension, of the file that contains the manifest. (..) Referencing Private .NET Assemblies To create a reference to a private .NET assembly, place a Constructor Node on the block diagram and specify the desired .NET assembly. LabVIEW automatically stores the relative path from the assembly to the VI that contains the .NET object so no manual registration is necessary.
File Management with .NET Assemblies LabVIEW .config files can apply to a saved project, shared library, or stand-alone application. Refer to Configuring a .NET Client Application for more details about using configuration files with .NET.
If you move a VI that uses a private assembly to a different folder or computer, you must keep the assembly in the same location relative to the VI. If LabVIEW cannot find an assembly file in the GAC, the directory that contains the project, or the relative path stored in the VI, LabVIEW prompts you to find the assembly file.
If you build a VI that uses a private assembly into a shared library or stand-alone application, LabVIEW copies the associated private .NET assembly files to the data subdirectory in the same directory as the library or application.
I jeszcze ten dokumencik: http://digital.ni.com/public.nsf/allkb/ ... enDocument

No ja niestety jadę na wersji 7.1.
Ale dzięki za helpowy cytat - co prawda to się odnosi do tworzenia dll przy pomocy LabView ale podział na private i public istnieje i w .NET - także może to dobry trop.
Sprawdzę i dam znac, Pozdrawiam, Goraith

[mac_671]

Zwroc uwage na element cytatu o GAC.

Aby twoje bibloteki byly widoczne dla kazdej aplikacji, mozesz zarejestrowac je w Global assembly cache.

Robi sie to tym toolem:
http://msdn.microsoft.com/en-us/library/ex0ss12c.aspx

Jesli masz Visual Studio na bank bedziesz mial tego toola zainstalowanego. Bo nie dam głowy czy jest on czescia standardowej instalacji .NET framework.

Jezeli nie to wiedz, że:
Tool ten jest czescia Windows SDK ktore mozna sciagnac za darmo ze stromy microsoftu jezeli posiada sie legalna wersje systemu operacyjnego windows XP lub nowszgo.

Dodanie twoich bibliotek do GAC powinno rozwiazac twoj problem.

Nie mam dostepu do LV do poniedzialku wiec wiecej nie pomoge.

Daj znac czy zarejestrowanie bibliotek w GAC rozwiazlo problem.

mac_671

[Goraith]

Zwroc uwage na element cytatu o GAC.
Aby twoje bibloteki byly widoczne dla kazdej aplikacji, mozesz zarejestrowac je w Global assembly cache. [...]
Daj znac czy zarejestrowanie bibliotek w GAC rozwiazalo problem.
mac_671

Witajcie,
Problem rozwiązany - biblioteki dll muszą się znajdowac w katalogu z którego jest uruchamiane główne vi (vi które są wywoływane przez główne vi mogę znajdowac się gdziekolwiek).
Dodanie dll do GACu też rozwiązuje problem.
Wielkie dzięki dla Was - Nowszy oraz mac_671 . Pozdrawiam, Goraith
PS Ciekawy jestem w jakim celu zostało umieszczone w menu Tools / Advanced... / .NET Assembly References w wersji LabView 7 - tym bardziej jak Nowszy stwierdził, że w wersji 8 tego nie ma ??? W celu kompilacji vi ?