Name collision error occurs when building executable

[stevengd]

I agree with Les here - it seems that these VI's, which are included with and intrinsic to the Labview distribution package should be renamed and located appropriately so as not to collide with whatever they're colliding with. Otherwise, every time someone includes a report generation VI in their code, the long list of warnings generated by the build process will cause them to pester NI experts on this forum. -Gerald

[Les__Bartel]

Hi Gerald,

I thought about requesting that the VIs be renamed.

1) This could break the code of those using those VIs.

2) NI may come up with a better solution.

A previous comment mentioned the namespace ...

My first though was C++ namespaces that allow the same name to be used in different namespaces without collisions.  Perhaps something like this can be implemented.  Then I continued reading and saw that the poster was talking about the (one and only one) namespace.

Namespaces would work very well for things like instrument drivers where we always want to use open (open.vi), initialize (initialize.vi) and close (close.vi) operations.

Just thinking out loud...

 - les

[Philip_Courtois]

It had to happen - I ran into the same issue after having developed a very large project with extensive use of cloned LabVIEW Libraries (*.lvlib). Wasn't the beauty of LabVIEW Libraries that you could handle multiple VIs with the same name simultaneously? LabVIEW will avoid the name collision by adding the namespace of the library itself to the name of the VI... In development mode that is. So why doesn't it add the namespace automatically when building the executable? I can get around the issue by using the "Rename this file in the build" option under "Source File Settings" in the Build Specification setup. But manually doing this for over 220 VIs seems a bit ridiculous - since all I'm doing is using LVLIBs for what they were intended...
 
So, honered LabVIEW R&D - is there already a plan to fix this issue or do you want us to create a CAR?

Message Edited by Philip Courtois on 10-01-2008 03:21 PM

[gmart]

Previous to 8.5,  an automatic rename happened for all library types. This unfortunately caused problems with LabVIEW classes since the VI names are important with dynamic dispatching. The model was changed in 8.5 so that conflicts would always result in external files rather than automatic renaming. This let the user take control of the process in case any automatic algorithm made the wrong choice in the renaming.

To ease the manual process, you can use project folders to help with the renaming. You can either add the libraries and files to a project folder and then apply a prefix to all files in that folder or you can create a folder under the library and then apply a prefix there.

This is a known issue that is actively being investigated.

[Philip_Courtois]

Thanks for the quick answer, George. NI Support still rocks!

I'll be able to live with the "Project Folder" workaround for now. By putting the folder inside the LV Library, it's still a quite elegant solution when cloning the LV Library.

[DonRoth]

Can you guys tell me the best way to handle the similar problem that is occuring BETWEEN LABVIEW files themselves during the build.  It has to do with use of the matrix functions.  Here is a screenshot of my problem.   It was not clear to me how I could rename for the several conflicst when I only see a box for for renaming one file name.  Do I separate the names by commas?

HELP!!

 

Thanks,

Don

Message Edited by DonRoth on 03-17-2009 10:48 AM

[DonRoth]

I am offsite today but I have a hunch that two different versions of the VI 'Multiply - CM,C.vi' are in my set of VIs comprising this project and if I find all instances are replace the instances to make sure they are all coming from one place, I might solve this.  (I don't know why this would have happened.)  Or renaming this particular VI (the other conflicts may be controls associated with that VI) might work.  I will report back on this when I try either later today or tomorrow.

Sincerely,

Don

[OliviaC]

Hi Don,

This is a known issue with LabVIEW and R&D is working on a fix for a future release of the software. At the moment the suggestion is exactly what you are attempting. Please post back your results.

[DonRoth]

Only way around this problem seems to be the following:

During the build, the name collision causes two folders to be formed that separate out the identically-named VI and ctl(s).  These folders are deposited in the same location as the executable.  The developer needs to send these folders to the end users and have them be placed in the same directory as the executable, or the developer needs to build an installer which should do this automatically.  I did not initially build an installer because the end users already had the LabVIEW 8.5 RTE on their systems and thus did not think I needed to do so.

So this would appear to be the workaround in my case.

Sincerely,

Don

[trosier]

Hi Folks - Outstanding discussion. I understand why this is happening and how to fix the problem in Labview. My problem is I am getting the same thing happening during a TestStand deployment. When the deployment completes these messages are in the deployment build message. I use this message as input, to a script that I have running the deployment builder from the command line, to an e-mail message to myself and some other developers. The message is inundated with these warnings all originating from the Reports libraries distributed with NI Labview. I am concerned that real problems may be masked or missed by people scrolling through the rather extensive list. Is anyone aware of how to silence these warnings in the TestStand deployment build process? I know this is a TestStand question but I came across this post when researching the solution to my problem.

Thanks in advance for any help,
Troy