我们有一个体面的MFC MDI桌面应用程序。有没有合理的方法将MFC应用程序转换为.net应用程序，还是更好地重写？如果答案是特定于应用程序的，您使用什么标准来做出决定？
答案 0 :(得分：2)
我会跳过WinForms并前往WPF。
根据应用程序的设计方式，您不必重写所有内容。您可以使用托管C ++包装器从C＃代码调用C ++代码，从而允许您重用现有的C ++代码。微软在WPF和Win32 / MFC之间的互操作方面也有extensive documentation。你可以用WinForms做类似的事情。
微软已经竭尽全力提供从MFC到WinForms / WPF的迁移路径，因为他们知道公司不能丢弃多年开发的代码。
此外，如果你谷歌“WPF和MFC”，你会发现许多人在同一个项目中使用这两种技术的例子。
答案 1 :(得分：1)
当从MFC移植到WinForms时，您必须重写UI代码，如果您在UI和业务逻辑之间有很好的分离，那么最好通过使用托管C ++或将其转换为C＃来移植业务逻辑（语法足够相似，使其成为可能）。
我已经为一个小型MFC应用程序完成了这项工作，我将业务逻辑移植到c＃，将C ++代码粘贴到c＃文件中并修复代码直到它开始工作，我从头开始重写了GUI。
这是一个非常聪明的举动，因为我们一直在将它开发成一个大型应用程序，最终结果比我们在同一时间表中在MFC中所做的任何事情都要好得多。
我们还有一个巨大的MFC应用程序，UI和业务逻辑之间没有明确的分离，我们希望将其移植到.net但尚未弄清楚如何做到这一点。
答案 2 :(得分：0)
它绝对是一个重写，但MFC中的很多概念都有.NET对应物，因此您可以映射很多域模型。我会使用Windows窗体，因为它可以轻松映射到MFC提供的相同Win32样式UI。
如果您的MFC应用程序很好地分离了域模型和业务规则，您甚至可以使用C ++ .NET重用某些代码，并保持不受管理或将其转换为托管类，并可选择将其转换为C＃以后。
答案 3 :(得分：0)
请参阅我对this question的回答，该答案与此基本相同。
答案 4 :(得分：-2)
在考虑从MFC到WPF的转换时，我花了相当多的时间来研究C＃，WPF，Expression Blend，MVVM。
WPF（VS 2010）是有意义的，如果你想要失去50％的MFC功能，并且在你完成时有一个非常复杂，非常慢的应用程序。没有MDI。
MVVM实际上有太多的开销。
收益：垃圾收集，可调整大小的对话框，XAML以及更多数据绑定选项都不值得。
最近升级到MFC，添加了一个功能区栏（比Expression Blend中的功能区栏创建更优秀）给了我所有我想要的功能。
简而言之，从MFC转换为WPF / .NET是一个坏主意;忘掉它。
不要放弃MFC微软，否则你会让人们跳槽。 （WTF ?????）