Passing a C# string to C++/CLI does not show up from a CPP program

SujayG

Hi There , I want to call a C# function from C++ , via CLI/C++. C# code

private string _text = "";

public void setText(string text)
{
// _text = text;
_text = "HI World";
Console.WriteLine("C# settext - {0}", _text);
}

public string getText()
{
return _text;
}

C++/CLI code Header :

//virtual void setText(System::String^ text);
//virtual System::String^ getText();

virtual void setText(std::string text);
virtual std::string getText();

CPP file

std::string CStringBridge::getText()
{
_managedObject = gcnew Bridge();
return (marshal_asstd::string(_managedObject->getText()));
}

void CStringBridge::setText(std::string text)
{
_managedObject = gcnew Bridge();
_managedObject->setText(gcnew System::String(text.c_str()));
}

Note : When I use the following code

virtual void setText(System::String^ text);
virtual System::String^ getText();

I get the following error 3395

__declspec(dllexport) cannot be applied to a function with the __clrcall calling convention

, and so I stuck to std::string When I use the library from the C++/CLI code, and call from my C++ program, "Hi World" should be printed ; instead nothing gets printed C++ console application

IStringBridgeWrapper *pBridge = IStringBridgeWrapper::CreateInstance();
pBridge->setText(std::string("I am here"));

try{

pBridge->getText();

}
catch(exception& e)
{
cout << e.what() << endl;
}

I think the string is not being properly passed . Any ideas to solve it shall be appreicated.

My Blog

David Knechtges

This is how I convert a managed (c#) string to an unmanaged string (C++):

using namespace msclr::interop;
void GetUnmanagedString(String ^ managedString, char **unmanagedString)
{
marshal_context ^ context = gcnew marshal_context();
strcpy(*unmanagedString, context->marshal_as(managedString));
delete context;
}

Note that the unmanaged string memory has already been allocated before I call this function.

SujayG

That's just the conversion part . I don't think that's the reason for the string not getting displayed.

My Blog

Lost User

sujayg wrote:

I get the following error 3395

__declspec(dllexport) cannot be applied to a function with the __clrcall calling convention

Why are you trying to use dllexport in a CLI program? Make everything CLI and it should work together.

Use the best guess

SujayG

Hi , I was following the example at Using managed code in an unmanaged application[^] It seeemed strange that the function signature with String^ throws the error, but std::string does not.

My Blog

Lost User

That has nothing to do with it; as the message says, you cannot use dllexport on a CLI method. You are trying to mix managed and unmanaged code, which does not work well.

Use the best guess

SujayG

What if I dont use String^ and use std::string as the preferred parameter .

My Blog

Lost User

You'll get in even more difficulty. You need to spend some time learning the difference between managed and unmanaged code in C++. I am not sure what you are trying to achieve here, but suffice it to say that what you are attempting is not straightforward. C++ was never designed to work in .NET and unless you have a compelling reason to mix the two languages you should not bother. Stick to either unmanaged C++ or C#, and make life easier for yourself.

Use the best guess

SujayG

I want to call a C# function from C++ ; and I am using C++?CLI as the bridge . I had developed a CLI wrapper - for calling C++ function from C# ,but this was my attempt to do the reverse.

My Blog

Lost User

See this white paper[^].

Use the best guess

SujayG

Thanks for the link. I have created the manged DLL , without errors. I want to call this DLL from native C++ applicaton . Please help me with a step by step process how can I do it .

My Blog

Lost User

sujayg wrote:

Please help me with a step by step process how can I do it .

Sorry, I don't have one, you will have to figure it out from the documentation and articles on the subject. I still do not understand what you are trying to achieve here, calling managed code from unmanaged is not such a simple matter.

Use the best guess

jschell

It isn't clear if there is a real business problem here but mixed mode programming can often be tricky. So it is easier to just not do it. Instead 1. Create a executable of the targeted functionality. 2. Provide an management API for that: sockets, files or std io. 3. Use the client application to manage a "process" to run the above executable. 4. The client application uses the management api to produce the desired functionality. The advantage to this is that both pieces, with care, can be tested independently and debugged independently as well. And the target functionality cannot take done the client application should it fail in a catastrophic way.