Project dependencies issue

[wire man]

I am having a problem locating & removing a dll dependency within my project. When the dependencies area loads I have a single dll that appears.The project lists the dll's path as dll_name.dll which confuses me because the path doesn't start with C:/ or D:/ or something which makes it hard to locate on my hard drive. Searching for the dll's callers brings up several VI's but these VI's never call the dll that is loaded into the dependencies. I'm running LabView 2010 on XP and the VI's are third party VI's used for interfacing with some hardware. If anyone knows how I can remove or locate this dll please let me know.

[wire man]

Also, clicking "remove from project" causes the dll to be loaded right back into the dependency list.

[RavensFan]

This third party driver, is is part of a LabVIEW library file?  If the library is loaded, it will load the dependencies in it even if you aren't using any VI's that call the .dll.

Why are you trying to eliminate the dependency?

[wire man]

The driver is not a part of a library file and the VI's that call are not either, though some are polymorphic.

I'm trying to remove the dependency because it causes the executable to not run correctly.

Most of the 3rd party VI's in the project have been linked with the correct dll but the main VI is still somehow calling the non-existent dll that can't be removed. Doing a search for the call library function in the main VI yields no results.

[LV_Pro]

Have you "right clicked" on it and done a "Find Callers" or "Show in File View"? Sorry if this is obvious.

[Jackie_B]

When you say that this causes the executable to not run correctly, what do you mean? Is there an associated error that is displayed? Is this causing a problem when you build the executable or just run it?

[wire man]

To answer your questions:

Using the right click "find callers" technique I had narrowed it down to a single VI (the main VI) which never calls the dll (The main has no call library function nodes being used). Upon further trial and error I was able to "remove" the incorrect dll path from my project by changing the dll location in a VI containing all of the 3rd party VI's (including ones not used by my project) and hitting save.

I put the above (remove) in quotations becaues now everytime the executable builds it builds with 2 warnings in regards to the dll location descrepency. The warning states that the old incorrect dll location will no longer be used but the new correct dll location will be used. Also, the executable is able to run but the 3rd party VI's which use the call library function nodes (which use the correct dll location) spit out an error so the hardware does not function.

I tested out the same thing in 8.6 with no errors. I received several updated 3rd party LabVIEW support files from the vendor this afternoon and will test it out first thing in the morning. I'm curious if it's just the vendors support files causing the error or if LabVIEW 2010's project has a weird bug in it.

[Jackie_B]

Hi Wire Man, 

You said that when you load your dependencies, there is only a single DLL that displays. However, you mention that other 3rd party Vis do use call library function nodes. But there is only one DLL, which leads me to believe that those Vis are trying to call that DLL. When you clicked on the find callers, it makes sense that it would lead you to the main Vi, which includes all the subVis that are calling the DLL. What is the name of this DLL? 

Something you could do is to use a Dependency Walker (found online) to determine if the DLL is a dependent of this project. If it is, then it definitely should not be deleted. 

I am still not understanding what problems this was causing in the first place. Did you receive an error message that made you to want to delete this dependency? Did the executable not build correctly? It seems that changing the filename has caused more errors. Did you simply build this application in 8.6 as it was originally or did you go through all the steps you've gone through, including changing the DLL filename, in 8.6 and have a successful build?

Please share the results of your test as well as the above information.

Regards, 
Jackie B

[wire man]

Sorry for the confusion. There was one dll of interest with 2 instances/paths loading into the project. One was moved out of the dependencies area and the 3rd party VI's that are used in my program call this dll correctly. The other dll was in the dependencies area and its only caller was my main VI which does not actually call the dll, nor do any of its SubVI's. I was able to fix this by modifying the dll location in a 3rd party VI which contained all of the other 3rd party VI's. My guess was that there was a weird dependence between one of the 3rd party polymorphic VIs used in my program.

In 8.6 I only had to include the main VI and let the project locate all other dependencies. I then built and ran the 8.6 executable and was able to correctly operate the hardware cards the software interfaces with.

Back in 2010 after the dll dependecy issue was resolved I then had an issue with running the actual executable. Yesterday running the executable was returning an error originating from the call library node which called the dll that was giving me problems before. This issue was fixed after receiving some updated files from the vendor.

Now I have a new problem. Upon running the executable I received a slew of errors regarding class method calling errors within the dll I was having dependency problems with earlier. Tomorrow I will install an updated software package supplied by the vendor and see if the issue can be resolved.

I'm going to have to check out that dependency walker program, thanks for the info!

[Jackie_B]

Hi Wire Man, 

Please let me know the results of the updated software installation. If this does not solve the problem, please send me a screenshot of all errors you are receiving, including the class method calling errors. Additionally, please send a screenshot of your project with all the folders expanded (so that dependencies, subVIs, etc are in view). Good luck! 

Regards, 

Jackie B