Application builder installers aren't allowing device receiving installation to find any project files

[dest2ko]

Dev system: Win7 Professional SP1 running LV2015 SP1 (15.0.1f10 32-bit, Professional)

Application system: NI TPC-2230 (WES7 standard, 32-bit) 

This application is the HMI application for a paired cRIO-9068 utilizing FPGA, serial communications, etc. I have created almost identical application installers for a few years now with this system with no issue. Recently, whenever I build an executable, build an installer and install it on the Application system, it will run the application utilizing the VI I have specified for startup, and then pop up a never-ending dialog that will essentially say it is attempting to load every single VI I use in the Project. The files it references when trying to load them are structured identically to my Project's file/folder structure. See attached photos. It appears as follows below: 

Loading:

C:\Source\NI\ ... \ controls

C:\Source\NI\ ... \ functions

etc

Searching:

Target system:

C:\Program Files (x86)\Application\instr.lib

It will hang on this target file repeatedly if I keep hitting Ignore. If I hit Stop, it will pop up a large list of various subvi's, typedef's, etc that I'm missing in the startup vi. 

I have no idea what I've done to throw this thing off, but it doesn't like it at all. I've never had these kind of issues before. Thinking back at what could have happened, I copied an existing project folder and it's contents to this folder and essentially started a branch copy in the current working folder I'm using. I only did this because I first used the "Duplicate .lvproj file and contents" option from within Labview and started everything that way, but with the same results. 

I have since gone back in and instead of instructing the Source File settings to Include if Referenced, I've just gone through every project item and folder I use and instructed it to "Always Include" within the executable. Still nothing.

Thanks

[dest2ko · Accepted solution]

Well after a couple days on this intermittently, I decided to do as I did before and duplicate the project into another folder, fix any dependency conflicts and rebuild. One thing I did differently this time was I disconnected a shared variable from its typedef, but that was really only to expedite all the conflicts I had and all the required VI updates I might have had to go through in order before resolving other conflicts. 

This seems to have resolved the issue and my startup subpanel VI now runs smoothly. Hope this is of some value to anyone going through this problem; maybe something just didn't translate well when I did it the first time. 

[billko]

A little late, but I found that if you have the project folder of the project that you copied at the same relative path as the original, you can have all sorts of conflicts that you won't see until you delete the original.  When I make a copy like that, I remove the original before opening the copy.  Perhaps this is what happened?

[dest2ko]

Thanks for that information. I will be trying that as I need to do a similar duplication soon. Will follow up on results.