.Net events not received after LV 2013.

[codeman]

I have a LabVIEW application which was originally created in LV 2013 and uses a particular third party .Net class.  When I try to port to any later LV version, the .net events for that class are not received.  I've tried LV 2014 - LV 2017.  There are no errors or exceptions.  Everything appears to work, but the events just don't come through.  Unfortunately, the third party class library is related to a fairly complex application and is not easily shared.  I only have issues with this one class, but I don't know what it is about this class that causes the problem.  The same exact VIs work perfectly in LV 2013.  The class also works perfectly when called from a simple c# app.  Has anyone run into something like this?  Any ideas what the problem is or how to work around it?  Did something about the LV .net support change after LV 2013?

I had theorized that it might be some strange thread issue.  I tried running the VI in the UI thread, but no difference. 

I also tried to create a wrapper class in c# to relay the events through in hopes I could capture something useful in that debugger, but the events don't seem to be received by the wrapper class either as long as the wrapper is being invoked by LabVIEW.  It works fine if I call the same wrapper class from LV 2013 or a c# console app.  Any suggestions appreciated at this point.  Thanks.

[tyk007]

Hmm this is a bit tricky without any actual detail to look at. Some some things off the top of my head that might point you in a direction:

1. What is the source of events are being raised? Is it a custom event with simple delegate event handlers or is it raised through a framework (eg. Windows Forms, WPF any other UI framework etc.)
2. I have had applications in LV2012 upgraded to LV2016 with event handlers and they have run without any issues, despite the assembly targeting .NET CLR 2.0. I did have to perform a mass compile but this makes sense given I had compiled code removed from the VIs.
3. In most cases .NET event handlers are likely to be called by a thread other than a LabVIEW created thread. This is the reason why you have difficulty debugging the callback VI in LabVIEW - the thread that is executing is not one that LabVIEW created so there are no "hooks" in place for LabVIEW to marshall the thread back to the UI thread where debugging occurs. Again, this depends a little on answer (1) above.
4. I assume you have tried to delete the callback VI and re-create it?

[codeman]

The class I'm trying to use is a client side monitor for a remote service.  The client class just has normal events with delegate handlers.  I was able to get access to the client source code, and it appears that under the hood its using .Net Remoting with TCP; Though nothing seems to be amiss.  Its as though the server just isn't calling the client side interface functions; Except again, it works fine in LabVIEW 2013 and in any C# app I try it with. 

[CyGa]

What is the .NET framework used by your dll ?

Can you reproduce the behaviour within a simple VI ?

Have you tried deleting your constructors and rebuilding them again ? Then samething with the callback VIs ?

[codeman]

The dll was compiled with .Net 4.0.  I've replicated the problem with a simple VI built from scratch.  Its something about the interaction of LabVIEW with this particular class, but as I said the class is a client for a much larger server application and is not easy to share.  I'm going to see if I can reproduce this with a simplified .net server and client.  If I can, I'll have something I can share with NI tech support;  Maybe they can shed some light on it.

[tyk007]

Anything you can share with us would also help us too. Otherwise its a bit tricky to diagnose any further.

EDIT: One thing to try. You mention that you are accessing a remote .NET instance using remoting. That implies that the LabVIEW 2016 requires the relevant firewall permissions (potentially higher user privileges too) since it is the process hosting the .NET code -> CLR -> your assembly and any remoting connections.

[tyk007]

Here is a simple example I created in LV2016 with a basic assembly targeting .NET 4.0 framework (CLR 4.0). You call a method of the class for a message you would like it to send back to you (via an event) 1000ms later. The thread that actually runs LabVIEWs callback VI will be a ThreadPool thread created by the CLR; I did this deliberately to demonstrate the limitations of debugging callback VIs. This works fine on my machine; maybe you could try it on yours.

The code for the assembly is below:

[CyGa]

OK, seems to work fine on my computer running LV2016.

What I had to deal with before is that LV was unable to call the right function with newest .NET framework.

I usually resolved it applying this technique : http://digital.ni.com/public.nsf/allkb/32B0BA28A72AA87D8625782600737DE9

It doesn't seem to be the exact same problem here, but maybe you can give it a try...

[tyk007]

Another thing you can try is debugging the assembly to see if the event is being raised. Since you will be running with CLR 4 there are a larger number of debugging options available. Visual Studio will let you do this - you say you have the source for the assembly so if you build a new copy (debug build with pdb), insert into LV and then use VS to attach to the LabVIEW process you will be able to set breakpoints in the source. If you don't have VS then I believe the free SharpDevelop will do this too. You could also use a general .NET tracing tool as well but I find interactive sessions to be better.

[codeman]

Returning to this problem after some time, I was able to get some debug info from the server side.  On attempting to invoke the callback on the client interface, it reports "Failed to connect to an IPC Port: Access is denied." .  Did a little research online and found that this error often occurs if the server and client are not running from the same windows user.  This applies in my case because the server runs as a special local Administrator user.  If I launch LV 2016 as that same user, everything does indeed work correctly.  Of course, that is not really a feasible work around for my client application.  

Online discussions about the problem suggest I should change the "authorizedGroup" property of the server channel. I presume in my case that this would have to be applied to the client which is after all a server for the callback.  However, I'm not sure that this is possible without altering the third party client code.  I know that the client works from LV 2013 and from C# based test apps, but not from later LV versions.  I'm not using dot net configuration files in any of them, which suggests to me that LabVIEW is forcing settings on its own.