Is it possible to derive a LabVIEW VI from a .NET class?

[MatthewZ]

Here is why I would like to do so if it is possible.

Our system makes extensive use of .NET remoting. Although we are able to get and set properties over a .NET remoting channel from a .NET object, I find that it is not possible in LabVIEW to register for an event over the remoting channel. LabVIEW gives error 1172 that, from searching this forum, I found is a rather general error. Unfortunately, LabVIEW is not passing on the exact .NET exception, and I offer this as a suggestion for future LabVIEW releases. If it were passing the exception message, my guess is that it would probably say that the class is not derived from MarshalByRefObject.

From the testing that I did, the only time that LabVIEW gives that error when trying to register to receive a .NET event is when the event is provided by a .NET object that is accessed through a .NET remoting channel. In all other cases except that one, I was able to successfully register for and receive .NET events in LabVIEW.

In .NET, it is only possible to subscribe to an event of an object that is accessed through a .NET remoting channel when the subscribing class is derived from the .NET class MarshalByRefObject. The derived class also needs to override the MarshalByRefObject member function InitializeLifetimeService. So, this is a second thing that I would need to do in LabVIEW if possible.

I did check documentation, and I did not come up with a means to do this in LabVIEW.

There is a "work around," however, in that a .NET wrapper class library can be written that subscribes to the event and then publishes that event on its class. LabVIEW is able to use that wrapper to subscribe to the remote event; however, this is the only means I have found that LabVIEW is able to employ to subscribe to an event on an object that is accessed through a .NET remoting channel.

I'm assuming, of course, that LabVIEW classes are not derived from MarshalByRefObject.

If it is possible to derive a LabVIEW vi from a .NET class, are there any examples available?

[Mac671]

MatthewZ,

Thanks a lot for sharing this with us it's a good to know thing , as for me I am in design phase for my interface that will interconnect LV and .NET so it is a good to know thing.

Although I cannot help you further I can only share my thought.

I think that if .NET documentation states that if you want to capature a .NET event you need the recieving end to do it you need use the "work arround" that you have stated here.

Since VI's are not .NET objects I do not think this concept of "inheritance" after .NET seems right, but a blue post here would be more clarifying so please treat this last statement only as my private thought

Thank You very much again for sharing this important info,
Maciej

[tst]

