Struggling with reuse of a userlib that references local DLL

[plyons.gks]

I'm going to try and sum up my problem so it's not too lengthy, but still asks the right question... maybe some of you folks have run into this before or maybe I'm just doing it all kinds of wrong 

I have a device in an old project/system that I need to create a demo for, so that that device's capabilities can be shown outside of a larger system.

It is a usb device that I control using an lvlib that labview made after I pointd it to the DLL driver for the usb device.

The problem I'm having is within the new project, separate from the old project, the "Call Library Function Node"s "Library name or path" path of all the library's vi's  is reffering to a path of the old project, and changing every one of them at a time would take forever.   Is there a way to do this with the entire library? at once?

Also-  When I right click the DLL that is in dependencies (whose path is in the dir of the old project) and select "why is this item in depencies" it shows me a list of those library vi's, with some of which I have already changed the "Library name or path" pointer path to the right dll under the new project.

I hope this is somewhat clear.

If you think I left anything out please let me know, my search results did not turn up much.

thanks

[GabbyG]

I guess I understand.

As far as I know:

Usually Windows searches for DLLs in a known order.

A specific path.

Or current directory and down that tree.

Or in System32 

I am not sure what happens if in the Call Library node is already a fully qualified path ???

What if you try to move the DLL to one of the usual suspects ?

Gabi

[plyons.gks]

I find this really interesting, I went to do a "move on disk" to see if relocating the dll from the old project dir location to where I want it in the new projects dir heirarchy would do it... it didnt have any effect, but when I thought it may be because I was asking LV to move on disk to a location where the dll already existed, I renamed the DLL (the one that i was manualy attempting linking to), the project immediately showed a missing item as expected but the DLL in dependencies (from the old project) was GONE.

I guess it's nice my problem seems to be gone... but I was hoping to have learned something here... I know I'm going to run into this issue again...

kudo to your response!

thanks again

edit: a senior suggested I try this same thing with a later version of LV, I'm doing this in 2011, he siggested it's possible there's a weird bug somewhere... who knows as of now...  I'll download 2013 for my next run of this...

[rolfk]

Windows does not allow to load a DLL with the same name multiple times into the same application unless the application uses something called SxS (Side by Side assemblies) a rather cumbersome technology to prevent the so called DLL hell for end users by creating a super hell for program distributors. The LabVIEW Call Library Node does not support SxS. So if one VI is in memory that references a DLL with a specific path, there can be million other VIs trying to load it from a different path but Windows will simply return the handle to the already loaded DLL and be done with it. The LabVIEW Call Library Node does query the actual DLL path used when you open the CLN configuration dialog, so will revert to whatever location the DLL is currently loaded from. And the DLL will be loaded from whatver location the first VI that gets loaded and which references the DLL will indicate.

So besides renaming the DLL outside of LabVIEW and fixing then all the CLN paths accordingly you can also go a different routhe. Create a single VI (outside of any lvlib to be sure) that references the DLL at the place you want. Add this to an empty project and open it inside the project, then add the lvlib to the same project whose VIs reference the DLL with the same name, but from your old project location. Now load a VI that makes use of all the library VIs. All the library paths should now get updated autimatically to point to the new location since your single dummy VI loaded the DLL from your new location and the other CLNs will be changed accordingly. Save the lvllib and all its VIs.