Using .net 4 library from MFC applications

Question

0.00/5 (No votes)

See more:

Hi every body

How can I use .NET4 library from MFC/C++ applications ? Actually I want use .NET4 library from my MFC project and I need pretty compatibility ... :)

Posted 27-Mar-13 21:17pm

Aydin Homay

Add a Solution

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-03-27T21:39:00

Solution 2

I almost forgot: there is another approach, more realistic in your case.

You can develop your code as a mixed-mode C++/CLI application, managed + unmanaged. In such project, you can reference any .NET assembly and use it as it is usually do with .NET. At the same time, the unmanaged part of the code can implement an MFC application. The language provides wide opportunities for collaboration between managed (CLI) and unmanaged code.

However, I would advice you to strictly segregate your files in three groups: 1) purely unmanaged code; 2) the code with managed "ref" classes; 3) the code with unmanaged wrappers of the CLI code; these wrappers can be used in group #1.

Please see:
http://en.wikipedia.org/wiki/C%2B%2B/CLI[^],
http://www.ecma-international.org/publications/standards/Ecma-372.htm[^],
http://msdn.microsoft.com/en-us/library/xey702bw.aspx[^].

—SA

Posted 27-Mar-13 21:39pm

Sergey Alexandrovich Kryukov

Comments

Aydin Homay 28-Mar-13 4:58am

Very good answer so tnx Sergey Alexandrovich kryukov ;)

Sergey Alexandrovich Kryukov 28-Mar-13 10:10am

You are welcome.
Will you accept if formally then (green button)? — thanks.
—SA

H.Brydon 28-Mar-13 16:17pm

I like your solution #2 better than #1 (+5 accordingly).

Sergey Alexandrovich Kryukov 28-Mar-13 16:23pm

Well yes, if C++ is used anyway, so C++/CLI can be used, it's better. I just failed to think about it at first.
Solution #1 is more interesting (and still perfectly legitimate), just because it breaks the common misconception that export to unmanaged is not allowed for .NET assemblies. Actually, this is allowed by the standard for IL directly, and for C++/CLI, indirectly, but not allowed in most .NET languages.
Thank you.
—SA

Aydin Homay 29-Mar-13 5:36am

Dear guys

Actually when we have legacy project from (MFC or ...) we have more problems with develop and extend that. if we develop new sub system from .NET and integrated with our legacy system we have COM technology problem or if we develop new sub system from MFC again we lost .NET feasibility... :/
Maybe if we develop new sub system from .NET and we use .exe from our legacy system with shell and ... is a better than other solutions !

Sergey Alexandrovich Kryukov 29-Mar-13 10:17am

Maybe, more importantly, the resulting system would be cleaner, and, first of all, much more maintainable.
But in real life.., who knows? Very often people have to upgrade slowly, by small stages, because they need to keep the system in production.

Cheers,
—SA

Aydin Homay 30-Mar-13 4:57am

Hi again

I used your solution #2 follow of these steps:
1- I created CLI windows application with my project name
2- I added my MFC 2010 project source codes(*.h & *.cpp) to the from of new CLI project
3- I changed "Use MFC" option from project properties to the Use "MFC in a shared DLL"
4- Build
But I get some errors same as:
1- error C3641: 'UnlockResource' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe
2- error C3641: 'InterlockedExchangePointer' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe
3- error C3641: 'DrawStatusText' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe
4- error C3641: 'AtlW2AHelper' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe
5- error C3641: 'AtlDevModeW2A' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe
6- error C3641: 'AtlA2WHelper' : invalid calling convention '__stdcall ' for function compiled with /clr:pure or /clr:safe
7- error C2440: 'default argument' : cannot convert from 'int (__cdecl *)(int,const char *,int,const char *,const char *,...)' to 'ATL::CTrace::fnCrtDbgReport_t' C:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\atltrace.h

What`s wrong ? any help would be appreciated.

Sergey Alexandrovich Kryukov 30-Mar-13 21:22pm

You need to show some code sample. Only please don't show your real code; create some sample with could of simplest methods of a class, just to reproduce only one problem. Where did you put this calling convention (you should not). You should not also try to "export" CLI classes. All you need is to make the classes and members you need to use in referencing assembly as public.
—SA

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-03-27T21:23:00

Many would say it's impossible (not counting creation of a COM component).

This is in principle possible, but in practice, just ridiculous. Too difficult to bother, and too easy to port to .NET from majorly obsolete and not-so-easy-to-use MFC.

However, if you really want to bite a bullet, there is one of the method explained in some CodeProject articles with overview and discussion in my past answer:

loading C# DLL in MFC[^],
How can I use a dll created in Visual Basic 2008 in Visual Basic 6.0[^],
Call Managed DLL written in C# from Unmanged Code VC++[^],
API's in .Net: Managed or UnManaged Code[^].

Note that some members considered this approach as highly questionable, but I value it much more than COM which contaminates the system. It works, even though many would say it's impossible.

Again, I don't recommend any. Get rid of MFC and don't torture yourself. Anyway, you decide.

[EDIT]

I almost forgot: in your special case, there is another solution. Maybe it will work for you better. Please see Solution 2.

—SA