LabVIEW
Why can't I use Microsoft Message Queuing in Labview 64-bit mode?
Off-hand, I'd say that the 64-bit dll for the messenger - if there is one - isn't installed on the computer.
@kskaro2 wrote:
Thanks for the input, but I checked and all the necessary MQ dlls are loaded.
They are 64-bit dlls? This is important, because a 32-bit app can't call a 64-bit dll and vice-versa. I know you probably checked that, but since you didn't mention it, specifically, I thought I'd just make sure.
@kskaro2 wrote:
I understand what your concern is, but I was told by the person from our company, who developed the tool implementing the MQ messaging, that all necessary 64-bit dlls were loaded as part of the tool.
I figured you had that base covered, but I just wanted to make sure, since you didn't mention it explicitly beforehand. Now it makes it more complicated. I see rumblings about LabVIEW 64-bit and ActiveX on a Google search. You might want to look at that.
@kskaro2 wrote:
I have an application in which I am trying to use MQ messaging to talk directly to our database, to which we send and receive messages regarding the product we are testing. I am using Labview 2016 and Windows 10. The .NET version is 4.6.0 and the MQ messaging version is 7.0.1. The application runs great in Labview 32-bit, but when I switch to 64-bit it won't work, I get an Unknown System Error when I initiate the MQ connection function to send a message. I noticed that when it fails, the MQ reference input to the MQ Connection property node passes in a zero. When it worked it would pass in a valid reference number. I am trying to switch to 64-bit to enhance the memory usage.
Without seeing the code it is a bit hard to say more than general advice but if the emphasized text means what I think it does, this would indicate that the according .Net object never was successfully instantiated. There are a myriad of possible reasons for this including wrong parameters to the functions that are supposed to instantiate the object but it could be also something like a missing DLL that your library attempts to load dynamically.
You mention multiple DLLs that your messenger library uses and that could hint strongly at such a problem. Your knowledgeable internal developer person may know a lot about his particular software but not about how it might fail in an environment like LabVIEW.
If it references external DLLs either implicitly by static linking and letting Windows resolve it or explicitly by loading them dynamically itself it should account for the special situation that might arise in LabVIEW.
LoadLibrary() without a full path will always invoke the standard Windows search rules which are to search in the current process executable directory, then the system library directories and after that it fails. The current process executable directory however is in the LabVIEW development system the directory where the LabVIEW.exe program is located, not one of the (sub)directories where your VI is located.
