Move all dependencies into project directory

[Niatross]

Hi All

I am trying to improve how I archive old projects, specifically handling non native LabView dependencies (e.g. User.lib and inst.lib)

Is there a way of automatically moving all dependencies in these folders into the project directory (and update all references) so that a project can be archived along with all the necessary 3rd party VI's.

I have opened one project too many projects that has loads of missing VI's because the previous person has been using an obscure instrument driver stored in that they have stored in their local instr.lib folder which they haven't included anywhere that I have access to it.

My only solutions so far are:

- Use the save for previous version, but I don't like the fact that the entire folder structure is copied, I would rather have all non native LV dependencies moved into a folder called 'dependencies' in the project directory

- Don't store anything in user.lib or inst.lib (I quite like the convenience of having them stored in the palletes though. I would also like to have my own pallete of my reusable VI's as well but have avoided this for the reasons in this post)

- I am guessing I could write something in VI scripting to do this, but I was hoping that LV had something built in before I started doing this.

Any thoughts would be appreciated.

[GerdW]

Hi niatross,

my use case:

I don't use the user.lib/instr.lib in the LabVIEW default directory, but instead I keep a folder (named "Projects") where all LabVIEW Projects are saved in their own folders. Here I also have a "libs" folder with all reusable code.

This allows me to easily include ALL stuff within my SVN repository, much better/easier than to include user.lib (or even forget about it when committing)!

[Niatross]

That is my preferred way as well at the moment. It is just a shame that there is no way of creating a palette from that folder (that I know of).

A nuisance I think I will just have to live with.

[billko]

---

@Niatross wrote:

That is my preferred way as well at the moment. It is just a shame that there is no way of creating a palette from that folder (that I know of).

A nuisance I think I will just have to live with.

---

I don't think you should be making palettes from those folders.  Those folders should be source folders.  Make a distribution, and that goes into your user.lib (or wherever it should go).  Even better, use VIPM to make an installer that will do that - as a bonus, you can define your own palettes.  And with the pro version, you can even have them appear in your right-click --> create menu.

[Kyle97330 · Accepted solution]

I've written code for a special "Build" VI that ensures every dependency of all included VIs except vi.lib files has been committed to source control. 

Then I just have every directory that I have in instr.lib or user.lib have its own path in source control as well.  Managing a dozen or so user.lib/instr.lib folders and updating/committing them as well can be a bit annoying, but I find it better than having one "mega" library folder with everything from every project ever in it.

There's an additional option that I turn on for "release" builds (as opposed to "testing" or "qualification" builds) where it not only verifies every dependency is committed, but also makes a text file log containing both the exact path to the file in the source repository as well as the actual last commit number, since there's always a chance that the file was committed to source control but a different user or PC later uploaded an updated version that didn't make it to my local PC. 

So if I ever need to replicate a build exactly, or produce an audit trail for one already made, I can do so as long as the source control server still exists.

I did this with the SharpSVN DLL, by the way, if SubVersion is what you're using you could probably use it as well.

[Frozen]

I really do not like the instrument drivers in <C:\Program Files (x86)\National Instruments\LabVIEW 20XX> either!

I am not sure why you would recommend *not* to create palette from those directories. It is pretty simple to do.

I would suggest that you DO use your source code (not user.lib)... or else it will come back to bite you later. IE you tweak the user.lib version of the vi, because that is the one you  are using, then later someone else tries an builds it only to find out that they do not have the tweak you made!

I usually use a common SW directory inside my source code repository directory and use it directly from there... At least you do not have duplicate vi's on your PC... because we all know how much LabVIEW likes that.

At a previous company, I had a utility that would verify that all the code was checked in and not modified (using SVN) haven't got around to it at the new company (using Perforce. ugh)

[Niatross · Accepted solution]

I think Kyle's response was closest to what I was after. Although I haven't used SVN before so am not 100%.

I have ended up writing something where I can select my top level VI's and it will go through and move everything which is in user.lib (I will extend it to inst.lib at some point) into a user specified directory.

This means that I can keep on copy of all of my reusable VI's somewhere (user.lib now that I have done this) and when I have finished a project and either archive or send the source code to the customer I can run this and it will move all of my dependencies into a single folder structure.

I have also decided to create a a palette for each of my current projects and store it as a .mnu file within the project directory. In this I am putting all of the project specific VI's that I use on a regular basis (queue registries etc)