将 C（不是 C++）转换为 C#答案

【问题标题】：Converting C (not C++) to C#将 C（不是 C++）转换为 C#
【发布时间】：2009-11-17 13:26:41
【问题描述】：

我有一些旧的 C 32 位 DLL，它们使用 Oracle 的 Pro C 预编译器库 (proc.exe) 向更旧的 VB6 GUI 公开大约 sproc/func 调用，它通过像这样的显式 Declare 语句引用这些函数：

Declare Function ConnectToDB Lib "C:\windows\system32\EXTRACT32.DLL" (CXN As CXNdets, ERR As ERRdets) As Long

C 头文件中的所有结构都在 VB6 前端中精心复制。至少 SQL 是预编译的。

我的问题是，是否值得尝试将 .Net 接口（通过转换为程序集）强加到 C 代码上并将 VB6 升级到 C#，还是你认为我应该放弃整个事情并从头开始.与往常一样，时间至关重要，因此我呼吁以前的经验。我知道如果我将声明保留在 .Net 中，我将不得不添加许多我想避免的复杂编组装饰。

我以前从未将 C 转换为 .Net，所以如果忽略其他所有内容，我的主要问题是是否有任何移植限制导致不建议这样做？

【问题讨论】：

你也可以“中途”使用 C++/CLI。
我考虑过这一点，但这还不足以让它值得额外的时间。等待这个的量化分析师已经支持我应该实施的改变，但你知道，当你看到一块 sh1t 时，你会情不自禁地想对其进行润色。

标签： c# .net c vb6 vb6-migration

【解决方案1】：

...至少SQL是预编译的。

这是您使用 C 语言编写代码的唯一原因吗？如果是这样，我的建议是放弃它并简单地用 C# 重写整个东西（或者甚至 VB6，如果这是你的应用程序所用的）......除非你已经对其进行了分析并且可以证明一个可测量的差异，否则你不会通过在 C 中调用 sql/sproc 获得任何性能优势。由于必须维护这个互操作桥的复杂性，您只会增加维护成本。

【讨论】：

不，那里也有很多关于证券的财务计算，尽管我同意你关于分离 SQL 的观点。它不是为了维护而设计的。前端的任何更改都必须一直传播。
重写总是表面上很有吸引力——新代码会好很多！ - 而且通常非常冒险。

【解决方案2】：

您应该通过围绕声明创建程序集来继续在 .NET 中使用 DLL。那个程序集在 VB.NET 中可能会比 C# 快一点。然后让您的新 UI 引用该程序集。一旦你做到了，那么你就为自己赢得了将 C 代码转换为 .NET 的时间。为此，您最初保留程序集并用新的 .NET 代码替换声明。很快你就会替换掉所有东西，并且可以将其重构为不同的设计。

时间杀手是破坏性行为。您越能保留原始应用程序的行为，转换就越快。请记住，引用传统的 DLL 并没有错。 .NET 建立在许多 API 层之上，这些 API 最终深入到 Windows 继续使用的传统 DLL。同样，一旦您的 .NET UI 正常工作，您就有更多时间在核心上工作并将所有内容都带入 .NET。

【讨论】：

+1。任何体面的升级工具（提示 - 不是来自 Microsoft）都会通过单击按钮为您整理 Declare 语句。另一个时间杀手是测试你没有破坏行为。我相信这是大型转换工作的主要努力。

【解决方案3】：

我always advise extreme caution 在着手重写任何东西之前。如果您使用decent tool 将VB6 升级到.NET，它会自动转换Declare 语句，所以不要过分强调它们！

在开始时乐观地重写大型软件，在修复旧架构中的一些众所周知的缺陷时取得良好的早期进展，然后陷入您刚刚使用的功能，这是一个常见的陷阱多年来理所当然。在这一点上，你的管理开始变得紧张，一切都会变得非常不舒服。我去过那里，这并不好玩。听起来您的用户已经心烦意乱，这是一个不好的迹象。

...这里是一个微软agrees with me 的博客文章：

我在 .NET 早期工作过的许多公司首先考虑重写，部分原因是在迁移到 .NET 的同时，他们强烈希望改进底层架构和代码结构。不幸的是，其中许多项目遇到了困难，有几个项目从未完成。他们试图解决的问题太大了

...还有一些关于从 VB6 迁移到 .NET 的 official advice from Microsoft UK

对 .NET 进行完全重写要比转换成本高得多，而且很难做好[比转换]……我们只在少数情况下推荐这种方法。

也许您的程序很小，并且您对它所解决的问题有很好的了解，并且您很擅长准确地估计并使您的项目保持在正轨上，一切都会好起来的。

【讨论】：

+1 感谢 Mark 下载了 ArtinSoft 的转换器以供查看。

【解决方案4】：

如果您从 VB6 迁移到 VB.net 或 C#，请丢弃 C 代码并使用适当的 ODP.net 类或 LINQ 来访问这些存储过程。由于C层（据我了解）除了暴露存储过程之外没有其他逻辑，因此在切换后不再有用。通过这样做，您可以（至少）获得更好的异常处理（即完全是异常而不是神奇的返回码）、可维护性等。

另请参阅：Automatically create C# wrapper classes around stored procedures

【讨论】：