Error 1172, A .NET exception occurred in subVI after loaded dynamically from Top level VI

[SolarLR]

Hello, knowledgeable application engineers,

I have implemented a proof of concept for .Net Container and C# User Controls in LabView 8.0 Full Development System. The behavior of C# user control is performing well in C# test form and LabView top level VI. However, “Error 1172 occurred at Property Node, Possible reason(s): LabView: A. Net exception occurred” was occurred after .Net Container and Control relocated in SubVI called by “Open VI Reference” and “Call By Reference Node”. I have searched all knowledge base that mentioned copying control DLL to the same directory where all VI resident. Still run out of luck. Any hit can be provided?

[JonathanN]

Hi SolarLR,

I actually had a couple of .NET user controls I was playing around with in LabVIEW the other day. I tried out your scenario of dynamically calling the VI that contained the .NET control and my VI's ran fine.

Questions I can think of include:
- Are those VIs that host those .NET user controls part of a LabVIEW project? If not, try and put the VIs as part of your LabVIEW project and run the top-level VI from there.
- Does the .NET user control that you host in LabVIEW have references to other .NET assemblies? If so, where are they located relative to the VI?

If you were previously using LabVIEW 7 and are trying to following the same assembly location rules, you might want to check out this post. The rules in LabVIEW 8 and later have changed.

If you are still having issues after reading through that post and thinking about my questions, please post a small example of the issue. That way I can see how you have your architecture set up.

Thanks

Best Regards,

Message Edited by Jonathan N on 08-25-2007 05:08 PM

[SolarLR]

Jonathan,

Thanks your response.

I have attached a simple .net control, NamesControl.dll, with three VI files,

dotnetMainPanel.vi

dotnetSubPanel.vi

Splash Screen.vi

for reference. The NamesControl.dll just comprises three textboxes and one label to display First, Middle, Last Name from textboxes input. dotnetMainPanel will play the top-level VI with one NamesControl that visibility was controlled by visible button. dotnetSubPanel.vi is called by reference node when dotnetMainPanel executes also has it's NamesControl visible control mechanism. You will see the .net error popped up when dotnetMainPanel runs. The error can be eliminated by delete visible property node of UserContol1 in dotnetSubPanel.vi. I will set up a project which following your suggestion to check the concept works.

Meanwhile, could you send me a simple framework that work well with user control and sub vi call after inspect the attached files. That can guide me through all mist.

Regards,

[JonathanN]

Hi SolarLR,

By adding in some error handlers into your subVI, you can see the actual error that is being thrown (1172 is very generic). Basically the error comes up saying that "Cannot pass a GCHandle across AppDomains". This occurred in LabVIEW 8.0. In LabVIEW 8.2.1, that error is not thrown but after you run your application, restart LabVIEW, a internal error occurs. In LabVIEW 8.5, both issues are fixed and your code will run normally. To validate this, I would download the eval of LabVIEW 8.5 and test this out on your side.

We had some bugs regarding this issue in earlier versions of LabVIEW but atleast on this end of running your program under LabVIEW 8.5, it works.

Sorry for the inconvenience.

Also, I am not sure what you mean by framework. Are you looking for suggestions on properly using .NET controls and assemblies in LabVIEW? Or are you looking for more architecture guidance? In that case, you might just post your end-goal and see if other users on the forum can offer their suggestions (if its an architecture question, you might want to start a new forum post so other users can see it).

Best Regards,

[ashur668]

I am experiencing a similar problem when using a C# dll created using VS2010 (framework 4.0) and Labview 2013.

The exception is thrown when the dll is called from the unbuilt code, indicating that is cannot find the dll's config file which is in the application directory with the dll.

It indicates that it is trying to find the config file on my desktop...not sure why.  Hoping someone may know.

Also, when running the built Labview .exe, the exception is not thrown and the all portions of the solution work as expected.

[ikelli]

Hi ashr668,

This forum has not been posted on for more than seven years.  To get a better response from the community on this issue, I recommend you post your problem in a new thread so more users will be able to see it.