Permanently removing paths that have previously been used / Conflicting Libraries

[MDumas]

So, a while back, I posted this question: https://forums.ni.com/t5/LabVIEW/LabVIEW-using-wrong-paths/m-p/3891146#M1103803 

Until recently, I thought this was fixed, and then I ran into another project that uses those libraries. As you can see in the dependencies picture, the project loaded, and automatically selected files that do not exist. The problem seems to be that despite having removed the files and fixing the dependencies in the vi.lib directory, LabVIEW still is looking at projects and directories that haven't existed in a while. 

The conflicts image shows that it is still looking for directories that don't exist when it's trying to find libraries.

Where does LabVIEW store these directories in its memory, and how can I delete them permanently, so LabVIEW NEVER searches these directories again? 

[winterishere8]

Typically for me, mass-compile fixes most of the things. I believe if you open the project .alias as a text file, you should see the dependencies, no?

[natasftw]

The problem isn't LabVIEW.  It's your project.

The VIs you've got in your project all have relative links in them to their dependencies.  Because you originally placed those libraries elsewhere and then linked your VIs to them, you need to clear up the linking in your VIs.  

You can try the mass compile someone else suggested.  Otherwise, you'll need to clean up the VIs to get them calling things from the correct location.

[MDumas]

That doesn't make any sense. 

If the problem were my project, then I could simply delete it and copy the files from the CD ROM I was given with the code base on it and have no issue. 

Instead what I see is that any project that uses gmath, analysis library, or modulation toolkit has this issue. Even using the resolve conflicts dialog and manually opening and relinking each vi in the project doesn't work. Every time I open the project I have to redo the entire thing.

The mass compile didn't do anything either. 

The only conclusion I can draw from this is that labview itself has decided to use the libraries from that old project by default. So what would cause it to do that?

Going off of what nata said, is it possible that the labview libraries in vi lib are all screwed up?

[natasftw]

Is it possible the VIs in vi.lib are messed up?  Yes.

But, that's an easy test.  Open up a blank project.  Drop a new, blank VI in it.

Add one of these VIs.

Does it add these awkward dependencies?  If so, you need to fix the dependencies in the vi.lib implementation.

Though, if that were the problem I don't think you'd see any benefit from cleaning up the dependencies in the project.

When you talk about the CDROM, is that a LV installation?  Is that some code your group has saved in the past?  What's on that?  If it's a LV installation, I wouldn't expect it to have much, if any, change as the VIs are linking to their dependencies.  If it's code built by your group, it'd explain your problem perfectly.  If the code was saved with bad links and burned to a CD/DVD, it has those bad links.  Each time you pull from that code, you're pulling the bad links.  If that's the case, you should fix the dependencies, re-burn that media, and burn the old one in a fire.

[MDumas]

It turns out some/a lot of the VIs in <VI Lib>/Analysis files point to the old tool that has since been deleted. I'm guessing that choosing to use the libraries that were bundled with that tool broke random links in my LabVIEW installation -- something I had assumed was not possible. 

At this point I'm guessing the only solution is to just completely remove LabVIEW and reinstall it. Either that or I have to open every VI in those directories and relink all of them. 

To answer @natasftw: 

The CDROM is a vendor provided code repository for a product that they were contracted to make for is, so it has been completely isolated from my PC. There's no chance it has ever heard of this older tool. 

Since I'm going to completely reinstall LV, I guess the obvious question is: Is there a way to prevent this in the future? 

[MDumas · Accepted solution]

I had to uninstall and reinstall LabVIEW, and now those issues aren't occurring when I add the same VIs. It must have broken the entire VI Lib. 

So, lesson learned, just say no to vendor code that includes standard LabVIEW libraries but isn't already encapsulated.