Add ability to select which version of LabVIEW Runtime is compatible with executable

[MaximeR]

Since LabVIEW 2017, the default build specification check the option "Allow future versions of the LabVIEW Runtime to run this application".

I don't undertstand why it is checked by default when you read the help that said "Disabling this option prevents any changes to the performance profiles and helps you avoid unexpected problems resulting from compiler upgrades."

Because NI and me doesn't know the future, NI will never garanty that your application will run with all the future LV Runtime. I know it well because I'm facing this issue with le LV RT 2020 that breaks the execution of different application that I have buid in 2017 SP1.

The behavior is a little strange too, because, even if you have the run-time use to build the application on your computer, the application will use the highest one present one the computer.

This options can be very usefull, and I appreciate it, but maybe we need to have more control on it. So my idea is to give to the user the ability to list supported or unsupported LabVIEW Runtime.

This will help us managing future LV Runtime without having to recompile the application which seems to be the goal of this option.

for Example :

[MyApplication]

ExcludeLVRTe = "2020,2021"

Regards

[donkdonk]

Sounds horrible to me.

I do not often have to make executables (most of the time we run LabVIEW in our lab, for our own purposes).

But at the moment I have a case, where I find myself modifying code using the same (older) LabVIEW version I used for my first version of the software. This way my client does not have to (shall not!) change/install another  runtime engine.

It means I have to install this older LabVIEW version and daqmx on a separate laptop. Or at least, that's what I do, being afraid that multiple versions on one machine will confuse things further.

So something should be done about it.

[thols]

NI contacted me soon after I made my last reply. They are very interested in hearing anything about this issue. I don't know if the OP was contacted or if he has the exact same bug. 

Anyway, I tried to reproduce the issue but could not. I have an executable which has the issue but the exe built from the project of the same scc-version (if I didn't screw up the versioning...) does not have the issue. The issue disappeared when I was testing and trying to minimize the code that showed the issue. Perhaps a bad cache, I don't know atm.

[wiebe@CARYA]

Heisenbug. Doesn't mean it's not there...

[wiebe@CARYA]

Yes, but step 1 to finding a solution is to reproduce the problem...

If it doesn't reproduce, it's much harder to solve.

[thols]

Wiebe: "Yes, but step 1 to finding a solution is to reproduce the problem...

If it doesn't reproduce, it's much harder to solve"

Agree. And since I can no longer reproduce it, there is now only one I/we know of that has this issue. Maybe there are more, but since it is a default setting, I expected to see more issues reported about it. Perhaps there are more issues, but I haven't found anything in the forums when I looked for it then.

OP: I expect NI has contacted you about it too. It will be interesting to hear what the progress on pinpointing the issue is.

[Yamaeda]

Yes a corrupt(ed) cache would explain a lot. Can you force a program to run with a specific RT? Or do you need to (un)install the 2020 RT just to test it?

So to reproduce:

Install 2017 RT and program

Install 2020 RT

Start program, or?

So, would clearing cache solve it? Can you force it to use 2017? Can you e.g. use the 2017 RT with a program as parameter, will that work?

[MaximeR]

Hi all,

The cache is maybe a source but not the only one. I sent a code that reproduce the behavior.
Forcing to use the Run-Time 2017 is only possible if you unselect the check box for compatibility.
There is no way to run an executable with that option activated to run with a specific Run-time engine. With this option, always the highest run-time will be used. That's the purpose of my idea to give user/developer, a way to control this option after building the application.

Best regards

[James_W]

1) I wonder if anyone's tried to hack the XML text of the lvproj file to work around this? (to uncheck to box in the build config)
2) I can see that if producing S/W for a test system for the medical or aerospace (or any other heavily regulated) sector  this'd pose a HUGE problem with validation after an upgrade.

James

[MaximeR]

Hi,

It's possible to uncheck this option when you build your Desktop executable. NI didn't changed anything on that point because LV 2020 continue to have this option checked by default.

It's not uncheckable at all for Real-Time Application and it's more problematic in my point of view :

Please take a look on that idea : Add ability to disable "Allow future versions of the LabVIEW Runtime" for Real Time application - NI...

best regards

[nanocyte]

I'd like to add a vote for the "Why would the more dangerous option be the default"

Being able to fix this in the INI (that's my interpretation of this idea) might be a good workaround to avoid a recompile