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 11 hours ago by ShaunR

[Matt_AM1]

ShaunR,

 

Based on what you are saying, it looks like I'd need to go down the VM route.  However, I'd like to verify I'm using the right jargon after rereading my initial message and reading your response. 

 

When I am saying portable, I mean that I would like to be able to transfer what toolkits and what not relatively easy between PC's.  So if my PC crashes or I have to change PCs in a few years, I don't have to recreate my wheel and be super meticulous about everything.

 

When I say isolated, I am thinking since I do dev work in 2 different versions, then those versions shouldn't be interfering with each other for common drivers, such as DAQmx.  So to me, that means that they should never be able to see each other, thus isolated.

 

If both of these are accurate to the jargon, then I do need to go down the VM route.  However, I am unsure if what I think portable means is what it actually means 😅.

 

Thanks,

Matt

[Reds]

I have a system I've been using for years that works pretty well.

Windows has a very capable boot manager. Once setup, it will prompt you to select which Operating System you want to boot into at system startup. You can have a different copy of Windows installed on basically every partition on your GPT formatted hard disk. If you start googling around for the "bcedit" and "bcdboot" Windows commands, you'll quickly find yourself deep into this rabbit hole. Sadly, I have the options for those command line tools memorized because I do this so frequently, and for so many years

If you really want to get sophisticated, you can also use the Windows boot manager to boot *directly* into a VHD - without any host operating system running. This allows your VHD *direct* access to all the NI hardware without any translation layers in between. This is known as "Native VHD Boot" in the Microsoft documentation.

If you're booting directly from VHD's - these VHD's are portable to new machines. You're just going to have get very familiar with the bcdedit, bcdboot, and diskpart command line tools. It's all doable, and it all works, but these tools will start to make your feel like you've living in Linux world, and not Microsoft world . It just takes time to learn and get familiar with the tools.

I've been taking this approach for many years - I can't even imagine living without these capabilities.

I don't know why anyone would mess around with docker or any of that stuff. The capabilities built directly into Windows meet 100% of my needs. The only special thing you need is a generously sized SSD, formatted with many different partitions (one partition per Windows copy).

Edited 4 hours ago by Reds

[Matt_AM1]

Reds,

 

NGL, I don't understand what you're saying, but I'm gunna take a stab at it.

 

It sounds like you have massive SSD with the various partitions for the specific versions of LabVIEW on it.  From the VERY brief googling I've done, it sounds like BCDBoot sets up a boot a virtual hard drive (VHD).  The VHD can be booted from windows (I am not sure what side-by side means with respect to booting the VHD, but I am assuming it means I can run the "real OS" and the "LV OS" versions of windows at the same time).  I think BCDEdit allows me to modify the boot of the VHD or it is the command line execution that creates the VHD's and BCDBoot is the one that boots the VHD.  

 

So, assuming I am on the rightish track, would the VHD only contain information related to LV specifically, such as LV/MAX/other NI software/git with its specific diff/merge for the LV version?  If so, then what would the "real OS" be in charge of with respect to LabVIEW?  

 

I guess what I'm not fully putting together is, why virtual hard drives?  From my very basic (mis)understanding of things, the VHD can be mounted/unmounted at will to swap between the versions of LV, so why couldn't you do that with multiple partitions on a SSD? It sounds like that was Tim_S's solution, with the various flash drives being the VHDs in this scenario.  Googling the difference, I see that VHDs are meant for virtual machines, so I am assuming that when you BCDBoot the VHD, you're booting a virtual machine's image to work in tandem with windows which contains the LV version and what not.

 

Matt

[Reds]

2 hours ago, Matt_AM1 said:

Reds,

 

NGL, I don't understand what you're saying, but I'm gunna take a stab at it.

 

It sounds like you have massive SSD with the various partitions for the specific versions of LabVIEW on it. 

Yup.

From the VERY brief googling I've done, it sounds like BCDBoot sets up a boot a virtual hard drive (VHD).

Yes, BCDBoot can definitely do that. But it can also just tell the PC to boot using a copy of Windows that is on a partition somewhere else on your drive. I guess you could say you're telling it to use a non-standard partition.

  The VHD can be booted from windows (I am not sure what side-by side means with respect to booting the VHD, but I am assuming it means I can run the "real OS" and the "LV OS" versions of windows at the same time). 

Nope. You're typically only running one copy of Windows at a time if you're using the Windows Boot manager (BCDBoot).

I think BCDEdit allows me to modify the boot of the VHD or it is the command line execution that creates the VHD's and BCDBoot is the one that boots the VHD.  

BCDEdit is how you tell your PC: "When you turn on, use the copy of Windows I have over here on this alternate partition...". You can also use BCDEdit to say "Don't boot from a partition at all, boot from this completely self-contained VHD file instead".

So, assuming I am on the rightish track, would the VHD only contain information related to LV specifically, such as LV/MAX/other NI software/git with its specific diff/merge for the LV version?  If so, then what would the "real OS" be in charge of with respect to LabVIEW?  

The VHD contains an entirely separate copy of Windows. There are no differentials. When you boot from a VHD you have a Windows environment that doesn't know anything at all about any other copies of Windows you have in different drive partitions. Native Boot from VHD is a completely and totally standalone environment. In fact, you could actually boot your PC directly from a single VHD file every day, and not even have a traditional Windows partition.

 

2 hours ago, Matt_AM1 said:

 

I guess what I'm not fully putting together is, why virtual hard drives?  From my very basic (mis)understanding of things, the VHD can be mounted/unmounted at will to swap between the versions of LV, so why couldn't you do that with multiple partitions on a SSD? It sounds like that was Tim_S's solution, with the various flash drives being the VHDs in this scenario.  Googling the difference, I see that VHDs are meant for virtual machines, so I am assuming that when you BCDBoot the VHD, you're booting a virtual machine's image to work in tandem with windows which contains the LV version and what not.

 

Matt