What are solutions to portable and isolated dev environments?

[Matt_AM1]

Hey Fancy Folk,

 

I am looking for solutions to creating a portable and isolated LV Dev environment (2018 32 bit and 2024 64 bit along with various toolkits).  From what I understand, I believe I need to go down the VM route for my needs, but I wanted to see what other people think because I don't know what I don't know.

 

Background:

I do dev work in LV 2018 and 2024 and want to isolate them from each other.  I am also using git for version control and I don't want to have to continually tell git what version of diff/merge tool to use on a per repo basis - less clicks in my life the better.  So, I am trying to make my future life easier since I currently know how things are set up and can recreate that wheel when things are settled vs when things go bad.  Right now, I have LV 2018 and 2024 both installed on my PC and it works good enough, but I am sure I'll eventually get bitten by having both on my PC.

 

My initial thought was to look into either a VM or Docker and create an image for both versions of LabVIEW.  Googling around, it looks like NI said that Docker was a no go because NI Drivers need kernel mode drivers and user mode libraries (Are NI Drivers Supported on Docker Containers? - NI), which makes me think that VMs are the solution to my problem.  However, NI also says that NI software should generally be good on VMs, but it is not officially supported (Are NI Products Supported on Virtual Machines (VMs)? - NI).  I am not claiming to be a SW engineer and I am unsure what tools exist, so I wanted to see what you guys think and if you have any advice for how to proceed. 

[Tim_S]

I've only started looking into Docker, so I can't comment there. I've some old versions of LabVIEW that I have on a VM and that works without an issue. My IT department gripes at me about VMs as each one is a license of the operating system.

[ShaunR]

Hey Person of Fancy

If you want device drivers, DAQ, vision toolkit or 3rd party driver support then VM is the way to go. All versions of LabVIEW work fine (with caveats) in Virtual Box and VMware - just read up on NI's licencing requirements for VM's. This will be GB's of data each save and VM's run like slugs compared to your dev machine. Also the computer hardware will not be representative of the final target you will deploy to. So beware- here be dragons!

When it comes to LabVIEW, I also have USB sticks with customer specific versions so that I can go on-site and seamlessly integrate into their teams. These are only applicable if device drivers et. al. are not a concern (e.g. UX, TCP, GPIB, Web Applications and stuff like that). Some want me to keep the USB while others want to keep the USB stick with IT - in the latter case, source control is their problem and for the former I just check in the entire USB stick.

if you don't use a VM and have multiple LV versions, there are 2 issues you need to be aware of

1. You can only have one NI-DAQ version across all LabVIEW versions (this is the main reason why you need VMs but there are others). If multiple versions are needed in different LabvIEW versions then VM's is the only way.

2. Recompiling in a later version is a huge risk because back-saving is, anecdotally, about 90% reliable and can easily fail in convoluted cases. The best defence is to adopt a workflow that mitigates the chance and rely on source control when that fails or vice versa. Projects are relative paths so as long as you include all code under your project directory (and don't scatter it around different drives and non-hierarchical directories) you should avoid this most of the time. For those times you don't, revert from source control or back-save. Keep your project code separate from vi.lib!

 

Edited 3 hours ago by ShaunR