移植VB.NET Winforms应用程序到C＃
将VB.NET winforms应用程序移植到C＃有什么“好”的资源吗？ 我确信有软件只是翻译代码，但我希望同时重构代码。 保持它当前的forms是有问题的，因为它使用了VB.NET允许的一些“糟糕的设计”实践，并且会进一步使未来的维护变得复杂。 这里有没有人经历过这个过程，你是怎么做的？ 你使用翻译/重构方法了吗？ 您是否只是使用最终产品来重新创建function而不查看大部分当前的代码库？ 你（集体）推荐什么？
更新 ：
正如我告诉Grauenwolf一样，用当前语言保留它会出现以下问题：
- 无法轻松添加function。 VB.NET不是一种我坚如磐石的语言。我很欣赏学习语言的讽刺意味 – 但未来的维护将需要考虑那些不懂VB.NET的人。
- 应用程序的其余部分已移植到C＃（事实上很久以前）; 我们想要添加的所有function都取决于解耦应用程序（现在它非常紧密耦合）。 我的选择是用一种我不太熟悉的语言重构它，或用我理解的语言重构它。
对于投票问题的任何人，我都不确定你为什么这样做; 关注的不是我是否应该将其留在VB.NET中; 关注的是现在没有移植它的未来成本是多少。 如果我要花费大量精力修复它，为什么不采取额外的步骤并使其可以为未来的程序员维护？
作者注 ：我多年没有看过这个问题，最近有一个回复，所以我把’回答’移到了问题中并删除了’回答’（因为它不是真的答案）。
根据我使用混合VB和C＃项目的大型应用程序的经验，我建议将其保留在VB.NET中。 如果设计有问题，那么修复它们，但将整个事物转换为C＃听起来像是一个混乱，不必要的分心。
两种语言之间的非风格差异非常小，因此很难看到强制转换的function需求。 （Visual Studio 2003中有一个旧的错误，它排除了某些项目引用链，它们以特定的方式混合了C＃和VB项目，但这是我遇到的唯一一个实际障碍。）
个别开发者肯定倾向于偏爱一种或另一种风格偏好，但完全转换是为了尝试不同风格的语法糖而做很多工作。
如果你使用像Reflector或Anakrino这样的东西，它的输出是基于IL而不是原始来源。 无论它是否产生更好的代码都可以争论……但无论如何你可以尝试一下。 🙂
保持它当前的forms是有问题的，因为它使用了VB.NET允许的一些“糟糕的设计”实践，并且会进一步使未来的维护变得复杂。
你认为C＃不会允许糟糕的设计？
问题不是VB，问题是编写它的人和那个拒绝修复它的人。 所以退后一步，深呼吸，然后开始修复代码。 谁知道，你可能会发现其中一些“糟糕的设计实践”确实很有意义。
在我的工作中，我们使用了developerfusion的翻译器，但没有自动化（只需翻译一段代码或类，然后手动将结果粘贴到c＃项目中）。
Reflector是一个很棒的工具，但是在阅读lambda函数时你会发现一些问题。
对于重构，我们尝试过的最好的工具是Refactor Pro 。
我已经使用C-Sharpener对我们的一些应用程序进行转换，但它远非完美。 它转换了大约95％的代码，当我手动修复剩余的5％时，我最终重构了。
我有两年的VB.NET经验，但现在我只在日常开发中使用C＃。 在我尝试使用VB.Net到C＃将我的VB.NET代码转换为C＃之前，我从它和本书中学到了东西。
哇哇！ 我是最后一个抓住这些东西的人。 我在WinForms中有一个非常大的VB.NET代码，并已被分配将其移植到C＃和WinForms 。 我对VB有0知识，但必须完成任务。 我使用T elerik在线代码转换器将所有VB业务逻辑转换为C＃。 转换器是一个愚蠢的转换器，我遇到了大约5000个错误，主要是混淆了[]和（） ，引用参数和线程的问题，以及什么不是。 编译器（VS 2013）甚至无法找出单个构建中的所有错误。 我不得不花了两个月的时间来修复这些错误并一次又一次地构建项目。 我将WinForms UI复制到C＃Winforms UI – 这不是什么大问题，现在我一直在调试这两个代码以查看输出。
我想告诉它现在已经4个月了，我仍在完成这个项目。 我对这次转变的经历非常痛苦，不愿意推荐任何人。