Return a string from C++ Native to C# 64-bit

  • Thread starter Thread starter jimbrown
  • Start date Start date
J

jimbrown

This works in VS2008 for 32-bit projects but fails for 64-bit
projects. How do I return a result that C# will interpret as a
string?

C#
[DllImport("hello.dll", CharSet = CharSet.Ansi)]
private static extern string getAString();

String xx = getAString();

C++ in "hello.dll"
extern "C" {
__declspec(dllexport) unsigned char * getAString()
{
printf("call made\n");
return (unsigned char *)"a string";
}
}
 
jimbrown said:
This works in VS2008 for 32-bit projects but fails for 64-bit
projects. How do I return a result that C# will interpret as a
string?

C#
[DllImport("hello.dll", CharSet = CharSet.Ansi)]
private static extern string getAString();

String xx = getAString();

C++ in "hello.dll"
extern "C" {
__declspec(dllexport) unsigned char * getAString()
{
printf("call made\n");
return (unsigned char *)"a string";
}
}

What exactly do you mean when you say that it "fails"? What happens, and
how does that differ from what you expect? Do you get any error message?
 
This works in VS2008 for 32-bit projects but fails for 64-bit
projects.  How do I return a result that C# will interpret as a
string?

C#
            [DllImport("hello.dll", CharSet = CharSet.Ansi)]
            private static extern string getAString();

                    String xx = getAString();

C++ in "hello.dll"
   extern "C" {
   __declspec(dllexport) unsigned char * getAString()
   {
        printf("call made\n");
        return (unsigned char *)"a string";
   }
   }

easy one.
32 DLL don't work properly on 64bits development.
You will have problems as long as your DLL is 32bit Using 64bits DLL
solve all my issues.
From what i experienced the applications i'm making seems to call DLL
as 64bits and ask for 64bits answer,
since the return value is 32bits the memory (here i guess) classified
the return as bogus and incomplete

But like i said, building the DLL as 64bits solve my issue.

In your case, i guess you will need to pass a 64bit string

i C# a 64bit string is using string builder with 64bit int limits
like :
StringBuilder sb = new StringBuilder(Int64.MaxValue, Int64.MinValue);
 
Franck said:
In your case, i guess you will need to pass a 64bit string

i C# a 64bit string is using string builder with 64bit int limits
like :
StringBuilder sb = new StringBuilder(Int64.MaxValue, Int64.MinValue);

A 64 bit string? What are you talking about?

The C++ code returns a byte array that contains a string that is encoded
as Ansi (Encoding.Default). This is decoded into a unicode string by the
marshalling code. A string in .NET looks the same regardless if it's on
a 32 bit platform or a 64 bit platform.
 
A 64 bit string? What are you talking about?

The C++ code returns a byte array that contains a string that is encoded
as Ansi (Encoding.Default). This is decoded into a unicode string by the
marshalling code. A string in .NET looks the same regardless if it's on
a 32 bit platform or a 64 bit platform.

The error I get is a complete failure of the debugger "vshost.exe" has
stopped working. I assume it is a problem with the marshalling code.
 
Franck said:
This works in VS2008 for 32-bit projects but fails for 64-bit
projects. How do I return a result that C# will interpret as a
string?

C#
[DllImport("hello.dll", CharSet = CharSet.Ansi)]
private static extern string getAString();

String xx = getAString();

C++ in "hello.dll"
extern "C" {
__declspec(dllexport) unsigned char * getAString()
{
printf("call made\n");
return (unsigned char *)"a string";
}
}

easy one.
32 DLL don't work properly on 64bits development.

This is correct. You need to compile your C++ code with the 64-bit
compiler, no changes needed to the code.
You will have problems as long as your DLL is 32bit Using 64bits DLL
solve all my issues.
From what i experienced the applications i'm making seems to call DLL
as 64bits and ask for 64bits answer,
since the return value is 32bits the memory (here i guess) classified
the return as bogus and incomplete

But like i said, building the DLL as 64bits solve my issue.

But everything after this is totally bogus.
 
Back
Top