Cannot compile a functioning .vi that contains .NET functions; other related buggy errors

[Filipp]

I have a perfectly functioning .vi that contains .NET functions, such as "Constructor Node", "Invoke Node", "Register Event Callback", and "Property Node".

However, when I try to compile the .vi into an executable, I get the following error:
"The VI is broken. Open the VI in LabVIEW and fix the errors."  (see picture 1)

I get similar error when I try to use this .vi (lets call it dnet.vi) as a sub.vi of my application (call it myapplication.vi). While everything works OK in Labview environment, the compilation of myapplication.vi fails. In this case the error is (see picture 2):

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1502 occurred at Invoke Node in AB_Source_VI.lvclass:Close_Reference.vi->AB_Build.lvclass:Copy_Files.vi->
AB_Application.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->
AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW:  Cannot save a bad VI without its block diagram.
Method Name: Save:Target Instrument

I then go to the block diagram of myapplication.vi and  open dnet.vi. Now the dnet.vi comes up broken. At the same time myapplication.vi,
which was functioning just a second ago, turns broken too.
(see picture 3. Note: in the pictures "dnet.vi" is called "OCC_adapter_main.vi", and "myapplication.vi" is called "RI for Optigauge.vi")

If I now close Labview, and then re-open either dnet.vi or myapplication.vi, everthing is OK.

If I open dnet.vi through the project, it runs no problem. However, if I open  dnet.vi on its own, it comes up broken.

The error inside the broken dnet.vi appears to be in the Constructor Node. When I click on the "Select constructor" option, it comes
up with the error: An error occured trying to load the assembly.

[JonathanN]

Hi Filipp,

What version of LabVIEW are you using? In LabVIEW 8.5 we fixed a bug where users would receive error 1502 when building an application that used .NET Constructors, Invoke, or Property Nodes within a LabVIEW OOP Class VI. Is this your case?  If this is the case, the workaround is put any .NET constructors, invoke or property nodes that are used in a LVOOP VI in a subVI that is not part of a OOP class.

As far as you receiving the message "An error occurred trying to load the assembly" usually indicates that the .NET CLR cannot find the requested assembly. If you add the VI that uses the .NET assembly to a LabVIEW project and then put any .NET assemblies it references in the same directory as the LabVIEW project or one of its subdirectories, everything should work. It's recommended that any VI that uses .NET assemblies be part of a LabVIEW project because we create a separate AppDomain for LabVIEW projects and set the AppBase to the LabVIEW project home directory.

Hope this helps!

Post back if things are still not working.

Best Regards,

[Filipp]

Jonathan,

Thank you for your suggestions. I use Labview 8.5. I don't know the error number or at least  I don't know where to look it up.

After various attemps, I finally found a solution. I have to open the project only, without opening any .vi's from that project. In this case the build works. As soon as you open any vi's, the build fails.

The subvi (dnet.vi) and myapplication.vi are in different directories. I have to use dnet.vi with many other applicatioins, and placing all the projects together in the same directory kind of defeats the purpose. In order for the build to work correctly, however, I have to copy the .dll's used by dnet.vi into the directory with myapplication.vi. After all these manipulations that resemble a vodoo rather than a controlled software developement, the planets align and I can finally get to the real work. 🙂

Thank you for your help.

[JonathanN]

Hi Filipp,

The big idea to remember is that LabVIEW searches the directory that contains the project and all subdirectoriese of that project to find private assemblies.  As long as the assemblies you need are in the project directory we can find them.  We have tried to follow the .NET model of where assemblies should be located at. In the .NET model, the .NET CLR requires the assemblies to be either in the GAC or live in the same directory, or subdirectory of the application.

If you are experiencing errors in LabVIEW, I would like to investigate those if you can provide me with some examples and steps to follow. We definitely want to make the LabVIEW and .NET integration as smooth as possible for you.

Best Regards,