将未经管理的C++项目移植到C#

Question

我需要将一个C/C++非托管项目（VS 2008）移植到C#（最好是.NET 3.5）。

是否有任何转换辅助工具？比如说，翻译代码语法并询问您每个问题点的验证/修改（我想我在做梦...）

在哪里可以找到关于此转换的一些有用的howto或文章。如果它们包含特定提示，例如：

extern变量应设置为公共静态类

（我不知道，我只是猜测...）

请不要建议“您可以从.NET调用C++ DLL”，因为我知道这是可能的，但我无法这样做。

注意：

• C/C++项目仅使用STL和其他基本函数，没有第三方库等。
• 我不能直接或从C#包装它，因为我们公司需要维护/修改代码，而我们在C#方面的技能要比C++高得多。

- digEmAll

---

你不能只是在C++/CLI中创建一个 .Net 封装器吗？ - adrianm

我真的非常非常不想包装它。请检查我的编辑 ;) - digEmAll

Answer 1

将其转换成C#代码所需的成本远高于将其包装并支付自由职业者（比如我）每隔几个月（或几年）为您更改C++代码以帮助您。虽然有一些机械方法，但更大的问题是您永远无法确定新的C#代码是否完全执行了旧的C++代码所做的工作。我有一些客户尝试过这样做，大多数人放弃并且把工作扔掉了。那些成功的人非常缓慢地进行，就像这样：

首先，您需要包装旧库，并确保您的UI或任何新代码（Web服务等）成功调用旧库。这可以让每个人都获得一些“物有所值”，并为解决“我们无法维护旧代码”的问题争取时间。您还需要开发一个全面的测试套件，证明旧库在各种边缘情况和仅在野外出现的奇怪事物中所执行的功能。随着时间的推移，您将从旧库中移动功能到新的C#库中，并更改调用代码以使用该功能的新库。您首先移除最不稳定的部分，即您经常更改的部分。在每个阶段，您都会再次运行测试用例，以确保从C++到C#的转换没有破坏其计算结果。也许您从未将其中的一些部分移出，最终将其全部移动。当您感到无法维护自己的库并需要支付他人来代替时的风险低于继续翻译它的成本时，可以停止移动。

建议您在开始时拥有具有良好C++技能的人员进行协助。您可能会遇到对您来说不太合理的事情。但是您可以很快地从库中获得价值，并在长期内解决您的根本问题。

- Kate Gregory

---

“缺少C++熟练的程序员”是移植而不是封装的原因之一，但并非唯一原因。感谢您的提示。 - digEmAll

Answer 2

这取决于您所说的端口是什么意思。

您可以使用C#重写一些内容，但不是全部。一些硬件或旧库即使您移植自己的代码也必须使用C/C++进行处理。我不知道是否存在可靠的C++到C#的自动转换器，我怀疑这种工具的存在。

更好的想法可能是在新的C#代码中包装现有的代码。例如，您可以创建一个C++/CLI互操作层。或者，如果您不想在同一进程中混合本机/托管代码，可以使用类似Google Protocol Buffers的东西与本机代码通信。

- Assaf Lavie

Answer 3

我怀疑代码转换工具不会有所帮助。如果你需要让一些C++与.NET以某种方式协同工作，最简单的方法是编写一个托管的C++层来包装它，并为.NET应用程序提供接口。但这取决于代码。

重写的目的是什么？你的代码是做什么的？它是否与其他组件进行接口？它是否有GUI界面？它是一个独立的可执行文件还是一个库？它是一个COM/ActiveX服务器还是使用COM组件？它是否链接到其他DLL或使用第三方库？

所有这些都会影响您如何移植/从头开始重写应用程序。例如，如果您的代码是一个MFC应用程序，您可能会忘记尝试挽救大部分代码。如果您的应用程序涉及http /高级网络处理，您可能需要从头开始编写。如果您的代码是低级别的，您可能需要通过托管的C++层进行一些C#和一些C++的重构。

有很多选择，这真的取决于您的应用程序正在做什么，它是如何编写的等等。

- locka

---

如果只是一个基本的STL应用程序，那么我认为最好只需用C#编写相应的代码。我不知道有任何机器翻译工具，但它们不可能生成良好的代码。 以原始代码为灵感，但像集合类、字符串操作、内存分配等这样的东西已经足够不同，你可能不会进行逐行移植。阅读此文章以了解翻译工具需要处理的问题类型：http://msdn.microsoft.com/en-us/library/ms379617%28VS.80%29.aspx - locka