Robert,
I would suggest using what is called a "loader" program.
I came up with this solution a long time ago to get over all the many bugs, quirks, and missing features (such as placing items in folders) of the application builder. I also did it because of this very problem. The drawback of a loader is that your application is made up of only one executable (the loader) and all of your VIs as they are. However; the limitations of the app builder make the disadvantages far overshadowed by the advantages.
First, the loader:
A loader is a very simple program which uses VI Server to call your main program. You can even have a "Splash Screen" as your front panel to make it look very professional (the specs for splash screens are online somewhere.) You create this VI, verify it works, build it once, and never again have to deal with or worry about building your application. If you were so inclinded, you could even include a .ini file with it to configure this single program to use a bitmap and filename to make this a universal, build it once per version of LabVIEW and never again Universal Loader...
The target:
The bad news, like I said is that your target program remains in VI form, which means you have to be careful. My first suggestion, to ALL programmers, is that you always program in a target environment. This way, no matter what, you are always sure that your program is organized logically, and that at least your relative paths are correct. However; again, the advantages of this method are far reaching. The greatest advantage is that you never have to rebuild your application again, unless you change the name of your target main VI (which you shouldn't do anyway.) Also, you can add, delete, modify, destroy, create, purge, expunge, compile, redo, make up, revamp, or whatever you want to do to any VI(s) in your hierarchy and still not have to worry about rebuilding your application. I very successfully implemented this methodology in a military field test application with a great deal of success. Sure, we had a heck of a lot of files, but when all was said and done, when we backed up everything, our distribution copy, and development copy were one-in-the-same.
I know its a long answer, but I think you will agree that its a much better solution.
Of course, the alternative is not fun. You would have to be able to first read the contents of the .bld file. Then, you have to understand them. Its pretty much just text, but I can't understand it, much less begin to tell you how to. And don't expect NI to tell you anything, this is protected stuff, and I don't think you will see them publishing the information on how to break down the file, it would mean that just anyone could create a compiler...still, miracles happen. Once you have understood the file contents, you have to create a generator/modifier. Then, you have to read in your project to the generator/modifier, and have it maintain an updated copy of the .bld file at all times. not a fun prospect by any means.
