I have a build spec where I copy a folder to the target directory. The folder name is in "always included."
The folder has subfolders and the subfolders have data files. The data files in the subfolders all have the same name, so for example we have
Folder Top (always included)
Subfolders one, two, three
and in each subfolder we have a data file named Data
When I build I get the following message:"Labview prevented a file name collision during the build. Duplicate file names cannot be copied to the same destination..." and it references the three data files named Data.
Well this is just crazy. They are NOT being copied to the same destination. Doesn't build understand a simple tree structure?
Solved! Go to Solution.
Thanks for your help.....BUT...
the KB article referenced refers to VIs with duplicate names. What I have are tree structured data files which I just want copied to the target directory. No linkages are required nothing at all complicated needs to be done. I am amazed (and appalled) that labview can't handle this. Of course I can manually copy the data directory to the target directory but then I have a problem when I build an installer because that directory is outside of the project.
You are certain that you told LV to copy the directories and not just the indiviual files?
The "Always Included" list of files are for dynamically called VIs or data/support files that need to be added as part of the build. By default, the destination of these files is the main destination or the EXE itself. For VIs that's fine since they can be part of the EXE. For data/support files, that is not the case, so Application Builder will automatically move files such as text files or DLLs into an external data directory. The structure in the data directory is flat by default so no hierarchy is preserved. You can see this setting if you go the "Destinations" page and select "Support Directory". Since the structure is flat Application builder attempts to prevent name collisions by creating unique folder names and placing files of the same name in different locations.
You can achieve the desired hierarchy by creating a custom destination in the "Destinations" page, setting the desired path and choosing "Preserve disk hierarchy". Then in the "Source File Settings" page you would select the folder in question, click on the "Set destination for all contained items" checkbox and select the new destination.
You can check if the settings generate the desired output by going to the "Preview" page and previewing the output files.
You do NOT have the files setup to be put into different directories. Just because you have files setup in different directories on the PC does not mean that it will do this in the EXE.
I have attached an updated build specification with added destinations and updated source file settings to place the files in the expected directories.
If you are planning on building an installer, why are you trying to do this in the EXE build?
thanks a lot. I was able to copy the entire hierarchical file structure by setting destinations and source file settings.
You also wrote: "If you are planning on building an installer, why are you trying to do this in the EXE build?"
I hadn't realized that this could be specified when building the installer.
It is a bit old thread but I faced this problem now.
The modified demonstration is also not a good solution because it is not general enough. If your subfolders contain subvi's and data files too, you have to specify this rule for each file. (subvi-> Application.exe, something.txt->Subfolder1) And if you have more than 3000 files in the "Top folder/Subfolder1" with other subfolders, then it takes a lot of effort to do this.
The best solution would be the support directory with the option "preserve disk hierarchy". Does anybody know why is this option grayed out in the application builder? I mean what is the reason, why the Support directory makes flat file structure?
If these are data files, do NOT try to make them part of your EXE build, do that in the installer.
If these are VIs that are necessary to build your EXE, you probably don't have any choice, although I question how you came up with 3000 files with duplicate names in a project.
Perhaps you should take a step back and explain the details of your situation, as your approach may not be best to begin with.