I need to expose some existing .NET logic (i.e. assembly MyManaged.dll) to native code, so I've decided to create C++/CLI bridge. I've created C++/CLI project and added an reference to MyManaged.dll. Long story in short - it works - I've succeeded to access everything that should be accessible form native code.
But big issue is that my implementation leaks memory. After days of testing and researching I've narrowed problem down to System::String <-> const wchar_t conversion. Finally I've created a trivial C++/CLI project that demonstrates (reproduces) the issue:
#define EXPORTED __declspec(dllexport)
System::String^ ToManaged(const wchar_t* unmanagedString)
{
return gcnew System::String(unmanagedString);
}
const wchar_t* ToUnmanaged(System::String^ managedString)
{
return (wchar_t*) System::Runtime::InteropServices::Marshal::StringToHGlobalUni(managedString).ToPointer();
}
EXPORTED const wchar_t* __stdcall GetString(const wchar_t* dummy)
{
return ToUnmanaged(ToManaged(dummy));
}
(If it isn't obvious from the previous code - I'm pretty new in C++/CLI)
As I've mentioned the code works but accumulates memory consumption so there's definitely a leak in System::String <-> const wchar_t conversion.
My question is obvious: how to implement string conversion without the leak.
Thanks!
UPDATE: Please ignore negative voter - as you can see he even refused to explain what is wrong here. Different people have different motives... One thing is for sure: solution provided here works perfectly, without any memory leak.
I've found the solution (based on Overview of Marshaling in C++ and marshal_context::marshal_as). So the following should be changed:
#include <msclr\marshal.h>
System::String^ ToManaged(const wchar_t* unmanagedString)
{
return msclr::interop::marshal_as<System::String^>(unmanagedString);
}
gcroot<msclr::interop::marshal_context^> context;
const wchar_t* ToUnmanaged(System::String^ managedString)
{
msclr::interop::marshal_context^ unpacked = context;
if (unpacked != nullptr)
delete unpacked;
context = gcnew msclr::interop::marshal_context();
return context->marshal_as<const wchar_t*>(managedString);
}
NOTE: Here I've implemented very clumsy handling of marshal_context instance - when the next call arrives, the result from the previous call is deleted. This implementation would fall apart in multi-threading scenario, so you should implement a better one having the following in mind:
marshal_context instance can be used for multiple calls, but it should be deleted every now and then (to free the memory from previously marshaled strings);
As soon as marshal_context is deleted - all const wchar_t* crated by using it are also deleted. It means that you should not delete context immediately after using it, but you need to provide enough time for calling code to actually get the resulting string.
You need to free the pointer from StringToHGlobalUni after you've used it. Use Marshal.FreeHGlobal or LocalFree.
While not built to your exact api, I think this addresses the memory
HRESULT GetString(BSTR* p_bstrResult, unsigned long* ulErrCode)
{
HRESULT hr = S_OK;
try
{
System::String ^systemstring = gcnew System::String("");
DotNetObject::o = gcnew DotNetObject:: DotNetObjectComponent();
*ulErrCode = (unsigned long)o->GetString(systemstring);
pin_ptr<const wchar_t> wch = PtrToStringChars(systemstring);
_bstr_t bstrt(wch);
*p_bstrResult = bstrt.GetBSTR(); // native client babysits
delete systemstring;
}
catch(Exception ^ ex)
{
}
return hr;
}
Related
i am currently trying to port some piece of code from C# to go where dll's are involved (not sure if this makes any difference).
the actual "code" is not the problem but i run into some "feature" problems
i have the following line:
Marshal.AllocHGlobal(Marshal.SizeOf(typeof(WINMSG)));
i know that i can transform
Marshal.SizeOf => unsafe.Sizeof also typeof is not a problem
but how can i implement the AllocHGlobal?
or is this not even needed - just create the instance of a struct and assign a pointer to it?
why do i need this:
there is need for communicating directly with dll's and i have to communicate/exchange data with them.
fully working code is available which needs to be turned into go
Done - but untested yet:
Marshal.AllocHGlobal
Marshal.FreeHGlobal
implementation of the stuff already done
import (
...
"github.com/kbinani/win"
...
)
type IntPtr int16
type UIntPtr uint64
const uint64 HIWORDMASK = 0xffffffffffff0000
// AllocHGlobal like Marshal.AllocHGlobal from c#
func MarshalAllocHGlobal(numBytes int) (tw.IntPtr, error) {
pNewMem := win.LocalAlloc( /*LMEM_FIXED*/ 0x0000, numBytes)
if pNewMem == 0 /*IntPtr.Zero*/ {
return nil, fmt.Errorf("OutOfMemoryException")
}
return pNewMem
}
func MarshalFreeHGlobal(hglobal IntPtr) error {
if IsNotWin32Atom(hglobal) {
if 0 /*IntPtr.Zero*/ != win.LocalFree(hglobal) {
return fmt.Errorf("failed to FreeHGlobal")
}
}
return nil
}
func IsNotWin32Atom(IntPtr ptr) bool {
return 0 != uint64(ptr)&HIWORDMASK
}
i also need
Marshal.StructureToPtr
#see https://referencesource.microsoft.com/#mscorlib/system/runtime/interopservices/marshal.cs,48a38ffe8a227f92
Marshal.PtrToStructure
#see https://referencesource.microsoft.com/#mscorlib/system/runtime/interopservices/marshal.cs,931fc84766e0e8cb
Updated information.
If you just want to call a Win32 api function, you don't need to .NET specific wrapper for memory management.
There is a pattern to call windows dll functions.
You can see example in windows specific code from the standard library, or at some libs that interact with windows API :
in https://github.com/gofrs/flock, for example, they grouped that code in the flock_winapi.go file
This post makes a decent job at explaining how to write code to call a specific function :
Breaking all the rules: Using Go to call Windows API
Have a good day!
For portability reasons, i have created a C++ DLL with almost novice C++ knowledge just by searching thousands of pages, hundreds of compiling error corrections and couple of stackoverflow questions.
It is far beyond being stable but it is working most of the time :)
Just for curiosity and modularity reasons without importing the header and the cpp file to my application, i would like to ask your advice and help:
C++ Win32 Console Application
int main()
{
HMODULE lib = LoadLibrary(L"Serial.dll");
typedef void(*void_Connect)(UINT Port, UINT Baud);
void_Connect Connect = (void_Connect)GetProcAddress(lib, "Connect");
Connect(1, 9600);
}
I want to add an event into above C++ Win32 Console application, which will be triggered or hosted by the DLL
For example, a Received_Event(const char* data) or Connected_Event(BOOL status) with parameters.
Part from the DLL
typedef void(*fpCALLBACK) (const char* aParam);
static fpCALLBACK s_pCallback = NULL;
extern "C"
{
#define DLL __declspec(dllexport)
DLL void ReceivedEventRegister(fpCALLBACK p_pCallback)
{
s_pCallback = p_pCallback;
}
DLL void evntReceived(const char *receivedData);
}
DLL void evntReceived(const char *received)
{
s_pCallback(received);
}
I want to achive something similar to this C# version, with Standard C++
private static ManagedCallbackDelegate MessageCallbackDelegate;
public delegate void ManagedCallbackDelegate(string aParam);
[DllImport("Serial.dll", EntryPoint = "ReceivedEventRegister", CallingConvention = CallingConvention.Cdecl)]
private static extern void ReceivedEventRegister(ManagedCallbackDelegate callback);
static private void serialRecieved(string data)
{
Console.WriteLine(data);
}
static void Main(string[] args)
{
MessageCallbackDelegate = new ManagedCallbackDelegate(serialRecieved);
ReceivedEventRegister(MessageCallbackDelegate);
}
With C# code above, any data received by the DLL, the serialRecieved function is called in realtime. I want to achive this with Standard C++
I want to be informed or be aware of with the DLL process in realtime, in my Win32 C++ Console Application. ( Without blocking the Win32 Console application )
No MFC. if it is possible, no Component Object Model (It is possible with C# without need to convert the DLL into a COM). if it is possible, I want to do it with Standard C++.
I am compiling things with Visual Studio 2017 Community
Please go easy with me. It is a hobby for me and i just do it in my spare time.
Questions
Can you reference me some code examples written for this purpose, you are aware of?
Is there any specific name for this kind of communication that i can Google?
Is there any approach, you can suggest?
Thank you!
Once again, thanks to #dxiv's comment; helped me a lot, to sort things out! Even, when someone tells you that it should work, you resolve 90% of the problem.
At the DLL side
DLL void evntReceived(const char *received)
{
s_pCallback(received);
}
The DLL is calling the above function all the time as soon as it receives any data. To get that data realtime in your Win32 C++ Application, you need to import the DLL function which is calling the above callback function. Which is this
DLL void ReceivedEventRegister(fpCALLBACK p_pCallback)
part of the DLL.
As the DLL function's parameter type name fpCALLBACK suggests, our function parameter has to be as it is defind in the DLL:
typedef void(*fpCALLBACK) (const char* aParam);
At the Application side
//Callback Function: A function that is passed to another function as an argument
void Event_Received(const char *recvd)
{
std::cout << recvd << std::endl;
}
int main()
{
HMODULE lib = LoadLibrary(L"Serial.dll");
typedef void(*void_Connect)(UINT Port, UINT Baud);
void_Connect Connect = (void_Connect)GetProcAddress(lib, "Connect");
// Type definition of the function pointer.
// In our case: a Void type, which takes in a
// void type function pointer with a parameter (const char *aParam)
// dllCALLBACK is just a type name; you can name it whatever you want.
typedef void(*dllCALLBACK) (void(*fpCALLBACK) (const char* aParam));
// Now we will import the function from our DLL which takes
// the same parameters as we defined above, to call
// our callback function
dllCALLBACK ReceivedEventRegister = (dllCALLBACK)GetProcAddress(lib, "ReceivedEventRegister");
// Call the callback function with the imported function above.
// And that is all there is to it. As soon as any data received
// by our DLL - our Event_Received callback function
// fires in our C++ Win32 Console Application
ReceivedEventRegister(Event_Received);
Connect(1, 9600);
}
If you are a novice like me this video may help you to understand about Callback functions.
Thank you #dxiv again, taking time to read and answer my question!
I'm calling C++ COM interface from C# code using a dll.
At the C++ side, i have a WCHAR* global variable which is updated through a method with a BSTR parameter.
The problem is that, when i first call the C++ wrapper method from C# to change the variable, everything works fine, but at the moment that i call another C++ wrapper method from C#, unexplainably the WCHAR* global variable points to a different memory position and its value gets corrupted.
Some code:
//THE C# side:
capture.filename = PATH + "\\" + DIRECTORY_NAME + "\\";
capture.MaxMinutesPerFile = MAX_MINUTE_PER_FILE;
"capture" is an object of the C++ wrapper class (i think it is autogenerated when building the C++ code to a DLL. Not my code).
"filename" property calls a "put_FileName" C++ method and "MaxMinutesPerFile" a "put_MaxMinutesPerFile" method.
//C++ code
WCHAR *m_bstFileName = L"None";
(...)
STDMETHODIMP CCaptureMF::put_FileName(BSTR PathName)
{
EnterCriticalSection(&m_critsec);
HRESULT hr = S_OK;
m_bstFileName = PathName;
LeaveCriticalSection(&m_critsec);
return hr;
}
STDMETHODIMP CCaptureMF::put_MaxMinutesPerFile(LONG Minutes)
{
MaxMinutes= Minutes;
return S_OK;
}
So, after calling "put_FileName", "m_bstFileName" is updated correctly with the "PathName" value, but just after calling "MaxMinutesPerFile" (or any other interface wrapper method), "m_bstFileName" gets corrupted pointing to a different memory position and fulfilled with strange data.
Thank you.
EDIT:
To make a buffer of "m_bstFileName" and then copy the "PathName" data, i used the following code, taking in mind that "m_bstFileName" size can change at runtime:
m_bstFileName = (wchar_t*)malloc(sizeof(PathName));
wcscpy(m_bstFileName, PathName);
That code works fine, but the rest of the program behaves bad. I´m not sure why, i should investigate more, but for now, could you analyze that pice of code and tell me if it is correct or if i should implement it in other way?
SOLUTION:
Ok, following your recomendations i have finally implemented the following code, which works perfect for the whole application:
CComBSTR m_bstFileName = L"None";
(...)
STDMETHODIMP CCaptureMF::put_FileName(BSTR PathName)
{
EnterCriticalSection(&m_critsec);
HRESULT hr = S_OK;
m_bstFileName = PathName;
if (g_pCapture)
{
g_pCapture->SetPath(m_bstFileName);
}
LeaveCriticalSection(&m_critsec);
return hr;
}
If you think that this can be implemented better, just tell.
Thank you for your help!
In the most basic case you'll need to make a buffer to do a string copy into. Same operation could be accomplished via assignment with cstring, ccombstr, std::string, etc. depending on the framework you're using.
You need to copy the string to m_bstFileName, not just assign it. Use something like
strcpy(m_bstFileName, PathName);
I am using C DLL in C# code (.net 4.0) in a console application and facing issue.
When I call the C method it raises the below exception.
"A call to PInvoke function 'ProcessFilesC' 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."
Here is the C code
int ProcessFilesC(
char **p_FilesOrDirs,
ImageInfoC **p_vecImageInfo,
int ***p_vecStackIndexes,
RectC ***p_vecFaces
);
Here is my C# code
[DllImport(#"..\ref\myCApp.dll", CallingConvention = CallingConvention.StdCall)]
unsafe private static extern UInt16 ProcessFilesC(
String[] p_FilesOrDirs,
ref ImageInfoC[] p_vecImageInfo,
out Int32[] p_vecStackIndexes,
out RectC[] p_vecFaces
);
public unsafe struct ImageInfoC
{
public String resizedFilePath; //char* (in C)
public Byte isUsable; //unsigned char (in C)
public UInt32 imageId; //long int in (in C)
public UInt16 stackIndex; //int (in C)
public Boolean isBestPhoto; //unsigned char (in C)
}
Below is C# code to call the method
unsafe
{
iResult = ProcessFilesC(
p_FilesOrDirs, // Value getting passed to DLL
ref p_vecImageInfo,
out p_vecStackIndexes,
out p_vecFaces
);
Console.WriteLine("ProcessFilesC Complete");
}
When code reaches here, I can see that method is processing as it prints in console but after processing, it raises the mentioned exception.
I guess this is due to C DLL is trying to write values in output/ref parameters.
I am not getting where is the issue or what's the wrong in my code.
Please note that I have already uncheck option "Suppress JIT optimization on module load" at Tools -> Options -> Debugging -> General
Please help as soon as poosible.
Thanks for spending to valuable time to read this post.
Thanks,
Kiran
The first thing to check is the calling convention. In most cases the calling convention specified in your DllImport attribute differs from the actual calling convention in the native DLL.
I have an ActiveX control written in C# and working when run in an ActiveX compatible program (CoDeSys). The problem I've come across is that in order to allow CoDeSys to interact with the ActiveX control, CoDeSys requires the dll to export the function prototype:
void ExecuteActiveXCall(IUnknown* pUnk, char* pszId, char* pszParam, char* pszReturnBuffer, int nReturnBufferSize, DWORD* pdwReturnFlag);
I've looked without success on how to export this like you can in C++, as shown in this example:
extern "C" __declspec (dllexport) void ExecuteActiveXCall(IUnknown* pUnk, char* pszId, char* pszParam, char* pszReturnBuffer, int nReturnBufferSize, DWORD* pdwReturnFlag)
{
if (strcmp(pszId, "IWebBrowser|GoBack") == 0)
{
IUnknown* pNewUnk;
IWebBrowser* pwb;
pUnk->QueryInterface(IID_IWebBrowser, (void**) &pNewUnk);
pwb = (IWebBrowser*) pNewUnk;
if (pwb)
{
pwb->GoBack();
pwb->Release();
}
}
else if (strcmp(pszId, "IWebBrowser|GoForward") == 0)
{
IUnknown* pNewUnk;
IWebBrowser* pwb;
pUnk->QueryInterface(IID_IWebBrowser, (void**) &pNewUnk);
pwb = (IWebBrowser*) pNewUnk;
if (pwb)
{
pwb->GoForward();
pwb->Release();
}
}
}
C# does have an extern keyword, but it doesn't allow you to provide the function definition (at least I haven't found a way). After attempting this:
extern unsafe void ExecuteActiveXCall(
[MarshalAs(UnmanagedType.IUnknown)] object pUnk,
char* pszId,
char* pszParam,
char* pszReturnBuffer,
int nReturnBufferSize,
UInt32* pdwReturnFlag)
{
}
The following error occurs:
'AlarmsCSharp.AlarmsControl.ExecuteActiveXCall(object, char*, char*, char*, int, uint*)' cannot be extern and declare a body
Has anyone attempted exporting a function in a C# dll?
Are there any workarounds? (I had the thought of [DllImport("AlarmsCSharp.dll")] and calling C# in the C++ dll, but figured I'd see if anyone had a solution before)
Perhaps I'm over thinking this and don't need to export this function since the ActiveX control is able to interact already with the C# code.
EDIT: I have a feeling my translation from the C++ function prototype to the C# interface declaration. If someone with more experience with C++/C# programming could verify that I did that translation correct or incorrect, it may be of some help.
You say that CoDeSys is ActiveX-compatible; have you tried using COM interop?
There seems to be 3 main options; the first is to set up COM interop where you can instantiate your C# control / class using COM. I'm sure if you do some searching you can find some more info on that.
The second option is to make your c++ module mixed managed/unmanaged, as described here:
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/5345a27a-a614-4a74-9f6d-ea7a999ddf83/
The third option is to use "reverse PInvoke" as described here: http://tigerang.blogspot.com/2008/09/reverse-pinvoke.html
There may be other options; those are the ones I know of.