labview 2011 file layout in executable

[syang]

I am working on upgrading my projects from v8.6 to 2011. one thing i noticed was that the file layout in the built executable has been changed to treat the executable itself as the root directory of the code sources.

To better address my problem, i would like to present an example as below:

I have two projects, A and B, where B is built on top of A. Their paths are:

C:\Workspace\ProjectA\source\Always_Included1.vi ...

C:\Workspace\ProjectB\source\Always_Included2.vi ...

in the built executable(ie. Application.exe) i found that all VIs were located under such as:

Application.exe\Workspace\ProjectA\source\Always_Included1.vi ...

Application.exe\Workspace\ProjectB\source\Always_Included2.vi ...

Since the "Workspace" is just a variable name for one of my workspaces, I am wondering if it's possible to make the built executable to start with one level deeper, such as:

Application.exe\ProjectA\source\Always_Included1.vi ...

Application.exe\ProjectB\source\Always_Included2.vi...

*notice that the "Workspace" has been omitted.

Thank you.

[Doug-B]

Based on what I can tell from your post it seems like you are trying to specify where your .exe file is saved. You can specify where that file is saved when you compile your .exe file when you build that executable in LabVIEW. If this is not what you are asking, please feel free to reply with some clarification and I will continue to try and help.

Good Luck,

Doug B

[tst]

I don't think there's a way to really control this, as this is something which is done automatically by the application builder.

A couple of options I can think of:

1. Place the top level VI in a level above ProjectA and Project B. This might cause the EXE to consider that as the main folder and start from there.
2. Check the 8.x check box in the Advanced page of the build settings. This will cause the build to be flat instead of a hierarchy, but I wouldn't recommend that, as that's basically a flag for backward compatibility.

The real question is what's your actual problem? Most people don't care about the actual location of the files inside the executable. If you do need access to a specific file, using relative paths is generally enough, as they stay the same inside the EXE. Another option which people use to control this is to direct some VIs to be saved outside the EXE (the build spec allows you to do that), but that's usually for specific use cases, such as calling plugins.

[syang]

Thanks for the reply.

The reason I want to do this is because we are keeping a very large source code depot with different branches. The directory "Workspace" as given in the example could be considered as a branch. All those dynamic loaded (i.e. Always_Include1.vi) VIs would be launched based on a configuration file. 

This is why it matters to me. If the builder takes "Workspace" as the top hierarchy, I would have to reconfigure the config file for every workspace/branch. Furthermore I am not the only developer here. Everyone is working on a few different branches/workspaces. Having a one-for-all config file can save us a lot of time.

[syang]

Hi thank you for the reply.

What i was asking was if it is possible to manipulate the folder structure in a LV2011 build.

Say LV packages the VI "Always_Include.vi" into this form:

<Application.exe>\Workspace\DirA\DirB\Always_Include.vi

Can I make LV to generate the build as:

<Application.exe>\DirA\DirB\Always_Include.vi

*Notice the original top level directory "Workspace" is omitted.

[tst]

If the VIs are built in to the EXE, that means they're known at build time. If they're also known at edit time, I would suggest simply using a static VI reference to automatically include them in the build and get their path as well.

If that doesn't work, I would suggest using a base VI, whose reference can be static, and then use that to get its path and build a relative path to the VI you want (which would always be constant relative to the base VI).

Other than that, I don't know what to tell you. While the rules that LV uses to determine the structure inside the EXE are simple and basically correspond to the original hierarchy, it's not something that you can control directly - you would need to figure out how to change your code structure so that it's built how you want, which I doubt is worth it. Generally using relative paths or statically loading is better, although, to be fair, I don't use branches, so my code is generally static.

[syang]

Using static VI sounds a very good option. I will try it. Thank you.

Also I have managed to rearrange the folder structure by configuring Destinations in build specification. It works 🙂

[gmart]

There is no way to manually change the way the directory structure is generated. Application builder will look at the files included in the build and determine the most common root path and then build a hierarchy from there. Based on your example, if you are just including the VIs under ProjectA/ProjectB, then there should not be a "Workspace" directory. If you additionally included a VI that was located in the parent directory of "Workspace", then the common path would be the next directory up and "Workspace" would then be part of the path to the VIs in the EXE.

Without knowing more information about your setup, it's hard to tell if that is the issue. Would you be able to include a simple example that demonstrates this issue?

[syang]

Hi George,

Thank you very much for the heads up. I just checked my project in the Files view. You are right Besides the files in the "Workspace" the project is also referencing another DLL that's located under a directory parallel to my "Workspace". I will correct this misreferencing then see what happens.

But back to the executable infrastructure point, I was able to manually set a VI (...Workspace\ProjectA\source\test.vi) to be located at <Application.exe>\custom\test.vi by configuring a new destination named "custom" with path points to the EXE inside the build specification.