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

[thols]

Same thing happened to me. I had a number of applications running on customer's computers, and a new version of one of our other applications, built in a newer LabVIEW version made the applications running on those computers not be executable, since they tried to run with the new runtime. And there was nothing to be done other than updating the older applications (or uninstall the new version of the application using the new runtime). It was quite hard to explain for the customers. It is obviously not a good idea to have this settings as default, at least, and there should be a warning of the consequences.

[MaximeR]

It's good to hear that I'm not the only one facing an issue with that. When I ask the support team, they told that there is no support or bug created related to this option since 2017. Even if I'm asking for at least one. I'm not allowed by my customer to send source code and I'm not able to build a simple example to reproduce the issue, but I'm sure that I'm not the only one because this option is activated by default.

I heard also that this option is activated but not unselectable for Real-Time application. I don't know if it's true. But If it's the case, it can be very dangerous if customer update cRIO for example and application can crash at un unexpedect moment due to this.

Thanks for the kudo

[thols]

I should have reported this as an issue/bug, but I was quite stressed to just get it working again. I was also surprised no one else reported this, but I never took the time to minimize the code to see what caused the break. But I can say that during loading of the application, the search box appeared and was searching for VIs from an addon, which it shouldn't need searching for since they clearly were in the correct place even after the new runtime was installed (still under my application, no files affected there), and the location of those files has nothing to do with the run-time version.

[wiebe@CARYA]

>I had a number of applications running on customer's computers, and a new version of one of our other applications, built in a newer LabVIEW version made the applications running on those computers not be executable, since they tried to run with the new runtime.

I'm a bit confused. If that option is on, why would it break if it uses a newer RTE? Isn't that what the option is for? Sounds to me like there is more then 1 issue...

Anyway, it seems like a mess.. +1 for me.

[MaximeR]

What he said is. Application A build in LV 2017 for example with compatibility. Customer install also application B build in 2020. Application B need at minimum runtime 2020 to works. But installing this runtime breaks Application A because it is using the highest runtime available with the option.

So to solve the issue, you have different solution :

- Remove application A

- Remove Application B and runtime 2020.

- Rebuild Application A in 2017 without compatibility and install both runtime 2017 and 2020 on computer.

- Rebuild application A in 2020

The good idea transform management of applicaiton a mess, I'm agree.

[thols]

The fact that an installation of an application can make an already installed application not run anymore is quite disturbing, regardless of how I built any of those applications.

[wiebe@CARYA]

>What he said is. Application A build in LV 2017 for example with compatibility. Customer install also application B build in 2020. Application B need at minimum runtime 2020 to works.

I know. Actually, that's what he wrote. Not sure if he said it as well.

>But installing this runtime breaks Application A because it is using the highest runtime available with the option.

But why does it break?

Isn't the point of the option that Application A can run with the 2020 RTE?

[MaximeR]

That's the point. I'm in this case where I have one application with this option, the application is not working with certain version of the runtime for un unknonw reason. It must, but it doesn't work. My application stay at one point, and take 100% CPU usage when LabVIEW 2020 is installed. I'm force to kill it. With other runtime it works. This is a "regression" of the runtime 2020 in this case. We can't control that.

Actual workaround from support is to recompile the application without the option, or with other LabVIEW version.

Maybe with runtime 2021 runtime it will work again. We cant know it now and my proposal is to say. When a new version of the runtime is provided by NI, I can test it and select if my application is running with it or not. If not, I can just configure my application to use another one without recompiling it and without having side effect from another application.

*Sorry for my previous post, this is not what he said, but this was my understanding.

[wiebe@CARYA]

I'd argue that if the original RTE is available, that RTE should be used even if there's a newer RTE. At least as an option:

+ Allow future versions of the LabVIEW Runtime to run this application?

+ Prefer the original version if it's available? (new)

Isn't the  'blacklist' you're suggesting in practice still an 'after the fact' action? You'd often not know at the time of compiling the executable if future versions don't work. So if it turns out it crashes you have to change this in the installed application. It's better than a recompile (either in the newer version, or with the option off), but not much. As you don't know the future, the only option is to always turn it off.

The first dll I build in LV20 crashed during the build, with "Allow future versions of the LabVIEW Runtime to run this application?" on (by default). So another reason to have it off by default.

[MaximeR]

+1 for "Prefer the original version if it's available? (new)"

It was my first understanding of the function in 2017. If the original RTE is present use it, if not, use another one. But it's not the case.

This option applies to PPL (lvlibp) .NET assembly build with LabVIEW or DLL build with LabVIEW. For PPL we can imagine to have very strange behavior too. What appends if I have this kind of setup. PPL build in 2018 with option activated. Source using this PPL in LV2019 and RTE 2020 installed ? In which version of the RTE the PPL is used ? And after an executable is build ?

Turning it off by default seems to be a good idea too for all new build specs. This option is huge sources of side effects.

But if this option is working well, I will love it.

Patching and exectubale by just changing the INI file is much easier than 3 years after than having to set the whole configuration to rebuild it. It's like a new version of Windows. At build time, you don't know the impact of the next version of Windows, you have to test your application after. Sometimes it works in the same manner, sometinmes not. At the end I will prefer to avoid new compilation. Windows propose to run your application with a compatibility mode for example. It avoids you to recompile your app and try to help you make it run on new software.

That's the case for PPL. PPL are nice, and you can imagine to distribute libraries for users without having to build one per version of LabVIEW. With the option, you can imagine to propose only one build for multiple instances of LabVIEW and just validate new version support with low effort.

Thanks for your feedback on my idea in any case.