将 C（不是 C++）转换为 C#
我有一些旧的 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，所以如果忽略其他所有内容，我的主要问题是是否存在任何移植限制导致这种做法不可取？
I have some old C 32 Bit DLLs that are using Oracle's Pro C precompiler library (proc.exe) to expose a hundred or so sproc/func calls to an even older VB6 GUI which references these functions through explicit Declare statements like so:
Declare Function ConnectToDB Lib "C:\windows\system32\EXTRACT32.DLL" (CXN As CXNdets, ERR As ERRdets) As Long
All the structures in the C header files are painstakingly replicated in the VB6 front end. At least the SQL is precompiled.
My question is, is it worth trying to impose a .Net interface (by conversion to an assembly) onto the the C code and upgrade the VB6 to C# or do you think I should just abandon the whole thing and start from scratch. As always, time is of the essence hence my appeal for prior experience. I know that if I keep the Declares in .Net I will have to add lots of complicated marshalling decorations which I'd like to avoid.
I've never had to Convert C to .Net before so my main question if everything else is ignored is are there any porting limitations that make this inadvisable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这是您使用 C 语言编写代码的唯一原因吗？如果是这样，我的建议是放弃它并简单地用 C#（甚至是 VB6，如果您的应用程序是用它编写的）重写整个内容......除非您已经对其进行了分析并且可以证明可测量的差异，否则您不会从 C 中进行 sql/sproc 调用中获得任何性能优势。由于维护此互操作桥的复杂性，您只会增加维护成本。
Is this the only reason you've got code in C? If so, my advice is to abandon that and simply rewrite the entire thing in C# (or even VB6 if that's what your app is written in) ... unless you've profiled it and can prove a measurable difference, you won't be getting any perf benefits from having sql/sproc calls in C. You will only get increased maintenance costs due to the complexity of having to maintain this interop bridge.
您应该通过围绕声明创建程序集来继续在 .NET 中使用 DLL。该程序集在 VB.NET 中的运行速度可能比在 C# 中快一些。然后让您的新 UI 引用该程序集。一旦你做到了这一点，你就为自己赢得了将 C 代码转换为 .NET 的时间。为此，您首先保留程序集并用新的 .NET 代码替换声明。很快您将替换所有内容并可以将其重构为不同的设计。
时间杀手是破坏行为。保留原始应用程序的行为越接近，转换速度就越快。请记住，引用传统 DLL 没有任何问题。 .NET 构建于多层 API 之上，最终深入到 Windows 继续使用的传统 DLL。同样，一旦您让 .NET UI 正常工作，您就有更多的时间来处理核心并将所有内容引入 .NET。
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升级到. NET 中，它会自动转换
Declare语句，所以不必太担心它们！一个常见的陷阱是开始乐观地重写一个大型软件，在修复旧架构中的一些众所周知的缺陷方面取得良好的早期进展，然后陷入您一直认为理所当然的功能中年。此时，您的管理层开始变得焦躁不安，一切都会变得非常不舒服。我去过那里，一点也不好玩。听起来您的用户已经焦躁不安，这是一个不好的迹象。
...这是 Microsofty 的一篇博客文章 同意我的观点：
......以及一些来自的官方建议Microsoft UK 关于从 VB6 迁移到 .NET
也许你的程序很小，并且你对它解决的问题有很好的理解，并且你很擅长准确估计并使你的项目步入正轨，这一切都会好起来的。
I always advise extreme caution before setting out to rewrite anything. If you use a decent tool to upgrade the VB6 to .NET, it will convert the
Declarestatements automatically, so don't stress about them too much!It's a common pitfall to start out optimistically rewriting a large piece of software, make good early progress fixing some of the well-known flaws in the old architecture, and then get bogged down in the functionality that you've just been taking for granted for years. At this point your management begin to get twitchy and everything can get very uncomfortable. I have been there and it's no fun. Sounds like your users are already twitchy, which is a bad sign.
...and here's a blog post by a Microsofty that agrees with me:
...and some official advice from Microsoft UK regarding migrating from VB6 to .NET
Maybe your program is small, and you have a great understanding of the problems it solves, and you are great at estimating accurately and keeping your projects on track, and it will all be fine.
如果您从 VB6 迁移到 VB.net 或 C#，请丢弃 C 代码并使用适当的 ODP.net 类或 LINQ 来访问这些存储过程。由于C层（据我理解）除了公开存储过程之外没有任何逻辑，因此切换后它不再有用。通过这样做，您（至少）可以获得更好的异常处理（即完全异常而不是神奇的返回代码）、可维护性等。
另请参阅：围绕存储过程自动创建 C# 包装器类
If you move from VB6 to VB.net or C#, throw away the C code and use the appropriate ODP.net classes or LINQ to access those stored procedures. Since the C layer (as I understand it) has no logic other than exposing the stored procedures, it's not useful anymore after the switch. By doing that, you get (at least) much better exception handling (i.e. exceptions at all instead of magic return codes), maintainability etc.
See also: Automatically create C# wrapper classes around stored procedures