I'll say up front that I don't know anything about .NET remoting or events (I use LV 7.0, which was the first version which had support for .NET and I don't think supports either).

I can say one thing, though - LV classes are definitely not derived from any .NET class. LV is not a .NET language and it has its own seperate compiler and run-time. You can see that very clearly from the relatively inefficient interface you need to use to interact with .NET (although I seem to remember this was somewhat improved in 8.something, because you can now use dot notation to nest properties in a single property node).

If I really wanted to sound like a flamer, I would probably say that when LV first came out, not only was .NET not even a thought, but Windows 2.0 was barely crawling...

I suggest you read Brian Tyler's postings and blog. He used to head the LV .NET integration team and has a lot of details about how the two work together (including, I seem to remember, why LV returns the generic 1172 error for pretty much any .NET error or exception).

[Mac671]

Hi,

I've been researching the LabView interoperability with .NET a bit more. What I have come to is that I will not be using .NET remoting as Microsoft has introduced Windows Communication Foundation within the .NET 3.0 framework. Communicating with WCF between LV and .NET code seems to just as straightforward as remoting.

As it comes to subscribing and using .NET remoting and exceptions between applications I have read on the internet that it is not a very stable solution and has been a problem in many apps that use it, Tho I do not have any real-experiences with Events under .NET remoting so I am just passing what I have read.

As it comes to WCF it does not allow passing events form the client to the server app but it does allow for the programmer to make Callbacks between the client and the server code. But it seems that not allowing the use of events between the remote code is a deliberate act, due to the problems this has caused.

As I do not have access to LV during the weekend I will post on the forum the example on how to use WCF and LV on monday.

Matt I know that for You this could probably not be a solution as Your .NET code allready exists, and using WCF would probably mean a migration project, form .NET remoting to WCF first, but maybe WCF is a way to solve your problem.

Regards,
Maciej

[MatthewZ]

Hi Maciej,

Thanks for your input.

For us, migrating to WCF is not practical at this point. I would like to do so in the future, however, given that VS 2008 is technically in pre-release at this point and we need to ship and are, in fact, shipping our product, I cannot justify the effort at this time, nor can I justify shipping code built with a pre-release development environment (not to mention that MS probably has something in their VS 2008 user license that says that to be compliant with the license, you cannot ship code built in a pre-release version of VS.)

I have gone through all the "pain" of invoking and handling events in .NET remoting. When I was doing so, there was little on exactly how to accomplish what I wanted to accomplish, so I tinkered for a couple of weeks and figured out how to do what I needed to do.

Between remoting objects on a local machine, there is really nothing special that has to be done, however, if you are communicating between two distinct computers, there are security issues that need to be resolved. First, you must open your communication channel with a username and password, and if you are using the TcpChannel, that username and password must exist on both the local and remote computers. Second, if you call a property or method that is hosted on the remote machine in the handler of an event that is called as a result of an event on a remote machine, you need to do an impersonation of the logged on user at the local machine since the event is actually running as if it were a user from the remote machine and that remote user does not have permission to communcate back out through the remoting channel. If this sounds complicated, it is; however, the code to handle this case is rather simplistic.

As far as I can tell, though, once all the security issues between two machines are worked out, everything runs reliably.

For you, though, it sounds like WCF is an option, and if you are creating a new product with a future release date, I would agree. I started working on our product at the beginning of 2006, and we are now shipping it. The LabView "adapter" is a value add that some of our customers need. So, since our current product is based on .NET 2.0, that is what I have to use.

As we move forward with a new version of our product, I will be using .NET V X.X and whatever is used for communication at that point.

[Lycangeek]

Sorry for the late reply on all of this - but it looks like you guys had some good conversations about this...

Let me chim in with a few extra bullet points.

1. Error 1172 - This simply means "A .NET Exception Occurred". Not that helpful. In later versions of LV, we tried to put extra info into the message, but it's hard to manage. You can also use something like dbgview from sysinternals to capture the actual exception. We dump out the full exception, including stack trace, to the debug log which dbgview captures.

2. .NET Remoting is tricky to get right, as is common with many proprietary TCP protocols. Security, eh...anyone remember E_ACCESSDENIED you always got from DCOM? Using dbgview would help in these cases - same sort of debugging work as if you were using C# or VB.

3. Using WCF, #1 - WCF has been released (back at the end of '06). VS 2008 provides extra support for programming with it, but you can use VS 2005 as well. Feel free to use it. However, to create a web service will require some C#/VB code which then calls LV. LV cannot directly create WCF web services, but it can consume them.

4. Using WCF, #2 - I believe 8.20 is the version where we shipped the "Import Web Service" feature under tools->Import. Before that you can find it on ni.com somewhere. It uses ASP.NET Web Services, not WCF, but does the job in many cases. Of course, it doesn't create Web Services, it only consumes them.

[Mac671]

Hi,

As I have declared here is a simplistic example of using WCF and LV, for people stating to bite into the toppic.

The server is in binary form and it is based on the example that microsoft provides with the WCF documentation. This example is allover the internet so if you need to browse for sources feel free. (putting ICalculator, WCF in google should get you there).

I deliberately do not post the .NET sources as if you need to understand the mechanics of WCF than you will need to study it anyhow.
What I did post is the XML configuration file that will allow you to study how to set up your application to use netTcpBinding.

As You can see the LV mechanics for using the server is straight-forward, and there is nothing magic about it.

Brian,
Thanks for your interest and post. I will keep using web-serivices in the back of my mind but my primary goal was to use WCF and netTcpBinding as I do not foresee the need to expose my .NET service over HTTP. I will however keep the WCF configuration in XML, so if I am ever asked to add web-service support for this service for whatever reason only a change in the config fille shall be nessesary. ( This is why I liked WCF so much ;] you can add a new communication method really easy a big +, if someone ever worked with web-services or turned legacy-code to become web-service compliant... you will know what kind of mine-field I'm talking about :])

Thanks,
Maciej

PS. I used 8.5 LV and converted to 8.2 if there are anny issues let me know and I will fix it.

[Mac671]

About WCF and consuming the services in labview, just an update.

Unfortunately LV does not seem to be able to import a WSDL form a WCF Web Service.

http://forums.ni.com/ni/board/message?board.id=170&message.id=384789#M384789

Thanks,

Maciej