calling a 64bit driver in 32bit LV using .NET

[Dave_Thomson]

    With a "normal" driver, e.g. a dll, if you have 32bit LabVIEW (on 64bit Windows), you need a 32bit driver. I was wondering if that is still true if the driver is called through .NET. E.g. we have 32bit LV 2018 on 64 bit W10. A particular hardware vendor has both 32 and 64 bit drivers for their hardware, but the group I'm working with already loaded the 64bit version, since they started using the hardware with the vendor's canned software app. So I'm wondering if I can call the 64bit driver in 32bit LV given that it goes through .NET. I'm guessing not. I did find this link that suggests that it doesn't generally work:
https://forums.ni.com/t5/LabVIEW/not-able-to-load-net-32-bit-DLL-in-labview-2010-64-bit/m-p/1601704#...

That suggests that you need a wrapper specifically to translate bitness. I could also try to install the 32bit driver simultaneously with the 64. Or remove the 64 and then install the 32.

TIA,

    DaveT

[rolfk · Accepted solution]

That depends on a few things.

First in .Net an assembly can be CIL (when it is compiled to the Common Intermediate Language platform, which usually means that it was written entirely with C# and compiled explicitly to "Any CPU" target instead of a specific platform) in which case it is architecture agnostic since it is not executed directly on the CPU but in the .Net runtime which translates it through its Just In Time (JIT) compiler to whatever the current CPU mode is.

Or it can contain binary compiled code for a specific CPU architecture such as x86, x64 or ARM. In that case it can only be executed in the context of a process that runs under a compatible CPU mode.

There are also mixed mode assemblies, which contain both compiled target CPU code and CIL, but for the purpose of execution they have the same limitation than pure binary compiled assemblies.

Even if the assembly itself is in CIL, if it calls native DLLs directly through .Net Interop or similar, it is tied to the target mode of that native DLL since it has to load the DLL into memory and the Windows module loader refuses to load DLLs into memory for execution purposes when the current process isn't using the same CPU mode than the DLL is for. This is usually the problem for most device drivers. The .Net assembly itself is usually written in C# anyways but it is just a .Net wrapper around a binary driver written in C or C++ (or whatever else, could be also a LabVIEW DLL in fact) that implements the real business logic and is compiled for a specific CPU.

In ActiveX it was possible to execute non native components IF they were properly registered. ActiveX allowed remote execution through DCOM, which was originally meant to support components located on other machines, but it also supported so called out of process invocation where the ActiveX component was loaded into a binary compatible proxy process that acted as host for the component and then all calls were marshalled across process boundaries through DCOM (using pipes, shared memory, NetBEUI, or TCP/IP under the hood). This worked but was of course slower than direct invocation. And DCOM was also quite complicated and could have strange interactions with the main process since the synchronization was tied into the main threads UI message handler loop (the same as the famous LabVIEW root loop) for backwards compatibility with Windows 3.x. And DCOM was of course a big security concern and the protection needed to make it not a major attack surface soon made it pretty unusable for anyone who hadn't studied the entire DCOM security model in depth.

For .Net such generic out of process mechanisme doesn't really exist. A driver could implement it itself but I only have seen that once so far and it was not a seamless experience for sure. You would have to do that yourself by creating a 32-bit application that uses this driver and then talk to it through interprocess communication (nowadays anything but TCP/IP is generally more trouble than necessary). You could implement your own TCP/IP server in that app and talk to it or you could use the VI Server protocol to call into the process from your other LabVIEW application.

That all said, if there is not a very good reason to stay in 64-bit such as other drivers that only exist in 64-bit or you plan to do Vision with many large images, then the most pragmatic albeit not very attractive looking option would probably be to just wipe the current 64-bit installations on all systems and install 32-bit LabVIEW instead. You can also install them alongside each other, you just have to make sure to start the correct one. Any LabVIEW code written already should pretty much load into the 32-bit version of LabVIEW just as well.

On reading it again it seems I misread your message (actually didn't quite read the last two sentences). Is there a problem with installing both versions of the driver? They should be able to coexist on a computer unless the developer did some shabby things or the installer for the driver is pretty borked. You could then still use the 64-bit driver in the vendors own software and the 32-bit driver from LabVIEW.

[Dave_Thomson]

Thanks for the detailed explanation, Rolf. I figured it wasn't simple, but didn't anticipate all the permutations you described!

There are a number of paths forward, including those you suggested. I was just curious if the path of least resistance was likely to work. I think the answer is: not likely.