Calling COM components running as a Windows 7 service (NOT A WEB SERVICE!!!) via LabVIEW

[OwlMan]

First, what I'm trying to do is completely new terrority for me and I've been looking everywhere unable to find found a solution. I've reviewed the following resources and have tried them out but to no avail:

[1] ActiveX and LabVIEW
https://www.ni.com/en/shop/labview/activex-and-labview.html

[2] ActiveX and COM -- Part I
http://www.ni.com/white-paper/2981/en 

[3] Tutorial: Configuring the Call Library Function Node to call a Simple DLL
https://forums.ni.com/t5/Developer-Center-Resources/Tutorial-Configuring-the-Call-Library-Function-N...

My problem is I have been given a COM which was installed to run as a Windows 7 service always running in the background (service.msc). So far it only seems to be a hunch that you shoul dbe able to either use:

A) ActiveX in LabVIEW to call the COM object by name or the .dll file.

B) Call the .dll of the service using Call Library Function Node

I can see the COM running as a service if I do ( service.msc). I also can see two .dll files associated with this service (they have the same base name as the running service). Lets say the service is called "TestService" then the other two .dll's are called "TestServicePK.dll" and "TestServiceXY.dll." In testing both ActiveX and Call Library Function Node I have tried calling both .dll files. When I tried the ActiveX approach I get "The selected file is not a .NET assembly, type library or automation executable."

Also the COM binaries were made in C++ but as I understand it should not be an issue at least for the Call Library Function.

This seems to be quite a corner case.

[Dave.C]

Hi OwlMan,

What result did you get when using the call library function node?

[nathand]

Do you have any documentation about how to call this service? Are there any other files (such as a .ocx) supplied with the service, other than the .msc? Is there example code in C# or VisualBasic?

[OwlMan]

Nothing catastrophic happened. In the functions dropdown I saw "DLLRegister, DLLUnRegister, DLLGetObject and DLLSomeOtherNameIForgotThatIsNotImportnant" functions, none of which were related to the C++ code functions I was expecting to see. But after some digging around I at least know part what the issue is.

In a nutshell I am trying to call unmanaged COM functions via LabVIEW which is not possible. LabVIEW is built around playing nicely with managed (.NET based) applications/code/dlls but not unmanaged. I've read around and will list a few things one can do should they dare venture down this similar path:

http://www.codeproject.com/Articles/165383/Integrating-an-unmanaged-C-lib-with-C

http://www.codeproject.com/Articles/14180/Using-Unmanaged-C-Libraries-DLLs-in-NET-Applicatio#xx23180...

http://stackoverflow.com/questions/7118314/c-sharp-wrapper-for-unmanaged-dll

There's a ton of information out there to help ne understand the primary issue with trying to call COMs in LabVIEW unfortunately if you are unfamilar with C++/CLR or creating interfaces in C# to unmanaged code the best I can say is good luck. All I can offer is the basic premise toward a solution.

In order to resolve this issue you basically have to in some way wrap your unmanaged code in a managed code environment (which uses the .NET framewrork). Create a .dll of the wrapper and from there you should be able to call it through LabVIEW. If I manage to get that solution I'll gladly share but its weeding through the bush at this point.

[candidus]

---

@OwlMan wrote:

Nothing catastrophic happened. In the functions dropdown I saw "DLLRegister, DLLUnRegister, DLLGetObject and DLLSomeOtherNameIForgotThatIsNotImportnant" functions, none of which were related to the C++ code functions I was expecting to see. But after some digging around I at least know part what the issue is.

These are the functions every COM object DLL must expose. You will see only these in the dropdown menu. The Call Library Function Node is not able to call the methods of a COM object. COM methods aren't exported functions. They belong to COM interfaces and are called via Invoke Node. The DLL must have a type library, otherwise this won't work.

In a nutshell I am trying to call unmanaged COM functions via LabVIEW which is not possible. LabVIEW is built around playing nicely with managed (.NET based) applications/code/dlls but not unmanaged. I've read around and will list a few things one can do should they dare venture down this similar path:

http://www.codeproject.com/Articles/165383/Integrating-an-unmanaged-C-lib-with-C

http://www.codeproject.com/Articles/14180/Using-Unmanaged-C-Libraries-DLLs-in-NET-Applicatio#xx23180...

http://stackoverflow.com/questions/7118314/c-sharp-wrapper-for-unmanaged-dll

You're mixing things up. LV works with COM objects. There are a few limitations however, e.g. there are restrictions which data types are supported. But this has nothing to do with managed vs. unmanaged code. COM is the predecessor of .NET . It was supported by LV before .NET even existed.

There's a ton of information out there to help ne understand the primary issue with trying to call COMs in LabVIEW unfortunately if you are unfamilar with C++/CLR or creating interfaces in C# to unmanaged code the best I can say is good luck. All I can offer is the basic premise toward a solution.

As said above, you don't have to know CLR or C#. Just try to understand how a COM client program works. Essentially you have to do these:

1. Create the COM object. In LV you have to use the Automation Open primitive. Return value is a reference to a COM interface.

2. Call methods of that interface. In LV you have to use the Invoke Node, not the Call Library Function Node.

3. Release the COM object. In LV you have to use the Close Reference primitive.

In order to resolve this issue you basically have to in some way wrap your unmanaged code in a managed code environment (which uses the .NET framewrork). Create a .dll of the wrapper and from there you should be able to call it through LabVIEW. If I manage to get that solution I'll gladly share but its weeding through the bush at this point.

No wrappers should be necessary if your COM object doesn't use exotic data types.

---

[rolfk · Accepted solution]

Actually COM != ActiveX!!!

ActiveX uses COM to implements its objects and also to instantiate and control them but COM is simply a binary API model and some functions to control the instantiation and lifetime of COM objects, nothing else. The only way to access COM objects properly (when no ActiveX type library is provided) is to have a C(++)  compiler that can parse the according header files to interface to the object interface methods. All ActiveX controls use COM to implement the calling interface of their objects but add also a type library to the DLL and a few other niceties such as object properties. This type library describes how the ActiveX methods and properties match to the actual COM virtual table interface pointers.

LabVIEW enumerates this type library in order to be able to interface to the COM interface of the Active X objects. A pure COM library lacks any and all of these niceties. If LabVIEW would support a COM interface node, its configuration would need to allow configuring all the things the type library describes. That configuration would require lots of manual configuration details, similar to what the Call Library Node has, only a magnitude more complex. So this is not really an option.

If your COM server DLL does not have an ActiveX type library interface, the only way to access it in LabVIEW is to either get such a type library as external interface (not possible for all COM features) or to wrap the COM server DLL by a traditional DLL, that translates the COM methods into standard exported C functions that can then be called through the Call Library Node.

Creating a type library from a COM DLL alone is more or less unfeasable. You should at least have the original IDL file that was used to create the COM interface. Writing a C(++) wrapper for your COM object is most likely the most practical approach, but will require some good C programming knowledge as well as some experience handling COM objects in C code.

[OwlMan]

That was a very thorough explanation Rolf. Thank you. After my original post I asked another engineer who had the same conclusion as you regarding your last comment "Writing a C(++) wrapper for your COM object is most likely the most practical approach, but will require some good C programming knowledge as well as some experience handling COM objects in C code." I've been hearing/reading some variation of this answer and the more I read up on te subject the more sound the approach seems.