移植VB.NET Winforms应用程序到C＃

Question

是否有任何'好'资源将VB.NET winforms应用程序移植到C＃？我确信有软件只是翻译代码，但我希望同时重构代码。保持它当前的形式是有问题的，因为它使用VB.NET允许的一些“糟糕的设计”实践，并且将进一步使未来的维护变得复杂。这里有没有人经历过这个过程，你是怎么做到的？你使用翻译/重构方法了吗？您是否只是使用最终产品来重新创建功能而不查看大部分当前的代码库？你（集体）推荐什么？

更新：

正如我告诉Grauenwolf一样，保持现有语言存在以下问题：

• 无法轻松添加功能。 VB.NET不是一种我坚如磐石的语言。我很欣赏学习语言的讽刺意味 - 但未来的维护将需要考虑那些不懂VB.NET的人。
• 应用程序的其余部分已移植到C＃（事实上很久以前）;我们想要添加的所有功能都取决于解耦应用程序（现在它非常紧密耦合）。我的选择是用一种我不太熟悉的语言重构它，或用我理解的语言重构它。

对于任何投票问题的人，我不确定为什么你做了;关注的不是我是否应该将其留在VB.NET中;关注的是现在没有移植它的未来成本是多少。如果我要花很多钱来修复它，那么为什么不采取额外步骤并使其可以为未来的程序员维护？

作者注意：我多年没有看过这个问题，最近有回复，所以我把'回答'移到了问题中并删除了'答案'（因为它不是真的是一个答案。

Answer 1

根据我使用混合VB和C＃项目的大型应用程序的经验，我建议将其保留在VB.NET中。如果设计有问题，那么修复它们，但将整个事物转换为C＃听起来像是一个混乱，不必要的分心。

两种语言之间的非风格差异非常小，因此很难看到强制转换的功能需求。 （Visual Studio 2003中有一个旧的错误，它排除了某些项目引用链，它们以特定的方式混合了C＃和VB项目，但这是我遇到的唯一一个实际障碍。）

个别开发者肯定倾向于偏爱其中一种风格偏好，但完全转换需要做很多工作才能尝试不同风格的语法糖。

Answer 2

如果你使用像Reflector或Anakrino这样的东西，它的输出是基于IL而不是原始来源。无论它是否产生更好的代码都可以争论......但无论如何你可以尝试一下。 ：）

Answer 3

  

将其保持为当前形式是有问题的，因为它使用了VB.NET允许的一些“不良设计”实践，并且会进一步使未来的维护变得复杂。

你认为C＃不会允许不好的设计吗？

问题不在于VB，问题在于编写它的人和那个拒绝修复它的人。所以退后一步，深呼吸，然后开始修复代码。谁知道，你可能会发现其中一些“糟糕的设计实践”确实很有意义。

Answer 4

在我的工作中，我们使用了developerfusion的翻译器，但没有任何自动化（只需翻译一段代码或类，然后手动将结果粘贴到c＃项目中）。

Reflector是一个很棒的工具，但是在阅读lambda函数时你会发现一些问题。

对于重构，我们尝试过的最佳工具是Refactor Pro。

Answer 5

我已经使用C-Sharpener对我们的某些应用进行了转换，但这远非完美。它转换了大约95％的代码，当我手动修复剩余的5％时，我最终重构了。

Answer 6

我在VB.NET上有两年的经验，但现在我只在日常开发中使用C＃。在我尝试使用VB.Net to C#将我的VB.NET代码转换为C＃之前，我从它和本书中学习过。

Answer 7

哇哇哇！我是最后一个抓住这些东西的人。我在WinForms中有一个非常大的VB.NET代码，并已被分配将其移植到 C＃和 WinForms 。 我有 VB 的知识，但必须完成任务。我使用T elerik在线代码转换器将所有VB业务逻辑转换为C＃。 转换器是一个愚蠢的转换器，我遇到了大约5000个错误，主要是将 [] 与（）混淆，引用参数和线程问题以及什么不是。 编译器（VS 2013）甚至无法找出单个构建中的所有错误。我不得不花了两个月的时间来修复这些错误并一次又一次地构建项目。 我将WinForms UI复制到C＃Winforms UI - 这不是什么大问题，现在我一直在调试这两个代码以查看输出。

我想告诉它现在已经4个月了，我仍然在完成这个项目。 我对这次转变的经历非常痛苦，并不想推荐任何人。