Unused bad VI in project/lvlib causes compile failure

[BertMcMahan]

I'm working on an LVLIB contained in a project, and am trying to build an executable using some of the VI's. 'm getting the notorious Error 1502 when I try to build my application, telling me that I have a bad VI in the project. The thing is, I *know* it's a bad VI, but it's not one that's being used in the executable at all. It's an older VI that I keep around as a testbed for a couple of other VI's; it's not being called by anything, and isn't included in the build specification. I know it's bad, but I don't care- it shouldn't have anything to do with the build anyway, but somehow LV wants to open it and resave it within the project.

I have instructed the compiler to remove unused members of project libraries, but for some reason it's still trying to save this broken VI.

Enabling debugging DOES seem to fix the issue and let it compile, but it seems silly that I have to do this on the final build of my software. Is there a way to get the compiler to ignore broken VI's in a library?

[wiebe@CARYA · Accepted solution]

The usual fix is to put a disabled case around the broken code. So, no, I don't think there is a way to ignore unused broken VI's in libraries (I only use classes, but expect libraries to behave the same).

You could try a conditional disabled case, so it's only disabled for runtime environment. Not sure if that will work.