Passing a C# string to C++/CLI does not show up from a CPP program
-
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.
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.
-
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.
-
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.
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
dllexportin a CLI program? Make everything CLI and it should work together.Use the best guess
-
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
dllexportin a CLI program? Make everything CLI and it should work together.Use the best guess
-
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.
-
That has nothing to do with it; as the message says, you cannot use
dllexporton a CLI method. You are trying to mix managed and unmanaged code, which does not work well.Use the best guess
-
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
-
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
-
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.
-
See this white paper[^].
Use the best guess
-
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 .
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
-
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.
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.