Cannot resolve conflicts in LV 2009.

[nathand]

Update: seems it wasn't just the DLL.  I'm seeing this mysterious dir.mnu conflict when I try to include a particular typedef control that is part of a library inside another typedef cluster on the front panel.  If I remove the control from the library, the conflict vanishes.  Oddly I'm using the same control elsewhere on the same front panel, also in a cluster (but one that is not a type definition), and that one doesn't seem to have any effect on the conflict.  Don't know if that helps you, but if you have time, try eliminating controls from your front panel (make sure you have a good backup first) and see if you can find one that's causing the conflict.

[poethomer]

Nathand, Thanks! I'll give it a try. I do use a common set of TypeDef controls for a number of Functional Variables throughout the project.

[nathand]

Don't know if you ever made any progress on this, but I've noticed one other thing that sometimes seems to cause this unexpected dependency to pop up.  If I have LabVIEW 2009 running with a project open, then open LabVIEW 2011 and open a VI in it, then exit LabVIEW 2011, I'll start getting the dependency error when I open some VIs from the project in 2009.  Exiting 2009, reopening 2011, exiting 2011, and then restarting 2009 and reopening the project seems to fix the problem.

[poethomer]

Thank you for the update, but I am still having this problem. The conflicts only appear on a dedicated lab system that only runs LV2009. My development system does not report any conflicts when the program is mass compiled. I only see this problem on the lab system at run time. Every VI halts during loading to dispaly a warning about the conflict. If "Ignore" is selected then the VI goes on to run normally. 

[MoReese]

I think nathand is on to it.  I had a similar issue with LV2010 recently when I copied a project from my developement machine to my laptop.  It occurred because some of my VIs were pointing to a .dll instead of the user library.  I resolved it by pointing to the appropriate .dll.