我目前有一个MFC项目（松散地）利用doc / view架构。该应用程序包含所有业务逻辑和GUI代码。我希望提供一个类似API的访问，可以通过.NET访问。在这样做时，我想尽量减少重写，所以我想知道选项是什么？
有没有办法在MFC应用程序周围加入.NET接口，同时仍然按原样使用MFC入口/启动？这样可以运行当前的应用程序并让另一个应用程序动态获取应用程序的句柄并使用API吗？
任何其他可能更有意义的方法？
[编辑] 最终目标是将业务逻辑分解为库和GUI到某种新框架（winforms，wpf，某些东西......）现在，我正在寻找通往基本API的第一个目标的方法来自第三方应用程序的控制。有了这些知识，是否值得进行COM接口的中间步骤，然后最终将逻辑拉入编写.net包装器的库以进行基本API访问？
答案 0 :(得分：0)
你真的想要什么？是否要为第三方提供API来驱动您的应用程序？或者您真的想用.NET UI替换MFC UI吗？
如果是前者，那么答案就是COM。从.NET可以看到COM，因此如果您的MFC应用程序支持COM接口，那么.NET应用程序可以通过它进行调用。
我目前正在开发一个MFC应用程序，它完全支持您描述的内容。我们的EXE公开了一个COM接口，它可以由用C ++，C＃，VB甚至Java编写的其他应用程序驱动。
[编辑以响应您的修改]
如果您最终想要用WinForms / WPF UI替换MFC UI，那么您可以将现有的C ++业务代码包装在C ++ / CLI中并从C＃访问它。添加COM API并不是您的方案中的中间步骤。这是一项很多工作，如果您真正想做的就是更换用户界面，可能不值得。
您可以参考this question来阅读使用WPF替换MFC UI的经验的详细信息。