VI can't find referenced VI, but reference has been removed

[Furbs]

I have a VI in a library that referenced another not in the library. I've passed the library to another user and it complained that it's missing the VI. Makes sense. I then removed the reference to the VI and committed the library again. His project uses the library, but not this particular VI. The project will still periodically complain that it can't run because the VI is missing a reference. If you open the VI, the project will then run because it knows there isn't a reference anymore. I have "Separate Compiled Code" on already. Somewhere there's a cache of this VI's references or something we need to clear out, but I have no idea where. 

Has anyone run into this before?

[Andrey_Dmitriev]

A very first thing to check and refresh dependencies:

In additional, both lvproj and lvlib are just test files with XML, you can check in any editor that all references are really removed.

[wiebe@CARYA]

---

@Furbs wrote:

Somewhere there's a cache of this VI's references or something we need to clear out, but I have no idea where. 

---

Tools>Advanced>Clear Compiled Object Cache...

[Furbs]

I clear compiled cache a lot. I know I mentioned a "cache" but I was thinking there was something else. 

We did refresh dependencies and check the library's XML file, but it wasn't a class issue, just the one VI. The problem was resolved by opening the VI, allowing it to determine it needed the other VI. Then making a change and saving it. Basically, he was unknowingly updating the VI in memory without the reference when he opened it, then it would work all day, until he closed without saving. It's a VI in the repo library, so we try not to save and commit without a conscious update by habit. 

[wiebe@CARYA]

Makes me think of odd behavior I sometimes have, where a 'save all' doesn't save all, but in stead makes the current copy work. Then I move, copy or commit and check out the code, and there are dependency problems.

It seems to me in these cases, the compile cache is actually fixing the issue, and when the project is loaded from another location, there's no compile cache and the dependency issue shows.

The problem has two sides: 1) save all doesn't save all because everything is OK to LV and 2) the compile cache fixes this, so there definitely is a mismatch between the class\vi and it's saved state.

IIRC this could be reproduced by (something in the line of) adding a method for overwrite, terminating LV (I know, that's cheating) and reloading the project. The class accepts the new method, save all doesn't change the class, but after a move the new method isn't in the class (which is dangerous, because that's not an error).

This did seem improved from LV20 to LV23, although it's hard to say as I don't repeat everything I ever did.