VC ++到C＃迁移指南/方法/问题

Question

我们计划将少数VC ++ Legacy产品迁移到带有.NET平台的C＃。我正在收集相关信息，然后提出建议，为客户提供乐观有效的方法。我正在寻找以下细节。

1. 将VC ++迁移到C＃.NET的任何一般准则
2. 当我们开展此活动时，团队可能面临的问题是什么
3. 是否有现有方法？我相信很多人可能已经尝试过，但可能没有详细信息，但在此基础上巩固这一点不仅有助于我，也有助于寻找这些信息的任何人。
4. 互联网上有哪些优质/有效的资源？
5. 如果该群组中有微软用户，那么微软团队会提出哪些建议？
6. 架构，组件设计方法等

请帮助我获取这些信息，每一分钱都会帮助我获得良好的理解。

提前感谢那些将通过此查询分享智慧的人。

Answer 1

通常，我最好的建议是：不要这样做。

如果你有干净的C ++代码，没有理由重写它。使用C ++ / CLI很容易围绕遗留代码构建包装，使其可以从C＃/ .NET中使用。

这通常是一种更好，更快，更安全的方法。然后，您可以在.NET中进行新的开发，并在需要时慢慢迁移所需的任何现有代码。

话虽这么说，将代码从C ++迁移到C＃通常非常完整，从头开始重写（除非你如上所述进行包装）。这主要是因为图书馆存在巨大差异，而不是语言的差异。

.NET Framework提供了一个庞大的工具库，可以而且应该在编写代码时更改代码的体系结构。如果你只是直接将C ++移植到C＃，你会发现你将以非标准的方式做很多事情，并且最终会得到非常难以维护的C＃代码。

根据我的经验，我的建议是首先包装你的代码。然后，如果您决定需要扩展某些功能，并且因为包装器而无法使用它，那么您可以使用全新的技术和库在C＃中重写代码的一个特定部分 - 并逐个替换C ++。

Answer 2

如果您有一个复杂的类层次结构，请注意C＃不支持多重继承，因此您可能需要重新考虑程序的结构。

编辑：要记住的另一件事是.net框架非常非常大。您可以在c ++代码中找到可以完全替换为c＃中的标准库类的实用程序类。

Answer 3

我过去在将大型应用程序从C ++（MFC）迁移到C＃（WinForms）方面拥有丰富的经验。

一些关键因素会影响您的策略：

1. 首先，你为什么要迁移？了解您选择正确策略的目标。在大多数情况下，您不应该“仅仅”迁移，以便使用酷炫的新技术。

2. 现有代码库有多大？如果它是一个非常小的代码库，只需要几周就可以重写，不要过度分析而只是去做...

3. 您是否必须将所有现有功能转换为C＃？或者你能保持C ++并只在C＃中添加新功能吗？根据现有C ++代码的组件化方式，您可以使用COM Interop等技术在C＃中进行开发时继续重用它。

4. 在重写所有内容之前，你能否延迟发布任何新版本？通常答案是否定的。 （想想Netscape - 你可能想要阅读this ...）你可能想要提出一个策略，你可以逐步替换应用程序中的组件和框架，让你自由发布版本升级，以便每个版本都有更多的C＃和更少的C ++。

5. 基本上，一种对我有用的方法是用C＃重写我的应用程序的基本框架，并使用COM Interop从我的C ++应用程序中使用这些框架。每个版本在C＃中都有一些框架和控件。一旦我们转换了代码的临界质量以及主窗口的所有控件，我们就将应用程序的入口点更改为.NET而不是C ++。

6. 至于资源，对我来说，这本书".NET and COM: The complete interoperability guide"是宝藏。

这是我现在能想到的主要内容。我或许可以回答你可能遇到的许多具体问题。

Answer 4

立即出现的一些事情：

• 确保不要混淆C ++“char”和C＃“char”。您可能知道C＃中的“char”实际上并不是单字节原语。因此，在移植过程中您可能会感到困惑，请注意在C＃中将C ++“char”移植到“byte”。

• 正如Brennan Vincent所说，C ++支持多继承，而C＃则不支持。如果您的课程“复杂”，您可能需要重新考虑层次结构。

• 指针在C＃中不像C ++中那样是原生的。同样，这取决于你如何编写你的C ++应用程序，但我可以打赌你在那里使用指针，所以确保usafe与C＃相对应，因为它以不同的方式处理它们，透明地来自程序员（在大多数情况下）。

  < / LI>

我可能会在稍后添加一些，很好的问题！

Answer 5

首先，不要使用您正在使用的本机C ++代码并将其编译为C ++ / CLI。你会得到可怕的结果。其次，不要使用您正在使用的本机C ++代码并尝试将其转换为C＃，同时注意使用基类库的位置，更改数据访问技术以及将您的UI范例从MFC调整为WPF。你会花很多精力来制作你以前所拥有的东西。

相反，请使用您正在使用的本机C ++代码并对其进行重构，以便您拥有一个或多个“业务逻辑”库。如果这些已经存在，那么它们可能具有COM接口，它们可能会暴露一些“extern C”类型函数，或者它们可能会暴露一些C ++实例方法。别担心。如果它们尚不存在，您有两种选择。如果表示层只需要一些方法，并且它们采用字符串之类的简单操作，那么将一些“extern C”函数作为业务逻辑的网关。现在，您可以使用P / Invoke从托管UI（VB或C＃，Windows窗体或WPF，无论如何）调用它们。如果有很多并且您想要组织它们，或者如果它们需要采用复杂的结构或对象，那么编写一个C ++ / CLI类或可以与原生C ++类进行通信的类，同时公开“public ref class”类到托管UI。 C ++ / CLI将使编组和生命周期问题更简单。

对于新UI，从头开始编写，在需要时调用业务逻辑。仅使用旧UI作为所需功能和验证的指南。使用新UI技术（WPF或其他）的“外观和感觉”来构建UI本身，而不是尝试机械转换。如果你过于贴近旧ui，你最终会追逐像素并且比你需要的更努力。旧的应用程序有3个按钮和一个复选框？很棒，3个看起来像WPF的按钮和一个看起来像WPF的复选框。而是在进行更改时切换到功能区？精细。完成后可以看起来不同。

然后，您部署仍然编译为本机代码的本机业务逻辑库，如果有C ++ / CLI包装器，则部署您的托管UI。这适用于除手机之外的任何事情。

我只需要再说一遍，请不要将工作的本机C ++业务逻辑移植到C＃中，作为项目初始阶段的一部分。当它完成并正常工作时，如果你有一个很好的商业原因（就像我们不想再花钱在C ++开发者身上）那么你可以考虑它。但首先让它使用互操作。这样做的好处是，如果你的翻译弄乱了不再和你在一起的人所写的微妙的商业逻辑，依赖于当前团队不知道的C ++微妙之处，那么你可以在其余的时间里依靠包装的库。