How to protect vi.lib?

[xl600]

This morning, I couldn’t load any vis without hundreds of errors being reported.  It turned out that many vis (but not all) within multiple installed libraries (gmath, aalbase, aalpro) had somehow been repointed to copies of the library members within various source distribution builds.  It was so bad, I had to recover the affected libraries from incremental backups I fortunately had just started making.

How can I ensure the installed libraries are protected?  My personal feelings are that anything “installed” should never be modifiable outside of an installer, but with the default being to not separate compiled code in vi.lib contents, that just isn’t in the cards. So I’m not sure what to do in this node based license multi user environment where many devs share the same labview installation.  I’m afraid of hidden changes being injected into supposedly stable libraries now.

[Bob_Schor]

---

@xl600 wrote:

So I’m not sure what to do in this node based license multi user environment where many devs share the same labview installation.

---

Too much "sharing" is a bad thing.  Sharing source code causes problems, so we implement Source Code Control.  I've not heard of a multi-user environment where many developers share the same LabVIEW (note proper spelling) installation -- this sounds like a sure recipe for disaster (as you are finding ...).

Bob Schor

[xl600]

This particular issue was easy to remedy fortunately.  But the idea of multiple devs using a single (Very high cost platform bundle) test station laptop connected to a big PXIe RT chassis shouldn't be a surprise.  Each dev generally addresses tickets against the test system one at a time (Can't simultaneously because of licensing and confusion).

Honestly, I don't mind if we step on each other with any of the checked in code.  That's just normal SW development shenanigans.  The issue is with stuff that isn't checked in (LabView's installed libraries and stuff added via the package manager) and the ease in which those can be modified by anyone.

This isn't even a multi-user issue (Though that makes it worse).  I've caught myself looking at installed system VIs many times and making changes without knowing (Usually mistakenly moving FP objects) then doing the Save All or closing the project and saving everything.  Dumb I know, but I get so tired of those dialogs saying to save things I didn't change simply because I've switched from Windows to RT and back.  VIs should have an option to set them as read only in their properties and/or NI should abandon the embedded compiled code thing once and for all for al installed VIs and libraries (My opinion...).  Rant... rant...

Thanks for the input

[Bob_Schor]

Hmm.  I wonder if it would make sense to put vi.lib into its own Subversion Repository.  I don't know how you "manage" your Test Station Laptop, nor whether you are routinely using some form of VCS (I'm assuming the answer is yes, with several !! after it), and haven't thought about how to link this into your Work Flow, but consider the following:

• I want to build and run my code on the Test Station Laptop (hereafter TSL).  I assume that vi.lib is fully backed up (I can check, if it's under Subversion, by seeing if it has a Green Checkmark by the Folder).
• I run, build, test, etc.  During the process, I may or may not inadvertently make changes to vi.lib.
• When I'm all done, one of two things happens:
  • I again check vi.lib, and if the indicator is a Red Exclamation Mark, I do a Commit of vi.lib.  I do this while logged in as myself (so there's a "trace" showing "who did this"), and I make some comments about What I Was Doing.
  • Alternatively, some clever person writes a Logout script that does a Commit All if changes have been made.  This has the Virtue of capturing "Who Did What", but lacks the ability to add Comments.
• Some time later, you discover that vi.lib is not working properly.  You can Commit (to save the problem), then start Revert to Previous Version to try to go back to a Version that does work, and (with a little bit of luck) figure out what went wrong in between.
• Of special note is when someone Installs a Package or deliberately adds stuff.  You definitely want to do a Commented Commit at that time.  You might also want to put more than vi.lib in such a Repository ...

Bob Schor

[xl600]

I manage code via git and TortoiseGit.  Putting the entire vi.lib into source control might be one method, but I would have to somehow disable compiled code for every VI.  I wonder if anyone has ever tried that or what the ramifications might be (I think my compiled object cache is pretty big already, I wonder what it would look like if all the vis from vi.llib were in there as well or how long it would take to do mass compiles).

Thinking here, I better have a darn good backup before even attempting that.  I did write a recursive VI to disable compiled code for my own code (As a quality check prior to allowing anything into source control).