LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
SteenSchmidt

Export Dev Environment Install Script

Status: New

We experience two use cases that is quite hard to complete 100% succesfully:

 

1) When we work several developers on a project we need to have identical development environments on our computers or else we get "dirty dots" on our VIs when another developer opens them from SCC. The development environment consists of at least LabVIEW version, modules, tool-kits, device drivers, patches, service packs, maybe TestStand, and maybe third-party tools as well.

 

2) If we need to recreate a particular development environment because a customer wants an update to some existing application.

 

The first one we try as hard as we can to achieve with lists "handed around", but it's almost impossible to extract all the version information from the installed environment (you have to look many places and filter each list manually), so it's extremely easy to miss something. The second one can be achieved with images on virtual machines, but sometimes VMs can't be used due to hardware or IO limitations, legal rights and what have you.

 

So I suggest some form of tool that lets you export an .msi that you can run on another machine, that tells you what to install to replicate the dev environment the .msi was created with:

 

ExportMenuSelection.jpg

 

The tool could be available from the various Tools-menus, and maybe from the MAX, from Start->Programs->National Instruments etc. It could open up a configuration dialog like this:

 

SelectDialog.jpg

 

The install script (.msi or similar) shouldn't contain any applications itself, but would just be a guide to get the proper tools installed - you must have access to the install media and activation codes yourself, but you would be told what to install, and the script would be able to verify that the installer you're pointing it at really installs the correct version. It should be possible to skip steps during the install guide process, and it would be great if the installer would also be able to handle already installed versions (both the correct and the wrong versions = different actions available).

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
5 Comments
Technico
Member

Device drivers should contain also MAX (and the MAX-configuration)

Third party components should contain installed OpenG / VIPM packages as well.

 

stbe
Active Participant

I'm in favour of your idea - it also seems to be ideal to setup several systems (eg. for larger development team, lectures ...) without the need to create a complete disk image (including operating system ...)

 

concerning


@SteenSchmidt wrote:

We experience two use cases that is quite hard to complete 100% succesfully:

 

1) When we work several developers on a project we need to have identical development environments on our computers or else we get "dirty dots" on our VIs when another developer opens them from SCC.

[...]


have you tried separating compiled code? (http://zone.ni.com/devzone/cda/pub/p/id/1258 )

this works fine for me (also quite stable since LV2011)

 

regards, Ben

_________________________
CLA
SteenSchmidt
Trusted Enthusiast

Hi Ben.

 

Separating compiled code for this purpose is like peeing in one's pants, we still need to be sure of which runtime environment our customer needs to set up to be able to execute the finished code. We can't rely on trial and error, the environment must be deterministic. And toggling the "separate compiled code" setting on several thousand VIs isn't too appetizing I think, from a practical and an SCC perspective 🙂

 

In regards to LV 2011.... we don't use it. It's too unstable for us currently, so we recommend staying with 2010 SP1 until we have evaluated 2011 SP1 or 2012. We have had to roll back a LV 2011 migration in a production site over christmas for instance. This is together with TestStand for the record, maybe LV 2011 works ok by itself.

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
R_Beauchaine
Member

We have struggled with this situation as well; not so much to duplicate a development environment, but more with run-time environments. We use VMs to be able to duplicate builds for distribution machines, but this does not cover the driver environment or third party installs. The NI installer makes it difficult to create an installer with the driver environment since you need the original media if you did not copy to disk originally. I plan to experiment with Win 7 backup (image) importing into VM and exporting back to duplicate machines. A native NI tool would be nice, I am sure the registry/MAX contains all this information from the installer.

-Rick

SteenSchmidt
Trusted Enthusiast

@Rick: Then please kudo the idea 😉

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion