2025Q3's new feature of saving project at older version source code and RTE

[Paul.B]

Hello,

I was trying the new LV25Q3 with the possibility to save a project with a source code of older LV version (later than 2017). That's seems pretty useful to be able to save to a lot of source code version with only one LV environment. However, when I try to create an application for this said project of older source code, the run time engine needed will be LV25Q3 (or Q1 https://www.ni.com/en/support/documentation/compatibility/17/labview-and-labview-run-time-engine-com...).

Will there be a possibility to build the exe that will need the RTE of same source code version ? So that if I code in IDE LV25Q3 with a source code of LV17, my RTE needed will be LV17 and not LV25Q3.

Paul.

[ZYOng · Accepted solution]

Can I Build an Application for a Previous Version of LabVIEW Run-Time?

No. When an executable is built, the Run-Time Engine dependency is defined by the development environment used to create the executable.

Therefore, make sure that you match the version of LabVIEW Run-Time Engine to a compatible version of the Development System.

[Paul.B]

Hey,

Thanks for the answer.

I find it quite sad that this is not possible because I thought that the goal of this new feature was to be able to develop everything on the latest LabVIEW version even if the program will be run on a PC with LV18 (or whatever version). I guess this is a limitation at the core of LabVIEW and not a small feature but it seems I'm missing the goal of this new feature.

[cordm · Accepted solution]

This feature makes collaboration a lot easier. You can contribute to projects developed in different versions, but don't need to have the specific version installed. Then you have the maintainer or CI/CD system create the executables. Creating a VI package that can be used in LV 2020 with LV 2025 is super useful.

[Paul.B]

Right, I don't do a lot of collaboration but that makes sense.

Thanks.

[softball]

Hi

Editing and saving for an earlier LabVIEW version than installed is/sounds useful.

However, remember the gremlins.

Your current LabVIEW version must include a feature set including whatever was installed on the older LabVIEW version. Otherwise you get broken VI's if using any feature not installed. Which is not fun.

Solving that problem might be impossible. Some Modules or Toolkit may simply be unavailable for both versions.

Also notice that RT and FPGA concepts are essentially not supported. Requiring you have access to the old LabVIEW version. So, not useless, but pretty convoluted. 

Regards

[Paul.B]

Your current LabVIEW version must include a feature set including whatever was installed on the older LabVIEW version. Otherwise you get broken VI's if using any feature not installed. Which is not fun.

---

For this part, 25Q3 indicates you when you are using a function that was not available or is deprecated on the version that you choosed. For example, there will be a warning if you use Collection function for a 2017 source version.

Solving that problem might be impossible. Some Modules or Toolkit may simply be unavailable for both versions.

---

For this part, I do not know if the system can warn you about that, I don't think so.

[Yamaeda]

How does the Project version relates to DAQmx? You should have one installed for e.g. 2024?

[softball]

Hi

As already stated, I find the benefits of this new edit and save as in a previous version of LabVIEW quite limited.

It can be used for very simple use cases. What I used to call DEMO examples.

But why not -simply- create a computer with multiple partitions and one LabVIEW version installed on each and then connect remotely to that computer, using TeamViewer or Windows own 'Remote Desktop Connection'. As a shared resource in a larger organization. I don't have access to such a setup myself, but it should just work. The graphics performance will of course be limited.

Regards

[BertMcMahan]

You don't need to have different partitions or anything- you can have multiple versions of LV installed on the same computer.

Many larger groups use CI/CD systems to build their executables, which is a solid way to go as it makes sure your build environment is always consistent. With that method, you can automate the process of saving your code and having the build system pick the correct runtime engine (or all of them!) to build.