managing multiple versions of LabVIEW

[clendon.gibson@canrig.com]

Where I work, different versions of LabVIEW are used for different projects. The view here is not to mix multiple versions because of the possibility of linking the wrong versions of libraries.

The usual way to deal with this is to have several computers or to use virtual machines.

It occurred to me that it should be possible to work with the OS (Windows 7 in my case) in order to create several developer environments. If I switch between environments I would need to change registry keys, make certain directories hidden etc...

Has anyone worked with software that makes this possible? (I can't be the only person with this headache.)

Failing this particular silver bullet, how do you manage multiple versions of LabVIEW?

[GerdW]

I install them in parallel.

I create working directories for each version (and use SVN of course).

I'm careful when switching LabVIEW versions…

Hint: Don't use two LabVIEW versions at the same time on one computer. That avoids most of the possible hassle!

[RTSLVU]

Like Gerd I just install them both, each with it's own (often identical)  user.lib, instr.lib, and projects in separate directories by Labview version.

The only time you really have to pay attention is when moving a vi or project from one version to another.

 You will have to avoid clicking on a project or VI in Windows Explorer and auto launching Labview, always start the Labview version you want and open the project using Labview dialogs

[clendon.gibson@canrig.com]

I should edit my OP.

While LabVIEW version is one thing, there are also the versions of the supporting software to consider. What version of NI-RIO is being used for Project X. Is it different then project Y? etc...

I can see being careful with LabVIEW itself, although the last time I tried I burned myself badly enough to not want to do that again. But there is supporting software that I think you can only install once. (Like NI-RIO)

[crossrulz]

I also just install in parallel.  I have 6 versions on this machine.  I think I have 7 on my other work machine.  You can run into some issues with drivers this way, like if you have LabVIEW 8.6 and 2013 installed, the latest version of DAQmx doesn't work with 8.6.  But in general, I have yet to have any issues.  Trust in my version control system if I accidentally use the wrong version on a project.

[Omar_II]

Set the LabVIEW.ini file setting showExePathInWindowTitle=True for all the versions of LabVIEW that you have installed

This will show you the actual version of LabVIEW that you have open and are working in. Helps me to keep things straight.

It will not show you the version of LabVIEW a VI was last save in. But you can find that under the VI properies.

[Hooovahh]

At one point I had something like 9 different versions of LabVIEW installed in one real machine.  It went okay for opening things but luckily I only was activly developing in the newest 3 or so.  Newer versions of DAQmx and other tools are pretty good for backwards compatibility to a few versions.  Right now I develop in 2011, 2012 and 2013 (all SP1) all in one real machine (VMs for older) and I use the newest DAQmx for all 3 no problem.  I can see the consern others may have about isolation and for that I can see why you wouldn't want more than one version installed in one machine at the same time but I haven't had any real issues.

The only minor issues I've had were opening a 2011 project in 2013 and accidentally saving it.  Luickly SCC saved me, and I developed a tool that when you open a file it looks at the version it was developed in, and looks at the versions installed and prompts you for which version it should be opened with.

[JÞB]

I hate to say it but, there is a famous teacher that will show you exactly how to go about this.  "Pain"

Yes, having multiple versions on one machine can be problematic.  But it really isn't too hard if you pay attention to what you are doing.  USE projects, Show file paths in the Project explorer Items view and isolate your reuse code by LabVIEW version. (Being very very careful about reuse item dependancies prior to reuse library release)

Awareness of the context that you are working in is a key skill that quickly becomes second nature.  Like learning how to use a gaming system device.  At first you have to think about what button you press when...then the controller just works for you.  Trust me it really isn't that high or long of a learning curve- but the first time you make a mistake there can be painful consequences....then you don't do that no more! (And SCC is a MUST!)