Best practices for hierarchy within project?

[Burt_S]

Another clarification: If you place all of the tags within one library and deploy it, does it deploy properly?  I just want to make sure that this is in fact an issue with the nested libraries and not something else entirely.

[Orion HE]

Grouping all of the tags in the same library without distiction of what address type each tag is is exactly what I am trying to avoid, but for testing purposes I suppose I can mess up my project, give me a minute.

[Orion HE]

I was not able to complete that test.  I moved all of the tags to the main library, and Labview had trouble finding VIs and then when I cancelled the build, it crashed.

[Burt_S]

I know this can be a bit of a hassle to rearrange your project, but it would be very helpful to know if this is an issue with deployment in general, or if its an issue with deployment due to using nested libraries.  If we can make this distinction, it will be much easier to suggest solutions to this problem.  Perhaps you could make a small example project that deploys and uses a single variable and see if you are able to get it to work properly.  That way we can try some more debugging steps without having to rearrange your current project. 

[Orion HE]

Ok, combining all of the tags into the main library and building an application and running it + refreshing the Distributed System Manager yields no deployed libraries.  Tell me if I am doing something wrong.  I select my top level VI as the start up VI, and the library with all my tags as the included file.  I also choose destination for the library to be support files, not included in application.  Let me know.

[Burt_S]

So it does sound like you are having a general deployment problem. In which case I would still suggest to use the nested library approach. For now though, lets stick with keeping everything in one library and see if we can get this working. Before we continue, have you followed all of the steps in this document. http://digital.ni.com/public.nsf/allkb/04D9A85B6967EE87862571140065EEC6?OpenDocument From reading what you have told me so far, it sounds like you have. I just wanted to make sure before I did any other research on what could be going wrong.

[Orion HE]

I have done all of that except "Enable enhanced DSC Run-Time Support".  I didn't think that applied to me, but then again, I am not sure what VI server is.  I don't think I am using any methods from it though.  I of course tried checking the box at one time which resulted in a fail for a different reason.  I have a .dll included with my project, and clicking that check box made my executable unable to recognize the .dll at it's proper location in the "data" support file and prevented my VI from even starting at all when run as an executable.  So there you go, yet more information that may or may not be useful.

[Burt_S]

So I have been doing some more research and I have another thing I would like for you to try.  Again, this would likely be easier if you created a new project that did something very simple using one or two of your variables.  However, either way, I am curious what happens if you right click one of your variables and got to properties.  Then change the "Bind to:" >> "Project Variable" to "PSP URL".  After selecting this, find the proper link for that variable.  Once you have done this, check and see if the variable will deploy from an executable. Let me know how this works out. 

[Orion HE]

Ok, after  much experimentation and engineer support, and more experimentation.  It appears the problem was related to the enhanced DSC runtime support AND apparently my deploy library.vi didn't like my relative path.  I chose a relative path because on the target machine the path will most definitely be different, and the documentation for the deploy library.vi led me to believe that I could use just the file name and not the full path.  So now my issue is to try and find a way to programatically find the path of the library I want to deploy.  Thanks for looking into this though.  I am now better equipped to help others because of this incident.