using managed class in VC++ .Net
-
As VC++.Net (2002) is unmanaged by default moeover all MFC classes (CDocumnet, CDialog etc) are unmanaged, how can I use a managed class (created in C#) within VC++. What i am trying to do is: 1. Create a control in C# 2. Add this control in a CDialog derived Dialog in VC++. Now, as CDialog derived class is unmanaged, I am not able to create a pointer to my managed control class. Using gcroot template class does help me over come this problme, but when i try allocating memeory by new opertaor, i get compiler error. Do let me know how can i overcome this problem
-
As VC++.Net (2002) is unmanaged by default moeover all MFC classes (CDocumnet, CDialog etc) are unmanaged, how can I use a managed class (created in C#) within VC++. What i am trying to do is: 1. Create a control in C# 2. Add this control in a CDialog derived Dialog in VC++. Now, as CDialog derived class is unmanaged, I am not able to create a pointer to my managed control class. Using gcroot template class does help me over come this problme, but when i try allocating memeory by new opertaor, i get compiler error. Do let me know how can i overcome this problem
There is an article under the name 'Using ADO .Net from MFC Project' that discusses this very same phenomenon. In it, the writer uses the .Net Library from an unmanaged MFC class. Although the sample uses ADO.Net, it is completely valid for all other .Net Library components as well. Even your C# control is a piece of .Net Library. The original article can be found here[^]. To implement your own control, you must compile the C# code so that it generates a DLL file. Then use the #using directive to import this DLL into your unmanaged project. You must also import the .Net Core Library (mscorlib.dll), otherwise strange behaviour might result. When done, follow the example in the above-mentioned article starting from "__gc pointers in an Unmanaged Class" onwards for an example on how to use your control. If you need help on creating a C# DLL, follow the guidelines in this[^] article. Then copy the finished DLL into the unmanaged project's search path and continue with the first article's instructions. Hope this helps you out -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.
-
There is an article under the name 'Using ADO .Net from MFC Project' that discusses this very same phenomenon. In it, the writer uses the .Net Library from an unmanaged MFC class. Although the sample uses ADO.Net, it is completely valid for all other .Net Library components as well. Even your C# control is a piece of .Net Library. The original article can be found here[^]. To implement your own control, you must compile the C# code so that it generates a DLL file. Then use the #using directive to import this DLL into your unmanaged project. You must also import the .Net Core Library (mscorlib.dll), otherwise strange behaviour might result. When done, follow the example in the above-mentioned article starting from "__gc pointers in an Unmanaged Class" onwards for an example on how to use your control. If you need help on creating a C# DLL, follow the guidelines in this[^] article. Then copy the finished DLL into the unmanaged project's search path and continue with the first article's instructions. Hope this helps you out -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.
Dear Antii, Thanks for the valueable information, but after i modified my code as described in the article, i come across an exception An unhandled exception of type 'System.IO.FileNotFoundException' occurred in MFCButtonForm.exe Additional information: File or assembly name MyControl, or one of its dependencies, was not found. This exception occurs only when I allocate memeroy to the control pointer as
gcroot<CColoredButton*> colorButton;
#pragma push_macro("new")
#undef new
colorButton = new CColoredButton();
#pragma pop_macro("new")Please do let me know haw can this exception be resolved. Regards Mohit Jain
-
Dear Antii, Thanks for the valueable information, but after i modified my code as described in the article, i come across an exception An unhandled exception of type 'System.IO.FileNotFoundException' occurred in MFCButtonForm.exe Additional information: File or assembly name MyControl, or one of its dependencies, was not found. This exception occurs only when I allocate memeroy to the control pointer as
gcroot<CColoredButton*> colorButton;
#pragma push_macro("new")
#undef new
colorButton = new CColoredButton();
#pragma pop_macro("new")Please do let me know haw can this exception be resolved. Regards Mohit Jain
Have you added the compiled C# class library DLL as a
#usingdirective into the project ? The exception is caused by the CLR not being able to find the target assembly, and the exception is not shown unless you try to create the control. Also, remember that after you've changed the project settings, all functions are compiled as managed by default. This means that you must add#pragma unmanagedstatemets to capsulate those classes and functions that are not managed, but should be compiled as native. I'll try to create a test project that uses a control from here in CodeProject and see what comes up. Perhaps I can then help you more, when I've seen the code in action. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible. -
Have you added the compiled C# class library DLL as a
#usingdirective into the project ? The exception is caused by the CLR not being able to find the target assembly, and the exception is not shown unless you try to create the control. Also, remember that after you've changed the project settings, all functions are compiled as managed by default. This means that you must add#pragma unmanagedstatemets to capsulate those classes and functions that are not managed, but should be compiled as native. I'll try to create a test project that uses a control from here in CodeProject and see what comes up. Perhaps I can then help you more, when I've seen the code in action. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.Correction to my earlier post. The reason your application causes an assertion is because it cannot determine where the control resides. In order to solve this, use a fully qualified name of the control. For an idea, consider if
m_NetFormwas a __gc wrapper for typeSystem::Windows::Forms*and would then be instantated as a form object by callingm_NetForm = new System::Windows::Forms();Does this solve the issue ? I tried to create a simple example application. It uses the .Net Framework 1.1 to create a file writer object (StreamWriter) and writes a single line into the file. You can download the sources and a working executable from here[^]. The text file is created into the same directory from which the application is ran. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible. -
Correction to my earlier post. The reason your application causes an assertion is because it cannot determine where the control resides. In order to solve this, use a fully qualified name of the control. For an idea, consider if
m_NetFormwas a __gc wrapper for typeSystem::Windows::Forms*and would then be instantated as a form object by callingm_NetForm = new System::Windows::Forms();Does this solve the issue ? I tried to create a simple example application. It uses the .Net Framework 1.1 to create a file writer object (StreamWriter) and writes a single line into the file. You can download the sources and a working executable from here[^]. The text file is created into the same directory from which the application is ran. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.Thanks for your suggestions and the sample. Besides your suggested approach, I had to copy my Control's dll to the folder from where my MFC app was running in order to resolve the exception. Thanks again. Regards