In one of the post Titled "Call a c++ method that returns a string, from c#"
Its said that , to make the following Pinvoke to work change the C++ signature to as
extern "C" REGISTRATION_API void calculate(LPSTR msg)
C++ code
extern "C" REGISTRATION_API void calculate(char* msg)
C# code
[DllImport("thecpp.dll", CharSet=CharSet.Ansi)]
static extern void calculate(StringBuilder sMsg);
How can stringBuilder which is a class ,convertd to long ptr to string .(but this is the accepted answer)
Shouldnt we use use IntPtr as below ?
extern "C" REGISTRATION_API void calculate(Intptr msg)
Look for the section marked "Passing Strings", the marshaler has got some added smarts to do this trick.
http://msdn.microsoft.com/en-us/library/aa446536.aspx
To solve this problem (since many of
the Win32 APIs expect string buffers)
in the full .NET Framework, you can,
instead, pass a
System.Text.StringBuilder object; a
pointer will be passed by the
marshaler into the unmanaged function
that can be manipulated. The only
caveat is that the StringBuilder must
be allocated enough space for the
return value, or the text will
overflow, causing an exception to be
thrown by P/Invoke.
Related
I hope somebody can explain what exactly the difference is:
In my C# Programm I want to pass an String to an C++ Method.
My Code in C# looks like this:
[DllImport("Test.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)]
public static extern String DoIt(String filename);
The inside of my C++ DLL looks like this:
__declspec(dllexport) CString DoIt(char* szFilename)
{
....
}
If I pass the String (like: C:\temp\my.txt) it becomes malformed =>"Ôœ&°8é-".
Now comes the confusings part I can't literly understand. If I change the return Type from CString to char* everything is fine.
__declspec( dllexport ) char* DoIt(char* filename)
Why is that so? The CharSet in C# is already set to Ansi to Marshal the String into the right Type. I cannot figure out where the connection between the return Type and my passing String is.
If you need more information just let me know.
Both versions of your code are wrong. You certainly can't pass CString as an interop type. You to use simple types for interop, not C++ classes.
The error when you use char* is more subtle. In that scenario there are two problems.
Firstly, with a string return type on the C# side, the pinvoke marshaller assumes that the returned string was allocated with CoTaskMemAlloc and will call CoTaskMemFree to deallocate it once it has been copied.
Secondly, although we can't see it, your C++ code almost certainly returns a pointer to a buffer owned by a local variable in the C++ function. Obviously this local variable goes out of scope when the function returns and so the pointer becomes invalid.
Some options:
Have the caller locate the string buffer and let the callee populate it.
Allocate the returned char* using CoTaskMemAlloc and so meet the expectations of the C# code.
Use the COM BSTR type which the pinvoke marshaller does understand.
I have included a C++ library in my C# project and i am calling one of it's method.
Earlier I was having the mangling problem then read about extern c and applied it to C++ method.
Then tried calling it like below:
[DllImport(#"F:\bin\APIClient.dll")]
public static extern IntPtr logIn2(IntPtr a, IntPtr b, IntPtr c, IntPtr d, IntPtr e, IntPtr f, int g);
But still I am getting Entry Point exception.
C++:
APICLIENT_API char* logIn2(const char* a, const char* b,const char* c,const char* d,const char* e,const char* f, int g);
And if i use entryPoint in DLLImport then it works fine:
[DllImport(#"F:\bin\APIClient.dll", EntryPoint = "?logIn2#CAPIClient#API##QAEPADPBD00000H#Z", CallingConvention = CallingConvention.StdCall)]
public static extern IntPtr logIn2(IntPtr a, IntPtr b, IntPtr c, IntPtr d, IntPtr e, IntPtr f, int g);
Why even after using extern c I have to give this Entry point to make things working.
The decorated C++ name is not a problem. It is actually very desirable, it automatically saves you from having to diagnose a very difficult runtime crash when the C++ code is changed and the function signature is altered. Since there now will be a mismatch and you get an easy "Procedure not found" error message instead of a corrupted call stack that is quite undiagnosable.
The much bigger problem, and the reason that extern "C" doesn't work, is that this is an instance method of the CAPIClient class. It uses the __thiscall calling convention, required to pass a valid this pointer. You can't get that from pinvoke, it requires allocating memory for the C++ object and calling the CAPIClient constructor. Only a C++ compiler knows how to do that correctly, only it knows the correct amount of memory to allocate. So you can't pinvoke, you have to write a C++/CLI wrapper.
The normal mishap when you pinvoke an instance method of a C++ class is a hard crash, typically reported as an AccessViolationException. Triggered when the instance method tries to access another other instance member of the C++ class through the invalid this pointer. Only a static C++ function can be correctly pinvoked. Since you didn't seem to have triggered an exception (yet), there's some hint that the function should have been static in the first place.
I have the following function header in a native DLL:
unsigned char* Version_String()
I'm trying to call it from a C# project, I've tried the following call (as found on other similar questions here):
[DllImport("BSL430.dll", CharSet=CharSet.Ansi)]
public extern static UIntPtr Version_String();
And I keep getting the following exception:
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
The next try was the following and I get the same exception:
[DllImport("BSL430.dll", CharSet=CharSet.Ansi)]
[return : MarshalAs(UnmanagedType.LPStr)]
public extern static string Version_String();
I can't seem to get around this issue. Any help would be greatly appreciated!
Edit:
I can't give the DLL code here, as it falls under an NDA, but the function I'm calling looks like this:
unsigned char versionString[50];
__declspec(dllexport) unsigned char* Version_String()
{
if(check_hardware_stuff())
{
strcpy((char *) versionString, "version_string_bla_bla");
versionString[5] = stuff;
}
else if (other_check())
{
//will return empty string, that should be filled with '\0'
}
else
{
strcpy( (char *) versionString, "ERROR" );
}
return versionString;
}
I'm not particularly fond of the DLL implementation, but I need to use it "as it is".
I get the exception thrown whenever I try to call VersionString(), regardless of what I do with the return value.
Update
Having seen the updated question, the various comments, and the code of your native function, it seems likely that the exception is raised when you call check_hardware_stuff(). It's simple enough to debug. I would replace your function with one like this:
unsigned char versionString[50];
__declspec(dllexport) unsigned char* Version_String()
{
strcpy(versionString, "testing");
return versionString;
}
If that still fails then my guess is that the error is raised in the DllMain of your DLL. Debug that by putting the above function into a plain vanilla DLL that does nothing else.
Original answer
Calling convention is the most obvious problem. Your native code most likely uses cdecl but the p/invoke default is stdcall. Change your p/invoke signature to be like this:
[DllImport("BSL430.dll", CallingConvention=CallingConvention.Cdecl)]
public extern static IntPtr Version_String();
You can safely omit the CharSet parameter since none of the parameters have text because you are treating the return value as a pointer.
Edit: Hans correctly points out in the comments that since there are no parameters, the calling convention mis-match does not matter. So this isn't the problem.
Call Marshal.PtrToStringAnsi to convert to a .net string.
string version = Marshal.PtrToStringAnsi(Version_String());
Since PtrToStringAnsi is expecting an IntPtr parameter I would recommend that you use IntPtr as the return type of you p/invoke signature.
This all assumes that the memory returned from your native function is allocated and freed in the native DLL. If it is heap allocated and you expect the caller to deallocate it then you have a small problem. How do you deallocate the memory from C# since you don't have access to the native DLL's heap?
The simple solution is to use the shared COM heap to allocate the memory. Call CoTaskMemAlloc to allocate the buffer for the string. Then declare the return value to be of type string and the p/invoke marshaller will deallocate with the COM allocator.
[DllImport("BSL430.dll", CallingConvention=CallingConvention.Cdecl)]
public extern static string Version_String();
...
string version = Version_String();
Of course, this only applies if you are returning heap allocated memory that you expect the caller to deallocate.
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.
I have a C++ function exported as api like this:
#define WIN322_API __declspec(dllexport)
WIN322_API char* Test(LPSTR str);
WIN322_API char* Test(LPSTR str)
{
return "hello";
}
the function is exported as API correctly by the .DEF file, cause i can see it in Dependency Walker tool.
Now i have a C# tester program:
[DllImport("c:\\win322.dll")]
public static extern string Test([MarshalAs(UnmanagedType.LPStr)] String str);
private void Form1_Load(object sender, EventArgs e)
{
string _str = "0221";
Test(_str); // runtime error here!
}
on calling the Test() method i get the error:
"A call to PInvoke function 'MyClient!MyClient.Form1::Test' has unbalanced the stack. This is likely because the managed PInvoke signature does not match the unmanaged target signature. Check that the calling convention and parameters of the PInvoke signature match the target unmanaged signature."
i tried many other data types and marshalings, but got nothing!
plz help me!
It is caused by a mismatch on the calling convention, the default for [DllImport] is Stdcall but the C compiler's default is Cdecl. Use the CallingConvention property in the declaration.
That's not the only problem though, this code will crash on Vista and Win7. Returning a string from a C function is quite troublesome, there's a memory management problem. It isn't clear who is responsible for freeing the string buffer. You are returning a literal now but that's going to stop being useful pretty soon. Next stop is using malloc() for the return string with the intent for the caller to call free(). That's not going to work, the pinvoke marshaller cannot call it since it doesn't know what heap the C code is using.
It will call Marshal.FreeCoTaskMem(). That's wrong, the string wasn't allocated by CoTaskMemAlloc(). That goes unnoticed on XP and earlier, other than the very hard to diagnose memory leak this causes. And goes kaboom on Vista and Win7, they have a much more stricter memory manager.
You need to rewrite the C function like this:
extern "C" __declspec(dllexport)
void __stdcall Test(const char* input, char* output, int outLen);
Now the caller supplies the buffer, through the output argument, there's no longer a guess who owns the memory. You use StringBuilder in the C# declaration.
[DllImport("foo.dll")]
private static extern void Test(string input, StringBuilder output, int outLen);
...
var sb = new StringBuilder(666);
test("bar", sb, sb.Capacity);
string result = sb.ToString();
Be careful to use the outLen argument in your C code so that you can be sure not to overflow the buffer. That corrupts the garbage collected heap, crashing the app with a Fatal Execution Engine Error.
Change your macro definition to
#define WIN322_API __declspec(dllexport) __stdcall
As an alternative, use CallingConvention.Cdecl when importing.
Read, for example, here for more info on calling conventions.
Make sure that you have the correct calling convention. Your DLL may use Cdecl, while C# defaults to StdCall. It's better to always explicitly define the calling convention.
Especially when using Windows functions which exist in an ANSI and wide char version (those with an A or W prefix), explicitly specify the CharSet so the correct version is used.
When the function returns a value, explictly marshal the return value. Otherwise, the compiler chooses a default, which may be wrong. I suspect this is (also) the problem here.
So change to this, for example:
[DllImport("c:\\win322.dll", CharSet = CharSet.Ansi, CallingConvention = CallingConvention.StdCall)]
[return: MarshalAs(UnmanagedType.LPStr)]
public static extern string Test([MarshalAs(UnmanagedType.LPStr)] String str);
Try returning LPSTR, not char*. You might also need to specify stdcall calling convention, which is default in .NET, but I'm not sure about your unmanaged project.
Use Unmanagedtype.LPTStr for the input. Notice the additional T
[MarshalAs(UnmanagedType.LPStr)] String str // your current code
[MarshalAs(UnmanagedType.LPTStr)] String str // try this code
Pass a StringBuilder from .Net as a parameter rather than returning a string (in this case it will be like an out parameter)