Mass Compile should NOT change Program Files

[d.w.b]

NI's code should be excluded! Many VIs are installed as part of LabVIEW in the C:\Program Files (x86)\National Instruments\LabVIEW folder. These should NEVER be modified outside of installs/upgrades. I started a Mass Compile and, whoa, it did much more than I expected! It changed and saved hundreds of files. I let it run for about a minute, got too nervous, and stopped it. I didn’t think to back that up. Now I fear my LabVIEW installation is dirty. NI SR#7722650 says "It does go outside of the specific folder if the VIs in the specific folder depend on another VI outside of the folder. When it goes outside, it is just opening the VI and resaving it in the current version of LabVIEW. Because your VIs depend on some VIs in the ... vi.lib it went and resaved them. But, they are already in LabVIEW 2015 SP1, so it will not change anything in them. It does this to ensure the VI is looking at the current version of LabVIEW and not an older version." If that is true, why would installation of a version of LabVIEW install VIs of older versions? Make sure all vi.lib VIs are already compiled for that version.

I found https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Force-Recompile-option-in-Mass-Compile/idi-p/2659839 which discusses whether or not LabVIEW Mass Compile changes files that are already up-to-date.

[BoKnows]

I've gone through the request you posted as well as the other Idea Exchange you linked.

Let's start with the latter first.  This addresses something that's almost the opposite of your concern.  In your post, you're concerned that things are being updated that shouldn't need to be updated.  In that post, it's asking for functionality to FORCE and update even if Mass Compile doesn't believe such a change is needed.  

With the request you posted, you provided the AE a log that showed some of your dependencies were also called into memory.  It doesn't reference the LabVIEW installation anywhere.  Without verifying the log, the AE took you at your word and explained why vi.lib would potentially be loaded.  In general, their explanation made sense.  When you're compiling a VI, it was also looking at the VIs you were calling to make sure things were in a good state and that went to other folders.  Specifically, it wasn't accurate.  vi.lib was omitted.  As Mass Compile is looking for changed VIs, those within your vi.lib wouldn't be changed.  They're skipped intentionally.  As the thread you linked describes, even if they weren't skipped intentionally, Mass Compile would skip them because the versions would match. As with all things in code, there can be small exceptions.  With these exceptions, the behavior is expected and wouldn't corrupt your installation as you fear.   

In order to make sure I wasn't missing something, I've tried to make VIs in vi.lib compile unsuccessfully.  

[Darren]

Declined for reasons listed in post by BoKnows above.

[d.w.b]

BoKnows:

> Specifically, it wasn't accurate.  vi.lib was omitted.

What do you mean?

> As Mass Compile is looking for changed VIs, those within your vi.lib wouldn't be changed.

> They're skipped intentionally.

> As the thread you linked describes, even if they weren't skipped intentionally, Mass Compile would skip them because the versions would match.

> As with all things in code, there can be small exceptions.

> With these exceptions, the behavior is expected and wouldn't corrupt your installation as you fear. 

Are you agreeing with me that Mass Compile should not re-save vi.lib code but in a few exceptional situations they might be but if they are they won't be changed functionally?