Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. Managed C++/CLI
  4. Incrementally convert existing native MFC Application to .NET

Incrementally convert existing native MFC Application to .NET

Scheduled Pinned Locked Moved Managed C++/CLI
c++csharpdotnetsysadminquestion
3 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • R Offline
    R Offline
    Rolf Kristensen
    wrote on last edited by
    #1

    Hi ya I'm working on a native C++ Client/Server application, where the Client is implemented using MFC. The Client and Server shares a common DataModel-library. I want to perform a incremental conversion of the MFC Client to a .NET implementation. The code-base is rather large (and obscure), so turning on /clr for the entire Client-project is not a good option. Is it possible to create a new ManagedClient-library, which the original Client-project can link with. Then slowly move the views and controls from the original Client-Project to the ManagedClient-library while converting them to managed c++/c#. So the main Client-project will continue to be unmanaged but will link to a managed library. At the same time the ManagedClient-library will probably need to access classes in the DataModel-library. Is it possible to create a ManagedDataModel-library which contains managed wrappers around the native DataModel-library. Is there a better way for incrementally converting an existing MFC application ? And are there any obvious pitfalls I should be aware of ? Best regards -Rolf

    S 1 Reply Last reply
    0
    • R Rolf Kristensen

      Hi ya I'm working on a native C++ Client/Server application, where the Client is implemented using MFC. The Client and Server shares a common DataModel-library. I want to perform a incremental conversion of the MFC Client to a .NET implementation. The code-base is rather large (and obscure), so turning on /clr for the entire Client-project is not a good option. Is it possible to create a new ManagedClient-library, which the original Client-project can link with. Then slowly move the views and controls from the original Client-Project to the ManagedClient-library while converting them to managed c++/c#. So the main Client-project will continue to be unmanaged but will link to a managed library. At the same time the ManagedClient-library will probably need to access classes in the DataModel-library. Is it possible to create a ManagedDataModel-library which contains managed wrappers around the native DataModel-library. Is there a better way for incrementally converting an existing MFC application ? And are there any obvious pitfalls I should be aware of ? Best regards -Rolf

      S Offline
      S Offline
      StevenS_Dev
      wrote on last edited by
      #2

      Yes. You can maintain your old MFC client application while calling into new managed DLLs. In fact, this is an article I've wanted to write for awhile. Any file which will be calling into a C# DLL will need to have the following options set in its Properties dialog: * C/C++/General - Compile with common language runtime (/clr) * C/C++/General - Debug Information Format - Program Database (/Zi) * C/C++/Code Generation - Basic Runtime Checks - Default (others may work too) * C/C++/Code Generation - Enable Minimal Rebuild - No * C/C++/Code Generation - Enable C++ Exceptions - Yes With SEH Exceptions (/EHa) * C/C++/Precompiled Headers - Create/Use Precompiled Header - Not Using Precompiled Headers Add the following near the top of your file (after #include's) * #pragma managed * using namespace System::Windows::Forms; * using namespace MyManagedDLL; ...and any other namespaces you may want to add. This just makes coding easier so you won't always need to prepend your classes with the fully qualified name. Right click on your project and select References. Add the following references. * mscorlib * System * System.Windows.Forms * Your special C# DLL Depending on your code, you may need to add more References. You will receive compilation errors if anything is missing. The above will allow you to call a managed DLL from your client MFC application. There might be one thing I left off. I've had others do this same thing and I recall one time someone mentioning they had to add another reference I missed. Going from managed to non-managed is a different story. One option is to use P/Invoke, but that is really best used for calling 'c' functions, not for C++. There is quite a lot written in regards to P/Invoke on this site. http://www.codeproject.com/KB/miscctrl/HostMFC.aspx[^] I haven't yet used it, but plan to look more into this for work when I have more time. This is a project explaining how to host your MFC application from within a .NET App Framework. It looks very interesting. I have not really had any pitfalls, but there are some things to be aware of. You will need to write code to convert between your C++ data types/classes and the managed data class. You will need to write this code in C++ using CLI.

      R 1 Reply Last reply
      0
      • S StevenS_Dev

        Yes. You can maintain your old MFC client application while calling into new managed DLLs. In fact, this is an article I've wanted to write for awhile. Any file which will be calling into a C# DLL will need to have the following options set in its Properties dialog: * C/C++/General - Compile with common language runtime (/clr) * C/C++/General - Debug Information Format - Program Database (/Zi) * C/C++/Code Generation - Basic Runtime Checks - Default (others may work too) * C/C++/Code Generation - Enable Minimal Rebuild - No * C/C++/Code Generation - Enable C++ Exceptions - Yes With SEH Exceptions (/EHa) * C/C++/Precompiled Headers - Create/Use Precompiled Header - Not Using Precompiled Headers Add the following near the top of your file (after #include's) * #pragma managed * using namespace System::Windows::Forms; * using namespace MyManagedDLL; ...and any other namespaces you may want to add. This just makes coding easier so you won't always need to prepend your classes with the fully qualified name. Right click on your project and select References. Add the following references. * mscorlib * System * System.Windows.Forms * Your special C# DLL Depending on your code, you may need to add more References. You will receive compilation errors if anything is missing. The above will allow you to call a managed DLL from your client MFC application. There might be one thing I left off. I've had others do this same thing and I recall one time someone mentioning they had to add another reference I missed. Going from managed to non-managed is a different story. One option is to use P/Invoke, but that is really best used for calling 'c' functions, not for C++. There is quite a lot written in regards to P/Invoke on this site. http://www.codeproject.com/KB/miscctrl/HostMFC.aspx[^] I haven't yet used it, but plan to look more into this for work when I have more time. This is a project explaining how to host your MFC application from within a .NET App Framework. It looks very interesting. I have not really had any pitfalls, but there are some things to be aware of. You will need to write code to convert between your C++ data types/classes and the managed data class. You will need to write this code in C++ using CLI.

        R Offline
        R Offline
        Rolf Kristensen
        wrote on last edited by
        #3

        I was actually planning to link with a static library compiled with /CLR (Giving access to .NET), while the old MFC project remains untouched. Is this not possible ? Found this article that seems to answer some of my technical questions Mixed (Native and Managed) Assemblies

        modified on Tuesday, October 28, 2008 11:50 AM

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups