Odd file locations in Files view of Project Explorer

[colorimeter]

I am a novice, trying to straighten out some dll and cross linking issues in an inhereted LabVIEW 2017 set of code consisting of many lvproj files, vi's and subvi's, and dll's.

I've run into something odd: When I look at one of the projects I've been trying to fix in the Items view of Project Explorer, under Dependencies the main dll is listed four times, all with "Warning: has been deleted, renamed, or moved on disk".

When I then look at the project in the Files view of Project Explorer, I see that two of these instances are listed under C:\Users\MyName, where MyName is my own Windows login, under subdirectories where they were earlier today. So that makes sense.

But the other two instances are listed under C:\Users\AnotherPersonsName, where AnotherPerson is no longer at the company. He wrote the version of the software that I checked out from version control and am editing on my machine.

Why would his local path be listed for the dll? 

Also, all 4 listings of the dll in Dependencies say there are "No Callers", but I can't figure out how to delete them from Dependencies. 

[Bob_Schor]

Sigh.  Getting files "lost" and (at a later time "restored") in a LabVIEW Project can be something of a challenge.  For this reason, I try to keep all of the files I need for my Project within my Project file, unless they are in a known Library that is installed on all of the Target machines.

I usually do this "manually", a file at a time.  The question about a path apparently "hard-coded" in a DLL may mean that the path was hard-coded into the DLL.  If so, you may need to open and edit the DLL itself.  [I recall, vaguely, seeing something like this when using third-party drivers that similarly used absolute path names, making it hard to use them).

Bob Schor

[colorimeter]

I beleive all 4 instances of the dll are the exact same file, so it seems like the path couldn't be stored inside the dll (that's what you meant by editing the dll, right?). 

Instead of having the copies of the dll in Dependencies, I would like to add it (and some other dll's it calls) under Build Specification > Source Files > Always Included. Therefore I would like to first delete it from Dependencies. Is this possible?

[Bob_Schor]

---

@colorimeter wrote:

I would like to add it (and some other dll's it calls) under Build Specification > Source Files > Always Included. Therefore I would like to first delete it from Dependencies. Is this possible?

---

Often, it is possible.  When I build executables, I usually specify only the Top-Level VI on the right-hand side.  I let the natural linkage process to bring in all the sub-VIs, drivers, etc. that are needed.  This works (for me) 95% of the time.

One of my colleagues uses a USB DAQ device that is not made by NI, and has its own driver.  I recall that sometimes we needed to specify its driver (or maybe a DLL, I don't remember), but this was not common.

I'd say, try doing a Build with only the top-level VI specified, and nothing in Always Included.  See if that works -- if it does, it will simplify your life.

Bob Schor

[tst · Accepted solution]

Items appearing in the dependencies section are (surprise) dependencies of the items in your project.

You should be able to right click the copies of the DLLs with the warning to find which items in the projects are the reason they are a dependency.

Then, you can go into those items (that would be VIs, in your case) and find where the DLL is called. It would be useful if the system would show you the actual location in the VI, but it doesn't.

[colorimeter]

For each of the 4 instances of the 'missing' dll in Dependencies, I was able to right click and get 'Why is this item in Dependencies?' This returned a list of several vi's. I opened each of those vi's in turn. Each time I got a warning that the dll was loaded from a new dependency path (the one I wanted), rather than the expected dependency path (a subdirectory of AnotherPerson, which I don't want). I made sure the Run arrow wasn't broken, which it never was, then saved the vi. Once I did this for all the listed vi's, the 4 instances of the dll had disappeared from Dependencies.

So I am thinking this is fixed.