We Keep Coding

P/Invoke Calls Failing

I have the following struct defined in C++:
struct GraphicsAdapterDesc {
// ... Just some constructors / operators / destructor here
DEFINE_DEFAULT_CONSTRUCTOR(GraphicsAdapterDesc);
DEFINE_DEFAULT_DESTRUCTOR(GraphicsAdapterDesc);
ALLOW_COPY_ASSIGN_MOVE(GraphicsAdapterDesc);
std::wstring AdapterName;
int32_t AdapterNum;
std::wstring HardwareHash;
int64_t DedicatedVMEM;
int64_t DedicatedSMEM;
int64_t SharedSMEM;
int32_t NumOutputs;
};
In C#, I have a 'mirror' struct declared thusly:
[StructLayout(LayoutKind.Sequential)]
public struct GraphicsAdapterDesc {
string AdapterName;
int AdapterNum;
string HardwareHash;
long DedicatedVMEM;
long DedicatedSMEM;
long SharedSMEM;
int NumOutputs;
};
I've tried to be really careful about matching up the widths of the variables (although I'm a bit unsure on what to do with the strings exactly).
Anyway, I have the following exported C method:
extern "C" __declspec(dllexport) bool GetGraphicsAdapter(int32_t adapterIndex, GraphicsAdapterDesc& outAdapterDesc) {
outAdapterDesc = RENDER_COMPONENT.GetGraphicsAdapter(adapterIndex);
return true;
}
And, the following extern method in my C# app:
[DllImport(InteropUtils.RUNTIME_DLL, EntryPoint = "GetGraphicsAdapter", CallingConvention = CallingConvention.Cdecl)]
internal static extern bool _GetGraphicsAdapter(int adapterIndex, out GraphicsAdapterDesc adapterDesc);
However, this doesn't work right when I call it. I get a different result depending on whether or not I'm compiling in x64 or x86 mode (both the C++ DLL and the C# app are compiled as x86 or x64):
In x86 mode, the call returns, but the struct has 'nonsense' values in, and the strings are all null,
In x64 mode, the call throws a NullPointerException.
My expectation is that I'm doing something wrong marshalling the strings, and that I need to specify 'wide-mode' for the characters, but I don't know how (or if that's even the right option).
Thank you in advance.

C++ types are not compatible with C# unless they're wrapped in managed C++. and you're using std::wstring which cannot be marshaled into .NET.
To interop successfully you'll either need to use a wchar_t[] or a whar_t* and tell C# now to marshal it.

I don't know what your macros are doing but this will only work if your c++ type is POD. c++11 Has an expanded sense of POD but I don't think you meet the expanded criteria anyway. Otherwise you can't guarantee layout. If you want to export your c++ classes to C# I would suggest you use c++\cli. Also you have wstring defined in your stuct which are definitely not POD. When you use DLLImport think C constructs only or you are going to have a bad time.

How to natively call this function from a DLL?

I have used DLL Export viewer to try and find the functions that are in this DLL, I have found a list of functions and here it is:
public: int __thiscall CSTVdsDisk::GetPartitionCount(void);
the question is within in C# I am not able to call the function using either:
[DllImport("Some.dll",
ExactSpelling = true,
EntryPoint = "GetPartitionCount",
CallingConvention = CallingConvention.StdCall,
SetLastError = true)]
or:
[DllImport("Some.dll",
ExactSpelling = true,
EntryPoint = "CSTVdsDisk::GetPartitionCount",
CallingConvention = CallingConvention.StdCall,
SetLastError = true)]
private static extern int GetPartitionSize();
They all fail. Is there something that I am doing wrong? Can anyone help? Thanks!

You can't call that function using P/Invoke. The __thiscall calling reference means that this function is a class member function. It is a member function of the CSTVdsDisk class.
To be able to call the function you will have to create an instance of the CSTVdsDisk class and call GetPartitionCount from that instance.
You'll have to do that in C++ or C++/CLR as you can't create a C++ class in C#. See also Create unmanaged c++ object in c#.

Based on the name, that appears to be a C++ class method. That is going to make it very difficult to call that method directly from P/Invoke for two reasons:
You need to find the "real" name; the Export Viewer is apparently showing up the unmangled name, but the actual C++ function name will look much uglier, like #0GetPartitionCount#CSTVdsDisk##QPBAEXA or similar. You may need to use a lower-level tool like dumpbin to find that name.
You need to fake the "thiscall" style call; this means you need to pass an instance of a C++ class as the first parameter. This is only going to work if the C++ class constructor is also exposed from the DLL; in which case, you can call the class constructor, store the result in an IntPtr, and pass it to every subsequent call. (If the constructor is exposed as a DLL export its mangled name will start with ??, like `??0CSTVdsDisk##QAE#ABV0##Z
This CodeProject article shows you how to do most of that, but it's pretty fragile, so expect problems. I'd strongly suggest you look for a non-C++ library that does something similar, or at least one that's designed to be usable from C code.

In your native code, make sure you're exporting the function. By default you function wont be listed in the Exports table so you need to mark it so that the compiler knows to export it. You also need to mark the function as
extern "C"
so that the compiler doesn't mangle the name.
Typically I define the following macro:
#define DLLEXPORT extern "C" __declspec(dllexport)
to handle all of this, and then simply declare exported functions like:
DLLEXPORT __cdecl int Example(int x, int y)
If you find you're still having troubles with the name, try using a free PE explorer program on the dll and checking the exported function table for the correct name.

Problems with wrapping a C++ DLL from C#

I'm using System.Runtime.InteropServices to call several functions written in C++ from my C# app. I'm just having problems with a particular function that returns an array.
I've seen that my function shouldn't return anything, and a pointer to the "returning variable" should be en entry. But I'm not managing to do it properly.
For instance if I have a function in c++
void func(double *y, double *x){...}
that manipulates an array x and returns an array y.
I'm doing:
-in my .h:
extern "C" __declspec(dllexport) void func(double *y,double *x);
-in my .cpp:
__declspec(dllexport) void func(double *y,double *x){...}
-in my c# code:
static class AnyClass
{
[DllImport(dllPath)]
public extern static void func(out double[] y, double[] x);
int otherfunc
{
double[] x = new double[5];
double[] y = new double[5];
...
func(out y, x);
}
}
but it gives me a System.EntryPointNotFoundException.
Any clue?

EntryPointNotFoundException means that nothing called 'function' was found in your DLL.
In your .h file you call it 'func'. But in your .cpp file you call it 'function'. And since your .h file is the only place which is declaring extern "C", what is effectively happening is that the function is being exported by your DLL c++-style-name-mangled, instead of plain-c-style. So, when C# looks for plain-c-style 'function', it cannot find it.

I think, you also have to specify extern "C" in your .cpp file. If not, you might end up with two different functions func, the one with the correct linkage only be declared and not defined.
Note: Afair the extern "C" linkage also specify how the functions are named in the DLL file. For C++ functions some pre- resp. postfixes are added to the name relating to the signature (i.e. the parameters and the return type). This is necessary because you can overload functions in C++. Therefore, if you don't specify extern "C", the functions are named differently in the DLL and thus cannot be found by the managed code.

An EntryPointNotFoundException means that the runtime failed to find the specified function name in your DLL.
Possible reasons are
You misspelled the function name in your DLL or your program
The you did not deactivate name mangling (extern "C")
The first reason is easy to find, just double-check all names and make sure they are really equal. If for some reason you can not change the DLL, but like a different name from C#, you can use the DllImportAttribute.EntryPoint property to point to a function of a different name.
The second one is more difficult to come by. To diagnose the problem, I suggest you use Dependency Walker to see what really is going on inside your compiled DLL. Using that tool, you can see the function names, and whether they are C++'ified or not.
You already tried to use extern "C" to make sure the function name is not afflicted by name mangling. Maybe you did not include the .h file from your .cpp file, so that the compiler did not see the extern "C" at all.

C# - Calling unmanaged C++ function passing LPVARIANT

I want to call the following function from my managed code:
short LS_LoadConfig(LS_ID SensorID,LPVARIANT varConfigPathFile,BOOL bInit)
Here is how I declare the extern function in my C# class:
[DllImport("LineSensor.dll", EntryPoint = "#16")]
private static extern Int16 LS_LoadConfig(
Int16 deviceId,
IntPtr variantFilePath,
int init);
And here is how I create the VARIANT instance and I obtain a pointer to it. Then I call the C# function:
string filepath = #"C:\Windows\ ...";
IntPtr variantFilePath = Marshal.AllocCoTaskMem(200);
Marshal.GetNativeVariantForObject(filepath, variantFilePath);
LS_LoadConfig(device.Id, variantFilePath, initLineSensor);
The problem is that I keep receiving error messages such as "calling the LS_LoadConfig function has unbalanced the stack, check that parameters match the unmanaged signature".
It seems that the problem is caused by the second argument "variantFilePath", like it is not properly marshaled and its size on the unmanaged heap doesn't correspond to the one of an address (32-bit in my case). I tried to change the type in the C# function signature from IntPtr to int as follows:
[DllImport("LineSensor.dll", EntryPoint = "#16")]
private static extern Int16 LS_LoadConfig(
Int16 deviceId,
int variantFilePath,
int init);
I tried to call the function passing a random number and it got slightly better, I have just received an error "memory access violation". Obviously because the random number wasn't a valid address.
Does anybody knows the solution to this problem?
Thank you for any helpful information.

The access violation you created is not better. It also prevents the MDA warning from being generated. Short from the argument types being wrong, the int16 looks pretty weird, the most likely trouble is caused by the CallingConvention. Try StdCall.
And declare the 2nd argument as "object", its default marshaling is to a VARIANT. Declare it with the "ref" keyword to get an LPVARIANT.

"calling the LS_LoadConfig function has unbalanced the stack, check that parameters match the unmanaged signature".
This usually means that you're using conflicting calling conventions between your native and managed code. C# by default uses stdcall, and c/c++ uses cdecl. Try specifying CallingConvention = CallingConvention.Cdecl.

Delphi method signature conversion to c#

I have this signature in a delphi 2007 function I'm calling (the SomeOtherFile is another DLL that it in turn is calling):
function MyFunction(Place, Name: PChar):_Recordset; stdcall; far; external 'SomeOtherFile.DLL';
I'm trying to call it from C# code like this:
[DllImport("MyFile.dll", CallingConvention = CallingConvention.StdCall,
CharSet = CharSet.Ansi, EntryPoint="MyFunction")]
public static extern DataSet MyFunction(string Place, [MarshalAs(UnmanagedType.LPStr)]string Name);
Whenever I run this and store it into a variable, I get a runtime error about type mismatches. I guess I'm reading the signature wrong, but I can't figure out what it should be.
edit
The actual error is: A call to PInvoke function [...] has unbalanced the stack...I've also tried both params using the MarshalAs attribute, and it throws the same thing.

I've done a bit of digging around and I think you need to marshal the return value as a Recordset interface. I'm sure the P/Invoke marshaller won't magically convert your Delphi _Recordset into a .net DataSet class instance.
So I think you can write it something like this:
[DllImport("MyFile.dll")]
[return: MarshalAs(UnmanagedType.Interface)]
public static extern object MyFunction(string Place, string Name);
Call it like this
Recordset rs = (Recordset) MyFunction(Place, Name);
I'm assuming that the Place and Name parameters are input parameters, in which case the default marshalling for string is just fine.
You don't need to specify ANSI character set because that is the default too. You don't need to name the entry point if it has the same name as the C# function. You don't need to specify the calling convention because stdcall is the default.
The Recordset interface resides in the ADODB namespace.
As an aside, the use of far in your Delphi function import is spurious. The far keyword stopped having any effect once we left the 16 bit world behind.