我有一些旧的 C 32 位 DLL，它们使用 Oracle 的 Pro C 预编译器库 (proc.exe) 向更旧的 VB6 GUI 公开大约 sproc/func 调用，该 GUI 通过显式 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，所以我的主要问题是，如果其他所有内容都被忽略，是否有任何移植限制使这种做法不可取？
... 至少 SQL 是预编译的。
这是您使用 C 语言编写代码的唯一原因吗？如果是这样，我的建议是放弃它并简单地用 C# 重写整个东西（或者甚至 VB6，如果这是你的应用程序所用的）......除非你已经对其进行了分析并且可以证明一个可测量的差异，否则你不会通过在 C 中调用 sql/sproc 获得任何性能优势。由于必须维护这个互操作桥的复杂性，您只会增加维护成本。
You should continue to use the DLL in .NET by creating an assembly around the Declares. That one assembly probably would go a little quicker in VB.NET than C#. Then have your new UI reference that assembly. Once you have that going then you have bought yourself time to convert the C code into .NET. You do this by initially keeping the assembly and replacing the the declares with new .NET code. Soon you will have replaced everything and can refactor it to a different design.
The time killer is breaking behavior. The closer you can preserve the behavior of the original application the faster the conversion will be. Remember there nothing wrong with referencing a traditional DLL. .NET is built on many layers of APIs which ultimately drill down to the traditional DLLs that continue to be used by Windows. Again once you have the .NET UI working then you have more time to work on the core and bring everything into .NET.
如果您从 VB6 迁移到 VB.net 或 C#，请丢弃 C 代码并使用适当的 ODP.net 类或 LINQ 来访问这些存储过程。由于C层（据我了解）除了暴露存储过程之外没有其他逻辑，因此切换后不再有用。通过这样做，您可以获得（至少）更好的异常处理（即完全异常而不是魔术返回代码）、可维护性等。
另请参阅：围绕存储过程自动创建 C# 包装类
在着手重写任何内容之前，我总是建议格外小心。如果您使用一个不错的工具将 VB6 升级到 .NET，它会Declare自动转换语句，所以不要过分强调它们！
开始乐观地重写一大块软件，在修复旧架构中的一些众所周知的缺陷时取得良好的早期进展，然后陷入你刚刚认为理所当然的功能，这是一个常见的陷阱年。在这一点上，你的管理层开始变得紧张，一切都会变得非常不舒服。我去过那里，这并不好玩。听起来您的用户已经很紧张，这是一个不好的迹象。
...这是微软同意我的博客文章：
我在 .NET 早期工作过的许多公司首先考虑重写，部分原因是在迁移到 .NET 的同时，他们强烈希望改进底层架构和代码结构。不幸的是，其中许多项目遇到了困难，有几个项目从未完成。他们试图解决的问题太大了
...以及来自 Microsoft UK关于从 VB6 迁移到 .NET 的一些官方建议
对 .NET 进行完全重写要比转换成本高得多，而且很难做好[比转换]……我们只在少数情况下推荐这种方法。
也许你的程序很小，你对它解决的问题有很好的理解，你很擅长准确地估计和保持你的项目在轨道上，一切都会好起来的。