Name collisions in built applications

[Lee Robertson]

Hi,

I posted on this topic about a year ago and Kennon Cotton gave a very good explanation of what was going on. In my built applications, I include support for various components in the form of lvlib's that get called dynamically. When the application is built, the lvlib's are sent to a destination other than the executable. The lvlib's are contributed by several different groups so there are inevitably name collisions when the application is built and all the VI's are dumped into the same folder. I tried for a while to put each library in its own destination folder but this grew too cumbersome because of all the gymnastics you have to do to the build specification when you add a new vi to a lvlib. The solution I finally adopted was to load the dynamic VI's by their name space (e.g. Library_1.lvlib:Library_2.lvlib:Libraary_3:dynamic.vi). I wrote a custom "Build Path" VI that is name space aware. It walks the XML files to construct a path to a particular VI (the entries in the lvlib (XML file) look like Item Name=dynamic.vi, URL="relative path to the VI"). This scheme has a lot of advantages because it works the same in the development environment as it does in the built application (the lvlib's and lvclass's get modified appropriately when the application is built so that it all works out in the end). The problem comes when there is a name collision between VI's in the lvlib's and/or the lvclass's. Digits get appended to the end of the VI names such that no two VI's have the same name. Unfortunately, both the Item Names and the URL's get modified by appending the digits. I have written python script to go through the lvlib's and lvclass's in the built application and "repair" the Item Name entries by changing them back to their original form. My question is: under what circumstances will this get me into trouble?

I have included a lvproj file that illustrates what I am talking about along with two built versions. When you run the top level VI, enter a name space for one of the test VI's and it will display the path generated and the VI will be dynamically called (it will popup a window giving the name of the library and the name of the VI, or the message "VI not found" if the path generated is not correct). The possible name spaces are "Library_1.lvlib:Test1.vi", "Library_1.lvlib:Test2.vi", "Library_2.lvlib:Test1.vi", and "Library_2.lvlib:Test2.vi". The DefaultDir entry for the ini file needs to be set to the directory where you unzipped the example. Note that there is a name collision between Test1.vi in Libary_1 and Library_2 -- ditto for Test2. When the application is built Library_1.lvlib:Test1.vi gets renamed to Library_1.lvlib:Test10.vi and Library_1.lvlib:Test2.vi gets renamed to Library_2.lvlib:Test2.vi (both the Item Names and the URL's are changed). Therefore, when you run the exe in Test_Name_Spae_as_built, only the paths for Test1.vi and Test2.vi in Library_2.lvlib get resolved correctly.

In Test_Name_Space_modified the Item Name entries in the lvlib files have been changed back to the original VI names but the corresponding URL's still point to the renamed VI's. Now all the name spaces resolve to the correct paths and the dynamic VI calls are successful. I have not tried this explicitly with lvcalsses yet, but they will be implemented soon and every single one of them will probably have an initialize method so there could be an explosion of name collisions.

Once the application is built, what are the lvlib's sent to destinations other than the exe file used for? IS anything bad going to happen because the Item Name entries in the lvlib files have reverted to the original names before the name collision?

Any insight on this will be appreciated.

--Lee