Best way to wrap an MFC Doc/View application in a .NET API?

I currently have a MFC project (loosely) utilizing the doc/view architecture. This application contains all business logic as well as GUI code. I'm looking to provide an API-like access开发者_JAVA技巧 to this that would be accessible via .NET. In doing this, I'd like to minimize re-write, so I'm wondering what the options are?

Is there a way to incorporate a .NET interface around the MFC app while still utilizing the MFC entry/startup as-is? So that the current app could be run and have another app dynamically get a handle to the app and utilize the API?

Any other approaches that may make more sense?

[EDIT] The end goal would be to break out the business logic into a library and the GUI to some sort of new framework (winforms, wpf, something...) For now, I'm looking for the way to the first goal of basic API control from a third party application. With this knowledge is it worth doing the intermediary step of a COM interface then eventually when the logic is pulled into a library writing a .net wrapper for basic API access?

---

What do you really want here? Is it that you want to provide an API for third parties to drive your application? Or do you really want to replace your MFC UI with a .NET UI?

If it's the former, then the answer is COM. COM is visible from .NET so if your MFC application supports a COM interface then .NET applications can make calls through it.

I currently work on an MFC application that supports exactly what you describe. Our EXE exposes a COM interface, which can be driven by other applications written in C++, C#, VB, or even Java.

[Edit in response to your edit]

If you ultimately want to replace the MFC UI with a WinForms/WPF UI then you can wrap your existing C++ business code in C++/CLI and access that from C#. Adding a COM API isn't really an intermediate step in your scenario. It's a lot of work and probably not worth it if what you're really looking to do is replace the UI.

You can refer to this question to read the details of my experience with replacing an MFC UI with WPF.