Looking for info on creating .NET Interop Assembiles

[John Lokanis]

I have decided to create a .NET assembly to expose an automation interface to my EXE. I dug around in the manuals and on NI.com for some info on how to do this but only managed to find instructions on how to build the assembly. I could not find anything about designing one. So, I was hoping someone on LAVA could point me in the right direction.

I am thinking is it a lot like web services. Perhaps if you have done this you can confirm or deny my assumptions:

1. The assembly operates in it's own application instance. Meaning the only way to talk to the EXE from the assembly VIs is VI server.

2. The connector pane of the exported VIs is used to set the input and output parameters of the exposed .NET method

3. The VI name is used to name the method.

Some questions: Can I only create methods or can I also create properties? If so, how?

I'm sure I will think of a few more questions as I dig into this more.

thanks for any help.

-John

[John Lokanis]

Still digging around for documentation on this. Let me know if you have does this before and have any good links to docs.

[John Lokanis]

Ok, so there is no documentation after all. At least non that NI has produced yet. But I did figure out some things.

1. The VI name and connector pane controls and indicators are used to construct the method call.

2. You can only create methods.

3. The .NET VIs run in their own application instance that has no persistence between calls.

4. Apparently, LabVIEW cannot call it's own generated .NET assemblies. This sure is annoying when testing them.

I will add more info here as I figure it out so the new person does not have to...

[Ton Plomp]

3. The .NET VIs run in their own application instance that has no persistence between calls.

Is it possible to load a functional global that keeps the ' application' alive?

Ton

[John Lokanis]

I don't think so. I was told that the VIs do not persist from one call to another. And are all basically reentrant so they cannot cross communicate.

Some new news:

LV2010 cannot call a .NET assembly created in LV2010. This is a known CAR. Might also apply to LV2009. Not sure about LV8.6 or earlier.

Also, I cannot call a .NET assembly build in LV2010 from C# either. It appears that the wrapper they add to the assembly is failing to detect the existence of the run time engine. Even on my dev machine. So, if you use .NET assemblies generated by LabVIEW, do not upgrade to LV2010 until there is a fix for this.

Oh, and see my bug about the build spec order here before that one bites you as well...

[John Lokanis]

Also, I cannot call a .NET assembly build in LV2010 from C# either. It appears that the wrapper they add to the assembly is failing to detect the existence of the run time engine. Even on my dev machine. So, if you use .NET assemblies generated by LabVIEW, do not upgrade to LV2010 until there is a fix for this.

Looks like the issue is limited to 64 bit OSes. We got it to work on WinXP (32 bit) but it fails to work on Win7 (64 bit). I'll post a CAR if one is issued.

[John Lokanis]

Ok, the issue with calling from c# was due to how the c# app was built. In order to make this work you need to set the platform properly in Visual Studio. Here is the explanation from NI:

If you set the platform target as any cpu, your app willto treated as x64 on 64-bit windows. In this case, if you do not have 64-bit LVRTE installed, it will throw an error. However, if you do have the 64-bit run-time, but try to run the 32-bitLabVIEW built assembly, it will throw an error as well. So, you need to select x86 as the platform inyour Visual Studio project, which will allow you to run the assembly with the32-bit LV run-time engine.

The support engineer promised to put this in a FAQ on building .NET assemblies in the near future.