在将旧版 C++ 组件之一转换为 C# 时需要建议
Posted
技术标签:
【中文标题】在将旧版 C++ 组件之一转换为 C# 时需要建议【英文标题】:Need advice in converting in one of the legacy C++ component into C# 【发布时间】:2010-07-04 20:13:21 【问题描述】:目前,我们正在开发一个 C++ 遗留代码库,它由多个软件组件组成。
其中一个组件的编写方式极难维护。 (例如,内存分配在 X 位置完成,但内存释放在 Y 位置完成。这使得内存管理成为一项痛苦的工作)。到目前为止,我们能够解决(或解决)所有内存泄漏问题。
然而,经过几轮的bug修复,我们的感觉是,由于这个软件组件的维护成本很高,我们离目前的里程碑还不能太远。
我知道重写源代码可能不好:http://www.joelonsoftware.com/articles/fog0000000069.html
但是,我们认为最好从头开始重写,而不是重构当前代码,因为
到目前为止,团队中没有人能够完全理解该软件组件代码。 旧版软件组件是一小部分软件。 20k 行,我猜 我们的团队非常清楚我们的要求和我们想要实现的目标因此,我们计划使用托管代码,至少让内存管理成为一项轻松的工作。我们打算选择C#,作为
我们所有的 C++ 代码都是使用 Microsoft VC++ 编译的 我们在其他软件组件中使用 MFC。 (以 DLL 形式)每个 DLL 都有自己的资源。我来自 C++ 和 Java 背景,对 C# 了解不多。
-
C# 与 MFC DLL 的接口如何,某些 DLL 函数会调用 MFC GUI?
有什么需要注意的吗?
如果我们使用托管 C++,与传统 C++ DLL 的接口会更容易吗?
谢谢。
【问题讨论】:
【参考方案1】:我也有类似的情况,我也做了一些混合 C++ 和 C# 的实验。然而,我的应用程序中的问题是:
应用程序没有明确划分为不同的模块,因此很难将特定模块从 C++ 迁移到 C# 该应用程序占用大量 CPU,实验表明从 C++ 到 C# 或从 C# 到 C++ 的调用开销很大此外,您不能直接从本机/非托管 C++ 调用 C#,这意味着我必须引入一个额外的中间 C++/CLI(或者这称为 C++.Net?)层。
因此,我选择不转向 C#,而是继续使用 C++。
因此,如果您想从 C++ 迁移到 C#,请确保:
你有明确分离的模块 从 C++ 到 C# 的转换(调用)或反之亦然是在一个不经常使用的地方(因此不在 CPU 密集型任务期间)此外,请记住,如果您不是项目的唯一开发人员,那么您的所有(或大多数)开发人员也应该学习 C#。您不想将所有 C# 代码委派给最新的初级开发人员,因为如果他离开,您将(或可能)遇到麻烦。
【讨论】:
【参考方案2】:C# 与 MFC DLL 的接口如何,某些 DLL 函数会调用 MFC GUI?
一点都不好。您不能 P/Invoke 到 C++ 库——它仅适用于 C 导出。您需要编写一个包装器,将 C 库接口公开给您从 C# 进行 P/Invoke,或者您需要使用 C++/CLI 重新编译 MFC。虽然 Winforms 是一个可与 MFC 相媲美的用于 .NET 代码的库,但几乎没有理由这样做。
有什么需要注意的吗?
我不明白这个问题。
如果我们使用托管 C++,与传统 C++ DLL 的接口会更容易吗?
考虑到你不能用 C# 来做,是的。您必须重新编译这些 C++ DLL 以让它们公开 C 接口,或者您必须使用 C++/CLI 从源代码重新编译它们。
注意:无论您在这里做什么,您仍然需要担心内存管理和本机代码中发生的任何事情的对象生命周期。 CLI 不会自动为您管理本机资源。
【讨论】:
您不能将托管代码作为 COM 对象公开给非托管代码吗?这样它就不需要 C 包装器 - 尽管它仍然会很痛苦 :) @Vitor:是的,我想你可以用 COM 做到这一点……不过,这比暴露 C 接口需要更多的麻烦。 但是,但是...C# 很神奇,所以我们永远不必担心任何类型的资源管理!!! @Noah:不,它没有。如果您从创建 C++ 类的 C# 调用 C 接口,则该 C++ 类仍必须由您手动管理。 CLI 只管理托管对象。以上是关于在将旧版 C++ 组件之一转换为 C# 时需要建议的主要内容,如果未能解决你的问题,请参考以下文章
关于将旧版 ASP 站点与 .NET 2.0 混合使用的建议