creating Folder stucture Application Builder

[Sri.VI]

Dear Friends,

I was intending to populate a specific folder structure inside the BUILD folder as shown in figure. But after a lots of combination unable to find what I was looking for.

Please refer the figure and do suggest me if, there is any methods / tricks to achieve my goal.

Assumptions:

All Vis Should be Always Included into the Build Specification.

All Vis contains SubVIs and Vilib Vis.

Thanks

Sri

[palanivel]

Is this the way you are expecting?

If this is the case, Simple way is to create folder in the same order as you expect and add ----->folder auto populating.

[amitwadje]

hi,

@Sri.VI

are you adding files and folders programtically using libray and project properties ?

@palanivel

Yes, autopoulating is the way but you can not autopolate under .lvlib which we need in most of cases though this can be accomplished using properties of  Application and Project item and Library

--Amit 

[Sri.VI]

Thanks,,,

Structure is same but, the VI inside the sub folder contents subvi's which are in another location..

I wish to create automacctically this folder structure inside build folder while creating the labview exe.

[Sri.VI]

i am adding the Folder using Build Specifications. and wish to replicate the same folder structure inside build folder..

[palanivel]

I guess this can be done, while creating installer....
while creating exe it's not applicable....

pls check by adding folder format under source file settings...

[amitwadje]

Hi,

while creating Applicaption(EXE) folders can be added easy but creating Installer, I usally add them as autopoplating in project first and then add this autopopulated folders directly in build sructure. have look at this

[palanivel]

Above picture representing installer rite?

[amitwadje]

yes 🙂

[Bob_Schor]

I don't understand what you are trying to do.  I think you are trying to build an Executable from a LabVIEW Project that is organized as a set of Folders inside a Top Level Folder.

If that is correct, then you should not try to replicate your folder structure in the Build!  The structure of a Build is a single folder that holds the Application (the .exe file that results from compiling and linking together all of the LabVIEW VIs and support VIs referenced by your Project) and giving you a single file (My Application.exe).  It also provides a few Configuration files (My Application.ini and My Application.aliases) in the same Folder, and might have a Data sub-folder where files that "need to be available", but might not be directly linked by the Builder, are located.  Most of my Executables just have the three .exe, .ini, and .aliases files present.

When you build the executable on your own PC, it links to the LabVIEW library routines whose locations it already knows (they're usually in Program Files\National Instrument\LabVIEW 20xx or similarly-named folders).  If you want to run this code on another PC that does not have the LabVIEW Run Time Library installed, you can create an "Installer" that will package up the additional files and create something that, when you run it, will "install" the Run Time Libraries and the Application.

I've only rarely done this (and, I confess, not recently) -- it can be a little messy.  I'm not delivering to Customers, but rather providing routines to Students, so it's a little more "hands on".  What I've done is to provide the Build (meaning the folder containing My Application and its supporting files), which they can copy to their PCs or just run directly from a Share, and also pointed them to an Executable that will install the appropriate LabVIEW Run Time Engine on their PC.  We've "standardized" on LabVIEW 2014 (for now), so everyone has the RTE installed, and only needs to pick up the latest Executable.

Hmm, are you trying to do a Source Distribution?  If I've gone off on an irrelevant tangent here, I apologize.  Yes, if you are trying to distribute the Source, then you may want to keep track of the existing file structure.  [How embarrassing if I've been ranting away on the wrong issue ...  I'll go away, now ...]

Bob Schor