|Yoa are better to throw the MFC code to garbage if you really need managed code. You won't be able to use MFC in a fully managed application thus you would have to uses mixed mode. But if you use mixed mode, then you can just have some part managed and some not managed.
If you really want a managed application, the best thing to do would be to start a new application using WinForms or WPF, and then redo all the UI and then port your code.
You have to understand that MFC and .NET are two worlds. While you can host managed controls in a MFC dialog (or an ActiveX control in a .NET application), you won't be able to cretae a fully managed application.
In a word, without using mixed mode (that is keep MFC not managed and eventually uses some managed .NET controls), the effort to port the code to be managed will probably be higher than completly rewrote the application. It simply does not make any sense. Show to your client our answers and tell him you would have to rewrote the application. If the application is large, it can take months or even years to do so.
If you try anyway, you will probably loose months trying to make things works and still have a lot of problems.
By the way, if you use MFC DLL, then you application have to be compiled with options that are compatioble with MFC. If you use .NET, then your application need to be compiled with options that are compatible with .NET.
If you try to uses both, you will have a lot of incompatible options and you will have to select proper options on a file by file basis. You will probably also need to have 2 set of precompiled header. One for unmanaged stuff and one for managed stuff.
I have done so code where I want to have some managed code and some unmanaged code, and I have to uses some custom options. I have a lot of warning for header files that are sometime included as managed and sometime as unmanaged as some definitions are differents. The more you application is complex, the more it will be hard to fully understand all the implications and the more, you will have hard to debug problem caused by things like incompatible macros definitions, incompatible alignments that will cause your application to crash at run-time. You will have to fully understand the implication of any compiler and linker options. In my case, it was something relatively simple so I was able to manage incompatibilities. By the way, I think I also need some tricks to get DLLs proberly loaded in my case.
If your client want managed code because the code run in a secure environment like SQL, then I think the only option is to rewrote the application.
In the end, you either have to tell your client it is not possible or that you have to rewrote your application. And rewroting the application, even if it is easier in .NET might take probably at least half the time it take to make the original application depending on how the application was done.
If you uses some advanced C++ stuff like template, boost, STL and you want a fully managed application (not mixed mode) it can even be harder to port the application. You can always uses STL/CLR to replace STL but even there you have a lot of changes to do.
In a fully managed application, you won't be able to uses pointers... And if you use mixed mode, then why not have some DLL managed (mixed mode) and some not managed (existing MFC code). That solution will be much more simpler.