Combine LabVIEW Project into a Single File

[xlaurencha]

I think it would be a cool feature if LabVIEW projects could be a single file containing everything instead of multiple files and VIs.  And individual VI's could then be converted to projects or added to projects.  Additionally, there could be an easy to find list of all of the toolkits, modules, and libraries that the project requires.

Something like this could make it very simple to move LabVIEW projects between computers, and would help keep project files from becoming scattered and disorganized on a user's hard drive.  (Without using some sort of version control).

[National_Burritos]

Interesting. Not sure if anyone else can chime in, but I feel as though this would at the least result in significant load times for large projects and applications. 

[AristosQueue (NI)]

xlaurencha: This is an idea that comes up from time to time. We do have plans to work on something like this. In order to better serve this use case, please answer a few questions:

1. For distribution, how is this any better than a zip file? If all of your files are in the same directory with your project then zipping is easy. But if your project relies on external files (like VIs shared by multiple projects) then both the .zip and the single-file-project have the same problem. What do you imagine would be better if you had a single-file-project for distribution specifically?

2. Would you have problems with source code control? A single file that gets checked in and checked out is going to have very rough grain revision control. Are you going to want some mechanism for unpacking and repacking the project? In other words -- is this single-project-file something you always want to work with or something that you would package up from time-to-time?

3. How much do you interact with third-party files (images, HTML documents, etc)? Would you need/want the single-file-project to aggregate non-LV files even if that meant that such files could only be edited by launching LV and then asking LV to create temporary files for the other editors to work on (i.e. save your text file to a temp location before asking a text editor to load it)?

National_Burritos: All the R&D testing says that load time should decrease significantly... a sizeable chunk of our load time (indeed, any application's load time) these days is disk seek times -- hard disks have gotten very large and files can be scattered far afield. The more you reduce the number of files, the more you reduce disk seeking. The OSes help with this, but nothing helps as much as reducing file count for load time. This is one of the reasons that we continue to evaluate single-file solutions despite their obvious drawbacks.

[xlaurencha]

1. I've encountered a few situations where one person develops code and doesn't keep the files in the same directory for whatever reason.  It can then be very difficult for a new person to come in and pick up where they left off, especially if the files need to be moved to a new computer.  Having the entire project be one file somewhat forces the user to keep everything in the same place, which would make this process a little easier.

2. That's a good point.  I think it would be ideal (for me) if you could develop in either state.  For most small projects, I would only want to unpackage it from time to time, but the ability to get at the internal files would be nice.  With a large project with a lot of files, I think I would want to use subversion and develop the project in an unpacked state.  

3. I mainly work with text or TDMS files, and I think I would want those to be saved by default in the same folder as the project is located, with maybe an option to include them in the project (for example, a list of files in the same folder with checkboxes to include or exclude in the packaged file).  If the non-LabVIEW files had to be included in the packaged file, I think that would be ok as long as when I opened them it worked fairly seamlessly - as in, I could double-click on the file and it would open in my normal default editor such as Notepad or Notepad++.

Thanks for taking the time to follow up on my post!  Let me know if I can answer any other questions.

[Bob_Schor]

I've adopted the opposite tack, which works very well for me.

1. I go to some trouble to keep each Project in a single top-level folder, with sub-folders that divide the files in Documentation, Resources, Host Code, Real Time Code, etc., with further sub-folders in the Code folders for Utilities, TypeDefs, Action Engines, etc.
2. The Project "virtual file" structure basically duplicates the structure of the top-level physical folder (although I don't put the contents of such folders as Documentation within the Project).  This makes it easy to construct the Project, and to do a "reality check" to ensure that all the files are present-and-accounted-for.
3. The top-level folder is a Working Copy of a Subversion repository.

The "down side" is that some "common Utility VIs" that might be used in several Projects end up appearing in multiple folders.  I tried doing this both by having a "Common Folder of Utilities" that I could include in all of my Projects, but found managing this (particularly with the parallel use of Version Control) much more trouble than simply providing each Project with its own copy.

This provides me two ways to get the latest version of my Project -- I can run Subversion and do a CheckOut or Update, or, if I'm remote without access to the Repository, I can have previously copied a single Project Folder and know I have all the files I'll need.

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.