Export All Development Environment Customizations for Portability or Backup

[Mr._Jim]

Hi All,

I truly hope this hasn't already been inquired about in some manner, but if it has I'm not even sure what to search for.  Here it goes:

Up until now, I've kept a backup of labview.ini around so that if my computer dies or if I move to a new PC I don't have to spend time reconfiguring options.  It dawned on me tonight that there are a lot of other customizations that LabVIEW developers use.  If heavily relied upon, these customizations can be painful to lose.  For instance:

• Palette customizations (Including "Place VI Contents" or Merge VIs)
• user.lib
• custom icon templates

...you get the idea. (This is a pretty lame list, but it's all I could think of off of the top of my head)

There really ought to be a tool to consolidate all of these options down to the nitpicking details so that they can be exported in the form of a single file. (let's say a zip file, hypothetically)  The user could then access this tool under "Tools-Advanced->Import or Export user settings" or some similar option.

This way, if the user's PC becomes unusable or they are forced by IT department mandate to move to another PC, they could simply import their user setting file and the whole development environment would be configured to their liking, complete with customizations.

Did someone already think of this?

Thanks,

Jim

[Mr._Jim]

Another thought... It would be great if this option worked across operating systems.  For example, if I exported my customizations from a Windows machine to a Linux machine, the applicable keys from labview.ini would automatically translate into keys in .labviewrc. 

Irrelevant or non-applicable customizations would be dropped, with a summary of warnings in a dialog.  (The dialog might say, "could not import recent path c:\xyz since it does not exist" or "Feature X is not supported on this OS")

Does this make sense?

[jcarmody]

I'd add user.lib, LabVIEW\project folder and some subset of the \resource folder (to get all custom JKI RCF and QD plugins).  I've thought of writing a program to do this.

[Mr._Jim]

---

@jcarmody wrote:
I've thought of writing a program to do this.

---

  Actually, the last few times I moved to another PC or had to reinstall I kept thinking that, but this time I finally took the time to write up a suggestion for it.

[David S.]

Playing the devil's advocate: is it not good enough to just back up your C:\Users\{username}\Documents\LabVIEW Data folder alongside labview.ini? As for <user.lib>, backing that up could get very hairy if you use VIPM to manage that folder's contents, because directly restoring the folder could confuse VIPM's installation tracking.

[Mr._Jim]

David, that's a very good point.  My primary motive for this suggestion was in fact user.lib... and you're right, VIPM could get well get "confused" by a mismatch with what's in the restored version.

Now, to play a different devil's advocate: (is it the devil we know?)

..Admittedly a lot of us use VIPM.  For all of its well-earned accolade and unofficial endorsement by NI (or is the endorsement official?), it's still not an official NI product.  Should we treat user.lib carefully on account of a third part add-on?  Or should we treat user.lib carefully for its potential danger with any of several behaviors or add-ons?

You've brought up a very legitimate point, and one which I fear has no clear resolution.  Recognition of and integration with VIPM or the decision of forgoing the development of the import/export tool altogether are certainly options.

[Dragis]

Taking things one step further, can we get LabVIEW to synchronize our settings with our ni.com account? I'd love to install LabVIEW, "log in" to LabVIEW with the ni.com account and then get all my settings synchronized for me. If it knows what external modules and plugins I've installed, having a way to quickly double-click an item from a nice dialog and have it install the module to my new LabVIEW would be awesome.

[David S.]

Mr. Jim, what about the point I made that you can simply back up your LabVIEW Data folder and hit almost all of the customizations in your installation? With that, it seems like LV R&D already has this feature in place, except for the user.lib backup.

[Mr._Jim]

Hi again, David. Well, I guess I did give you somewhat of a circumlocutory response.

Since you insist, I will concede that you're right.  (So that you can flag this idea as already implemented?)  Backing up the LabVIEW Data directory along with labview.ini pretty much hits all of the major stuff.

---

With that, it seems like LV R&D already has this feature in place

---

Now, I'm going to infer from this statement that there's no specially defined "feature," (e.g. a menu item or dialog) but that the option to manually conduct the backup serves as the feature.  (There's no special option, right?)

Backtracking a bit, the major motivation for me was the ability to back up user.lib because I'm starting to increasingly use merge VIs.  I recall reading at one point of a de facto tradition of storing merge VIs in user.lib.  Apparently that's not a hard and fast rule because I tried putting my merge VIs in a different path and had no problem doing so.    I can always reinstall VIPM and download packages again, so that's a moot point, too.

David, thanks for hearing me out, and it's always a pleasure to learn something new.

Kind regards,

Jim

[David S.]

Mr. Jim -

Actually, I'm not in LV R&D, so my opinion matters no more than anyone else's on here. I'm just contributing because I'd like to see so many of these ideas implemented in LV. Getting involved in the conversation is the best way I can find to either get an idea accepted by R&D or get it out of the way to make room for those that will.  I only pressed the point because your idea is written such that you asked for many kinds of things to be backed up, and it happens that all those things (but one) are available in a single folder for just such a purpose!

Regarding the user.lib backup, I don't think it's an inherently bad idea. I just think it's going to require some diligent consideration because of the fact that NI doesn't control what goes in that folder or how it gets there. (If we were backing up vi.lib, it'd be a different story because we could make a lot of assumptions.) I can't think of how we could confidently back up code in user.lib without having some kind of manifest or INI file for it that describes where all its dependencies are on disk, too.

e.g. How would you back up the NotifyIcon API linked here? It depends critically on a few .NET framework classes, so restoring it on a system without the framework installed would be ineffectual. (The point is weakened by this particular code's method of distribution at the moment, but If it were properly distributed as an installer or VI Package, the author would write a function that checks the Windows Registry to make sure that .NET 2.0 or later is installed on the system, and it could throw an error if the check failed.)

Regarding merge VIs: Yes, they work from anywhere. A merge VI is really just defined by the palette you place it in; the code is identical to any "normal" VI you might write and store anywhere on disk. If you just need to back up your merge VI palettes, might I suggest an alternative design that helps you with your specific situation? (Disclaimer: This doesn't mean I think this idea is invalid!)

1. Create a folder in LabVIEW Data called Merge VIs.
2. Create a synchronized subpalette under user.lib and point it to that folder. Make a copy of the subpalette in your Merge VIs folder as a backup.
3. Now you can back up your LabVIEW Data folder and your Merge VIs will be included in the backup. If you ever need to reinstall LV, all you have to do is restore that subpalette from yoru backup by copying it over to the user.lib folder.