executable folders

[feriel0209]

Hi every one,

I want to built an executable having the same structure as my project.

In my project explorer I have many autopopulating / virtual folders.. But when I create the executable I have one folder named data where every thing is stored.

Does any one know how I can do this?

Thanks in advance for any help that you can provide,

Regards,

F

[crossrulz]

You handle that when you build your installer.  That is where you include all of your support files.

[Bob_Schor]

When you are dealing with Source Code (i.e. LabVIEW VIs, TypeDefs, and Classes), it is helpful (and sometimes necessary) to save them in separate folders as sub-folders under the main Project Folder.  This helps you, the Developer, keep code organized and segregated by functional unit.

However, when you build an Executable, most of the details about how the code is organized disappear.  The Compiler knows where each sub-VI is stored in memory and generates the appropriate machine code to execute the VI when it is called.  As (to a first approximation) it is all one big "chunk of memory", it makes sense for it to all be in one folder.

Now, there are some exceptions.  Some programs load pieces of code at run time.  I've not done much of this, myself, so I don't know if Best Practices are to put each of these external blocks in their own folder or in the same Data Folder as the main .exe.  But you certainly do not want (nor need) the Source Code folder tree in your Executable folder.

Bob Schor

[feriel0209]

I am builting the installer now.

I didn't find how. Please can you show me the steps or any helpful tutorial on youtube? The ones I have seen aren't explaining how.

Besides, I am using third party instruments on labview. How can I add their drivers?

Thanks in advance.

Regards,

F

[Norbert_B]

When buidling an executable, you have to take care of elements which will be included in the EXE and elements which have to be placed outside.

Bob talked well about the stufff which goes inside the EXE. This is what the developer usually doesn't take care of anymore once the EXE is being build; however, the other stuff can create real big headaches....

Traditional items which are NOT placed in the EXE:

- DLL, LVLIBP, OBJ, ..: Compiled files running in a runtime engine as ready to go code component

- INI, CFG, ...: Configuration (textual?!) files necessary for running the EXE

- PNG, JPG, DOCX, HTML, PDF,....: Support files for usability (e.g. user guidance, help files)

-...

When distributing the application, it is most often not enough to simply copy the EXE file. You also have to provide the additional components. And here many developer struggle:

- If components are loaded by relative path, the application and the support files *could* be simply copied as long as the relative paths are being kept. An installer can ensure this

- If components are loaded by static path, file copy usually fails. An installer can make sure that static paths are fulfilled... however, it is bad practise.

- Some components require registration. Only an installer can ensure this at at least some automated level

Norbert