LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

dependency to .NET .dll has to be resolved manually upon start

Solved!
Go to solution

Hello,

 

I have a LabView application that depends on a certain .dll to work.

This .dll is in the dependency list.

 

The application works.

 

I created an installer for the application.

I included the installer that installs the .dll file at the end of the LabView installation.

 

The installer works.

The application is created on the computer and also the .dll file is created.

 

The application does work, but asks for the path to the .dll upon every start.

Why is this?

What am I doing wrong here?

0 Kudos
Message 1 of 6
(1,038 Views)
It sounds like the location of the DLL is different in the development environment.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."
0 Kudos
Message 2 of 6
(1,021 Views)
Highlighted
Solution
Accepted by topic author max_
08-27-2015 04:09 PM

The .dll was isntalled via the same installer.

 

solution: add the .dll to the project, which will copy it to the data folder.

 

The .dll does not have to be specified by the user anymore.

The .dll is correctly used (connected hardware works as expected).

 

Downside: Applications bringing their own .dll kind of defeats the point of .dlls, that is: the same code being shared by many applications isntead of duplicating that code for every application.

 

0 Kudos
Message 3 of 6
(1,001 Views)

@max_ wrote:

Downside: Applications bringing their own .dll kind of defeats the point of .dlls, that is: the same code being shared by many applications isntead of duplicating that code for every application.


Yes, but the application still needs to know where to find the DLL.   In .NET, if you want to have a shared DLL, I believe the proper thing to do is to register it in the global assembly cache, which allows all programs to find it by name. Reading up on that should probably get you the info you want.


___________________
Try to take over the world!
0 Kudos
Message 4 of 6
(992 Views)

@tst wrote:

@max_ wrote:

Downside: Applications bringing their own .dll kind of defeats the point of .dlls, that is: the same code being shared by many applications isntead of duplicating that code for every application.


Yes, but the application still needs to know where to find the DLL.   In .NET, if you want to have a shared DLL, I believe the proper thing to do is to register it in the global assembly cache, which allows all programs to find it by name. Reading up on that should probably get you the info you want.


The proper thing to do is to have a redistributable/installer that does its job placing the .dll in the right spot.

0 Kudos
Message 5 of 6
(988 Views)

@max_ wrote:

@tst wrote:

@max_ wrote:

Downside: Applications bringing their own .dll kind of defeats the point of .dlls, that is: the same code being shared by many applications isntead of duplicating that code for every application.


Yes, but the application still needs to know where to find the DLL.   In .NET, if you want to have a shared DLL, I believe the proper thing to do is to register it in the global assembly cache, which allows all programs to find it by name. Reading up on that should probably get you the info you want.


The proper thing to do is to have a redistributable/installer that does its job placing the .dll in the right spot.


And that right spot is indeed the GAC just as mentioned by Yair. It is the only globally accessible location in every version of .Net if you do not want to copy the assembly DLL into your application directory. LabVIEW adds to this the location of the current project file but that is about it. Individual applications can register additional directories with .Net where it should search for assemblies but that only applies for the actual application not for any other.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
0 Kudos
Message 6 of 6
(985 Views)