Pb deploying a LV executable on a machine that has the LV environment

[Paillard]

Deploying a LabVIEW executable on a machine that already has the LabVIEW environement poses problems. Among those, the LabVIEW runtime is sometimes downgraded by the new install, plus LabVIEW projects sometimes cannot build anymore and display strange errors after installing an unrelated LabVIEW executable.

This has been the case for a long time now (not just the present version), but it is really a pain. That means that we cannot safely deploy executables built with LabVIEW on the machines of customers who happen to have the LabVIEW environement. When the installation corrupts their LV environement, customers are understandably annoyed (to stay politically correct).

Do you think you could find a way so there is no risk installing an executable built with LabVIEW could corrupt the LV environement, when there is one on the machine?

Thank you for your help

Bruno

[Mockingbird]

Hi,

can you go into a bit more detail about which versions you've seen this happen on? Each version of LabVIEW Runtime engine is kept separate from the others so I'm not sure I understand what you mean when the LabVIEW runtime engine is being downgraded. 

What errors are you running into for your LabVIEW projects after installing the unrelated LabVIEW executable? Are you able to reporduce these problems consistently? If you are, can you post the steps you take to do that? That would really help us look into this issue.

Thanks

[p-rose]

For simple applications with one executable file and a few support files (images, database, etc..) you can just make an exe and take the output of the build folder and create a self-extracting archive. You don't always have to create an installer, I usually only do that in rare circumstances where I'm trying to make installation a little easier on a machine that has never seen labview. It goes without saying but the runtime version needed equals the development version used. All version of the run time environment are available as stand-alone downloads, google is your friend there.

[Jeff-P]

The different versions of the LabVIEW Run-Time Engine (RTE) are side-by-side installations, so you can have multiple versions installed at the same time on the same system. If you have an installer with an RTE in it, if that version of the RTE already exists on the system, it will not install anything. If that version is not present, but other versions are (ie you are installing the 2012 RTE and the 2011 RTE is on the system already), then the existing installations will not be affected, and the new RTE will be installed. The only case where running an installer that contains a RTE will modify an existing installation is if you are installing a later version of the same RTE (ie you have the 2012 RTE installed and your installer contains the 2012 SP1 RTE).

There is a full explanation of compatability in this KB - LabVIEW Run-Time Engine Compatibility

Regards,

Jeff Peacock 

Product Support Engineer | LabVIEW R&D | National Instruments 

[Paillard]

Hi Gabriel

I can offer two cases that occured with my colleagues, for which I have the most information:

1) In the first case one of my colleagues had LV-2012 installed, but was not the latest service pack (installation was pre-SP1). He installed a LabVIEW executable that had been built with LV-2012-SP1-f4. After the installation one of his own .lvproj projects had a builder for an installer that would not build anymore, and was asking for the LabVIEW installation CD (The first one). There was no indication of what was missing. In that case, after reinstalling LabVIEW 2012 SP1-f3, my colleague could then provide the LabVIEW installation disk when the .lvproj was asking for it. That solved the problem.

2) In the second case Another colleague had LabVIEW 2012 SP1-f4 installed. He installed a LabVIEW executable that was built using an earlier version of LabVIEW (probably 2012, but pre-SP1) - Let's call that Exec_1. After that install, one of its project had an installer that would not build anymore (similar situation as above), but in that case it was requesting the installer for another LabVIEW-built executable - Let's call that Exec_2 - THAT HAD NOTHING TO DO with the project at hand. In that case, even reinstalling LabVIEW from scratch would not solve the problem. My colleague had to delete registry entries corresponding to the installer for Exec_2, and force a reinstall of the LabVIEW environment.

My colleague suspects a problem with the VISA run-time, rather than the LabVIEW run-time.

Note: In those two cases all LabVIEW executable installers concernedhad to install the VISA module.

I will ask my two colleagues to see if they want to add anything.

[Mark_Yedinak]

What specifically are your installers doing? I have never encountered this issue with the applications I have built and created installers for. They have also included VISA as part of the install. I have installed applications built with versions of LabVIEW all the way back to LV 7.1. I have had a mix applications spanning at least four versions of LabVIEW on my development computers. I suspect that the installers are doing something specific which is causing the issues you are experiencing.

[Paillard]

Hi Mark

All of the installers discussed above install a LabVIEW-built executable, plus the VISA run-time.

Some of them (not all of them) run a driver installer after the LabVIEW installation itself. But that is a pretty standard driver installer, based on DPInst. The driver installed is WinUSB.  This step is completely separate from the LabVIEW installer itself (this is a simple executable run after the LabVIEW installer has completed).

Nothing else of special significance...

Bruno

[Mark_Yedinak]

---

@Paillard wrote:

Hi Mark

All of the installers discussed above install a LabVIEW-built executable, plus the VISA run-time.

Some of them (not all of them) run a driver installer after the LabVIEW installation itself. But that is a pretty standard driver installer, based on DPInst. The driver installed is WinUSB.  This step is completely separate from the LabVIEW installer itself (this is a simple executable run after the LabVIEW installer has completed).

Nothing else of special significance...

Bruno

---

Are the installers placing any source VIs on the machine? Are they adding anything to the LabVIEW directory? As I have stated I have had no issues installing applications trhat were built using LV 7.1 on PC today that have multiple development versions of LabVIEW on them including and LV2012. I haven't installed LV2013 yet but my current development machine has the full development environments of LV 2009 through LV 2012 with installed applications built with nearly every version from LV 7.1 to LV 2012. I have never experienced the issues you describe which is why I wonder if your installer is putting other stuff onto the system beyond the basic installation.

[Paillard]

Hi Mark

No. The installers are NOT placing any source VIs on the machine

No. The installers are NOT touching the LabVIEW directory, except I imagine to install the LabVIEW and VISA run-times when appropriate. In other words, no deliberate modification of the LabVIEW directory.

My (and my colleagues) experience seems to be quite different from yours...

Bruno

[Andy-C]

Hello Bruno,

It does sound to me like something strange is happening here. This is certainly not normal behavior in most cases. We would likely need some more information on the errors you are seeing to say much more. Can you provide any more details or screenshots of the errors you and your colleagues have been seeing? It sounds like this is quite an inconvenience for you, so I encourage you to get in touch with our support department if you haven't already. 

Best regards,

Andy C.

Applications Engineer

National Instruments