将 MFC (VC6) 应用程序迁移到 .NET 2008答案

【问题标题】：Migrating MFC (VC6) application to .NET 2008将 MFC (VC6) 应用程序迁移到 .NET 2008
【发布时间】：2011-03-22 04:07:35
【问题描述】：

我想从开发者那里得到非常具体的回答，并想知道你是如何解决你所面临的问题的。

我们有非常大的 MFC (VC6) 32 位应用程序存在 10 年。现在我们想将它迁移到 .NET 非托管 64 位应用程序。这里我们有一些问题，我们的 UI 不应该改变，我们可能需要一些托管的 .NET 类以便于开发，在不影响架构的情况下如何添加托管代码和非托管代码，很多 win32 API 可能会更改为新的 API，应该运行XP、Vista、Windows 7 OS 机器没有任何变化，这些活动不应该是耗时的，新技术分析应该做，因为我们是 MFC 程序员......

请分享您的经验，如果您有任何明确的文件将非常有帮助...

注意：为了清楚地理解，我再次重新表述一些观点。我们希望将我们的 VC6 本机代码 32 位应用程序迁移到具有 64 位支持的 VS2008（或 VS2010）本机代码（非托管 C++）。主要要求是现有 UI 不应该有任何变化。另外，如果.NET支持托管代码和非托管代码的组合，我们可以尝试在非托管C++环境中使用.NET远程处理等一些特性。我想向所有人传达的另一件重要的事情是，我们不会用 C# 或从头开始编写任何代码。

【问题讨论】：

您想用 C# 为 .NET 重写您的应用程序，还是只想让您的 MFC 应用程序在 Visual Studio 2008 中编译为 C++ 应用程序？
您要求对一个非常不具体的问题提供非常具体的答案。不知道在避免这种情况 10 年后会遇到什么。
@auujay：我认为 Snabak 指的是让 hte MFC 应用程序在 VS2008 中编译以及与 64 位支持相关的更改。用 C# 重写应用程序是不可能的，因为整个 KLOC 将达到 550 KLOC 左右。
它是 .NET 或非托管的。哪一个？将其保留为本机（非托管）C++，使其在 2010 年构建并利用更新的 MFC 是可行的。将其迁移到托管代码是完全不同的游戏。
朋友们...感谢您的 cmets。为了清楚地理解，我再次重新表述一些观点。我们希望将 VC6 本机代码 32 位应用程序迁移到支持 64 位的 VS2008（或 VS2010）本机代码（非托管 C++）。主要要求是现有 UI 不应该有任何变化。另外，如果.NET支持托管代码和非托管代码的组合，我们可以尝试在非托管C++环境中使用.NET远程处理等一些特性。我想向所有人传达的另一件重要的事情是，我们不会用 C# 或从头开始编写任何代码。

标签： c# .net winapi visual-studio-2010 mfc

【解决方案1】：

我们已经完成了这些步骤（VC6 -> VS2005 -> VS2008 ->（很快）VS2010），大多数问题都与 API 的更改有关。

发出大量警告消息的不安全字符串操作（strcpy 与 strcpy_s）（如果您不想全部修复，请使用 _CRT_SECURE_NO_WARNINGS 预处理器定义来删除它们）
更改了消息处理程序的原型（返回 LRESULT、WPARAM 和 LPARAM 的更改……）
已弃用的 API（您很快就会发现它们，我认为 msdn 上有一个页面）
编译器可能对标准 C++ 更加严格。

很难说具体...

但请查看此博客条目以获取更多信息：http://insidercoding.com/post/2008/08/20/Migrating-from-VC6-to-VC9.aspx

祝你好运。最大。

【讨论】：

【解决方案2】：

您要求的并不是真正的迁移，而是几乎完全重写，至少是整个 UI。除非您的“非常大......阅读乔尔的Things You Should Never Do.

底线：这几乎可以肯定是一个非常糟糕的想法。如果你仍然这样做，你需要开始意识到它将非常耗时。

如果您决定继续这样做，您几乎需要逐步进行。为此，我可能首先在现有代码中找到离散的“部分”功能，然后将这些部分转换为 ActiveX 控件。一旦你明白你的主程序基本上是一个相当小的框架，大多数实例化和使用 ActiveX 控件，在托管代码中创建一个新框架就变得相当容易了，它做大致相同的事情，委托大部分对现有 ActiveX 控件的实际工作。完成此操作后，您可以开始将各个控件迁移到您认为合适的托管代码。

这样做的目的是避免有很长的时间间隔，在此期间您只是编写复制旧代码的新代码，但不能为您的客户进行任何更新。几乎我见过的唯一合理的替代方案是拥有两个独立的开发团队：一个继续工作并更新旧代码库，同时第二个团队从头开始全面重写。如果你有足够的钱，这种方法会很有效。

例如，微软曾多次这样做过。举几个例子，几年前有传言说 Borland（当时微软在编程语言工具方面的最大竞争对手）将生产 TurboBASIC，微软认为 QuickBASIC（当时的 V2）真的无法竞争。作为回应，他们成立了两个团队：一个团队尽可能多地升级到 QuickBASIC 2，以生产 QuickBASIC 3。第二个团队从头开始完全重写，产生了 QuickBASIC 4。

另一个例子是 Windows 95/98/... 与 Windows NT。他们继续开发现有的 Windows 代码库，同时从头开始完全重写以生产 Windows NT。虽然他们让两个团队保持同步，所以 UI 看起来很相似，但两者几乎完全是分开开发的。只有在两者重叠年之后，他们才最终放弃了旧代码库的工作（我有时想知道 Windows Me 的蹩脚是否至少部分不是故意的，或多或少强迫用户迁移到 NT 代码库）。

除非你能做到，否则几乎唯一的成功机会就是使用渐进式方法。

【讨论】：

我们希望在一段时间内执行这两个项目（现有的和新的迁移项目）。一旦迁移的项目（VS2008非托管C++ 64位项目）在生产领域合格，我们将停止支持该项目的现有版本（VC6原生代码32位项目）。

【解决方案3】：

正如 Jerry 提到的，Joel 在他的博客“你不应该做的事情”中谈到了这一点。此外，此转换还需要考虑其他事项。

您将如何处理现有的 VC++ 6.0 代码库。
进行更改后测试整个产品所需的认证时间（不同的操作系统、SQL 等）。
如何管理有和没有 64 位支持的 2 个代码库。

PS：最重要的是，当您在 VS2010 中修复和验证您的产品时，我猜 VS 2012 会发布 :)

【讨论】：