LabVIEW 2018 not changing vis (no dirty dot) when upgrading from LabVIEW 2016

[Thomas_robertson]

We are upgrading our code base from LabVIEW 2016 to LabVIEW 2018.   I expect to see about 6500 vis and ctrls being saved.  In Perforce I have checked out our source code repository, In LV2018 opened up the projects and vis that pull our whole project in to memory and save all.  Then in perforce I use "revert unchanged" so as to not check in random text files and the like.   It ends up reverting about 2/3 of our source code repository because there was no change on disk.

In years past (e.g. LabVIEW 2012> LabView 2014 > LabVIEW 2016) we have used this method and it has touched every vi in our source code repository.   Has something changed such that LabVIEW 2018 doesn't need to change the file when reading LabVIEW 2016 vi's?   I thought at a minimum it would have written a "saved in LV2018" flag to it.

[Bob_Schor]

---

@Thomas_robertson wrote:

 I thought at a minimum it would have written a "saved in LV2018" flag to it.

---

There are two ways to check that.  First, try to open it with LabVIEW 2016, see if that works.  The other way is to open it in LabVIEW 2018 and check out its Properties (right-click the Connector in the upper-right corner and select VI Properties) and under General, check "Source version".

Bob Schor

[Thomas_robertson]

I can confirm that after using "save all" from the project window in LabVIEW 2018, many vis in memory are still in LV2016 format.  VI analyzer confirmed that for me.

[Kyle97330 · Accepted solution]

I'm going to go ahead and bet that if you looked, all of the unchanged VIs have the common trait that they have the "Separate compiled code from source file" option checked and the VIs themselves are simple enough that nothing was altered in them in the last 2 editions.

I don't have 2016 but I confirmed that a VI saved in 2015 and loaded in 2018 doesn't get the dot if it has that option enabled, and does get the dot if that option is turned off.

[Thomas_robertson]

Also, VI analyzer encourages me to fix this by mass compiling my directory of vis.   Problem is, I tried mass compile yesterday and it took about 12 hours before it finally crashed.   I tried it on a subset of our code just now and it only took about half an hour to crash.  So that's progress.

[Thomas_robertson]

Yes, indeed, we have seperate compiled code turned on for most of our vis.  So...  Is this a documented feature that it doesn't need to re-save those vis?

[Bob_Schor]

Ah, yes, "Separate Compiled Code" -- one of the reasons we do this is so that VIs that aren't "really" changed don't get marked as "revised" just by being opened in LabVIEW.  I should have thought of this, but I've only just started to do this, myself ....

BS

[Kyle97330]

I don't know that it's specifically documented.  This help file says "You can upgrade source-only VIs to a new version of LabVIEW without checking out the VIs from source control.", which kind of implies that?

A VI basically contains 4 things (front panel info, block diagram info, compiled block diagram info, and assorted properties/metadata) and if you don't want updated compiled code and the other 3 don't have any changes in them between versions, then it makes sense that it wouldn't force a save.

[Ben]

Wasn't there also a change with the Run-time engine supporting multiple versions?

Ben

[Thomas_robertson]

To fix this, I opened a project that had darn near every one of our 5,000+ vi's in it, went to project options and use the "Mark Items" feature of the source code tab to mark everything as do not separate compiled code, then saved everything, then used the dialog to mark them as "separate compiled code" then saved everything again.    Then when I used Perforce "revert unchanged files" it didn't revert any of our vi's.  They were all changed.