我有一些旧的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，所以我的主要问题是否其他一切都被忽略了是否有任何移植限制使得这个不可取？
答案 0 :(得分：3)
......至少SQL是预编译的。
这是你在C中获得代码的唯一原因吗？如果是这样，我的建议就是放弃它，简单地用C＃重写整个东西（如果这就是你的应用程序的内容，甚至是VB6）...除非你对它进行了描述并且能够证明一个可衡量的差异，否则你不会在C中使用sql / sproc调用可以获得任何好处。由于必须维护这个互操作桥的复杂性，只会增加维护成本。
答案 1 :(得分：2)
您应该通过在Declares周围创建程序集继续在.NET中使用DLL。在VB.NET中，一个程序集可能会比C＃快一点。然后让你的新UI引用该程序集。一旦你有了这个，那么你已经花了很多时间将C代码转换成.NET。您可以通过最初保留程序集并用新的.NET代码替换声明来完成此操作。很快你就会取代所有东西，并可以将它重构为不同的设计。
时间杀手打破行为。您可以越接近保留原始应用程序的行为，转换速度就越快。请记住引用传统DLL没有任何问题。 .NET建立在许多API层上，最终深入到Windows继续使用的传统DLL。再一次，如果你有.NET UI工作，那么你就有更多的时间来处理核心并将所有东西都带入.NET。
答案 2 :(得分：1)
我always advise extreme caution在开始重写之前。如果你使用decent tool将VB6升级到.NET，它会自动转换Declare语句，所以不要过分强调它们！
这是一个常见的陷阱，开始乐观地重写一大块软件，在旧架构中修复一些众所周知的缺陷，早日取得良好进展，然后陷入你刚刚采取的功能陷入困境理所当然多年。在这一点上，您的管理层开始变得神秘莫测，一切都会变得非常不舒服。我一直在那里，这没什么好玩的。听起来您的用户已经抽搐，这是一个不好的迹象。
...这是微软的一篇博文agrees with me：
我在.NET早期工作过的许多公司首先考虑的是重写，部分原因是他们在迁移到.NET的同时强烈希望改进底层架构和代码结构。不幸的是，许多项目遇到了困难，有些项目从未完成。他们试图解决的问题太大了
...和一些关于从VB6迁移到.NET的official advice from Microsoft UK
对.NET执行完全重写要花费更多，并且难以做好[转换] ...我们只会针对少数情况推荐这种方法。
也许你的程序很小，而且你对它所解决的问题有很好的理解，你很擅长准确估计并保持你的项目正常，而且一切都会好的。
答案 3 :(得分：1)
如果从VB6迁移到VB.net或C＃，请丢弃C代码并使用适当的ODP.net类或LINQ来访问这些存储过程。由于C层（据我所知）除了暴露存储过程之外没有任何逻辑，因此在切换后它不再有用。通过这样做，您可以（至少）获得更好的异常处理（即完全异常而不是魔术返回代码），可维护性等。
另请参阅：Automatically create C# wrapper classes around stored procedures