Calling LabVIEW DLL from C# with char array

[yoda8579]

I am trying to call a function from a DLL generated in LabVIEW. I thought this was going to be far more straightforward than it is turning out to be. The function is described below:

void __cdecl Device_Init(charDevName[]);

So in my C# code I am trying the following:

[DllImport(@"Device.dll",CallingConvention=CallingConvention.Cdecl)]
private static extern void Device_Init(StringBuilder name);

I call this in my application by simply using the following:

StringBuilder devName = newStringBuilder(DeviceName);
Device_Init(devName);

Rather than getting any initialization on my device, I see a LabVIEW vi window pop up that has a title akin to a different method within the dll (i.e. AF1_GetPressure.vi). The application then hangs with this LabVIEW window popped up and I have to exit the debugging session.

I guess my question is how my function signature might be erroneous... I used StringBuilder as I found an example on this website that seemed to indicate that LabVIEW requires this variable type to better ascertain the number of characters in the array. https://forums.ni.com/t5/Example-Code/Using-NET-to-Call-LabVIEW-DLLs-That-Pass-String-Data-Types/ta-...

I have tried all kinds of different combinations of parameter types but I simply can't seem to get this to work. If I try calling the dll from C++ then I can get things to work. Although, oddly, I had to dynamically load the dll in C++ because I was getting a dll initialization failure when I tried to load it with the application.

Any help would be greatly appreciated! (Note, the LabVIEW DLL is from a vendor so I don't have access to the source code.)

[yoda8579]

As I was able to get this working through C++ I decided to run an experiment making a C++ wrapper for the DLL call that could be invoked from C#. In the processing of doing so, I found that, when debugging my C++ DLL wrapper, I got the same behavior (i.e. the application launched a vi window and basically froze just as though the call had been made from C# directly). I had basically hardcoded the working code from the C++ application into the wrapper DLL so, all things being equal, the call should have been successful. After looking at the debugging output stack, I noticed that when I call the DLL from C# the application freezes at:

'Application.exe': Loaded 'C:\WINDOWS\system32\nimercu.dll', Cannot find or open the PDB file

At which point I basically have to stop the debugger. If I call the dll directly from a small test C++  app then I get passed this module load but encounter a memory exception which the application continues past to complete the loading process:

'TestApp.exe': Loaded 'C:\WINDOWS\system32\nimercu.dll', Cannot find or open the PDB file
First-chance exception at 0x7c812afb in TestApp.exe: Microsoft C++ exception: LVExcept at memory location 0x023bc870..

This leads me to believe that in C# the debugger might be stopping at the memory exception while in C++ the code continues to function and ignores the error.

So at this point, I'm still stuck and can't get things working for my main C# application. Does anyone know of a way I can proceed? Even if I build in release mode and execute outside of Visual Studio this problem will force the C# application to hang.

[yoda8579]

Alright... So I tried to call the DLL from a stripped down application and was able to get the DLL to load properly. When I went back to my framework I discovered that, provided I call the DLL right after I initialize components on my main form in the constructor, the DLL will load. If, I wait until the OnLoad event, then the DLL call will no longer work. In the stripped down application, it seems to work no matter when I call the DLL so there is definitely something that happens in my main form in the application framework... I just don't know what that is...