LabVIEW Project and saving only the relevant vis

[m3rl3n]

I have a large development folder (and sub-folders) that I have used as a repository for all of my development plus test pieces of code. There are about 800 vis in the folder, but if I save my main VI off to another folder using "Duplicate Hierarchy to new location" I end up with 150 or so relevant files.  Unfortunately I have not discovered an easy way of copying the project over to the new location.

What I'm looking for is the ability within the project file to go through all of the files that in the project, determine if they are used in the VI hierarchy, transfer those files to my new location along with the project files. And then also reference all files in the new location, not the old.  This way I could build a number of slightly different programs, but which uses the whole power of my development vis that I may have already.

Dan

[zenthoef]

Why not just make a new project file?

Or, copy the existing project file on disk to the new location and use that? This would be done through Windows, not LabVIEW.

[m3rl3n]

Fair statement, but I don't want to have to wade through all 800 vis to find the 150 or that are actually being used by the main VI.  I want to be able to have a dialog in the project that allows me to copy the project to a new location and only take the VIs that are currently within VI that I have selected.

Dan

[zenthoef]

I think this may be what you are looking for. 

If you go to your LabVIEW Project Explorer and select Save As... There is an option for "Duplicate .lvproj file and contents" and under that there is an option for "Select Contents to Copy". That may not be exactly what you are looking for, but its pretty close.

[zenthoef]

In addition to what I said, maybe you could put those 150 VIs into a separate folder and then just transfer that folder when you duplicate the project?

[Ben]

I'd start by creating a source distribution in the project (use perserve hiearchy) based on the top level VI or if that is not enough create a Tree.VI (search for that) that holds all of the top-level VIs and all dynamics.

Run the Source Distribution to your new target and let it go.

If the project file does not have too much special in it just crate a new proj file in the new location.

If the proj has a lot of special stuff, then first remove anything that is in the proj that you do not want (and or turn of autopopulate of folders). Once it is is clean you should be able to use Explorer to move the proj file to the new location.

If you did you clean-up right, there should not be any conflicts or missing files.

As a last check open the Tree from the new location, show its hierachy, show full path in VI label then float over every VI to enuse they are all where they are supposed to be.

Ben

[m3rl3n]

zenthoef - I had thought of your solution, but that is assuming that you know all of the VIs that are being called and there would be a lot of transfers going on.  You would have to go into the main VI, do a duplicate hierarchy, get your list of files, then in the new project move each of those VIs over. Then hope that you hadn't messed anything up.

I will try Ben's suggestion. I'll have to go through it step by step because I'm not sure I follow every step in the first read...  I'll le tyou all know.

Dan

[Mark_Yedinak]

For future reference you may want to consider a more organized file structure on your disk. It sounds as though you have not only your project VIs but other general purpose Vis all stored in the same place on disk. If this is the case you may want to separate them out and place only project specific VIs in a project's folder.

[Peter_B]

---

@Ben wrote:

I'd start by creating a source distribution in the project (use perserve hiearchy) based on the top level VI or if that is not enough create a Tree.........

---

A similar problem has stumped me for years and relates closely to the solution you pose Ben.

I am frustrated that LabVIEW doesn't allow me to include the lvproj file into the source distribution.  I used to be able to do it in LV2009 via a workaround (I'd put the lvproj file into a subdir of the highest commmon DIR where all the project files reside on disk), but now LV 2010 intentionally seeks out and excludes my lvproj wherever I try to hide it !!

This article from NI Source Distribution Does Not Include LabVIEW Project File tells me to use the zip file distribution method instead.  Well, that ain't a solution for me as zip file distributions don't have:

• the 'Always Excluded' pane in the Source Files menu (there are project files that I don't need to distribute),
• the 'Additional Exclusions' menu item as for some reason there are a heap of vi.lib files also included into this zip (which I don't want or need). 

[Ben]

---

@Peter_B wrote:

---

@Ben wrote:

I'd start by creating a source distribution in the project (use perserve hiearchy) based on the top level VI or if that is not enough create a Tree.........

---

A similar problem has stumped me for years and relates closely to the solution you pose Ben.

I am frustrated that LabVIEW doesn't allow me to include the lvproj file into the source distribution.  I used to be able to do it in LV2009 via a workaround (I'd put the lvproj file into a subdir of the highest commmon DIR where all the project files reside on disk), but now LV 2010 intentionally seeks out and excludes my lvproj wherever I try to hide it !!

This article from NI Source Distribution Does Not Include LabVIEW Project File tells me to use the zip file distribution method instead.  Well, that ain't a solution for me as zip file distributions don't have:

• the 'Always Excluded' pane in the Source Files menu (there are project files that I don't need to distribute),
• the 'Additional Exclusions' menu item as for some reason there are a heap of vi.lib files also included into this zip (which I don't want or need). 

---

Yes I still that was a bad idea by NI.

I did try to log a bug about that but was fed some line about including the .proj file was not part of thier use case so... I think their use case is flawed, still.

Ben