我计划将大型vb6应用程序升级到.net。该项目使用许多第三方组件，例如VSFlexGrid以及水晶报告。它还使用源代码不可用的旧VB6 dll。我的问题是
我欢迎之前完成此任务的人提供任何有用的意见。
答案 0 :(得分：7)
自动转换是比重写更好的选择。这是一个常见的陷阱，开始乐观地重写一个大型软件，在旧架构中修复一些众所周知的缺陷，早日取得良好的进展，然后陷入你多年来一直认为理所当然的功能陷入困境。在这一点上，您的管理层开始变得神秘莫测，一切都会变得非常不舒服。
...这是微软的一篇博文agrees with me：
我在.NET早期工作过的许多公司首先考虑的是重写，部分原因是他们在迁移到.NET的同时强烈希望改进底层架构和代码结构。不幸的是，许多项目遇到了困难，有些项目从未完成。他们试图解决的问题太大了
优秀的Microsoft page建议使用两个第三方迁移工具，而不是（不再是available）内置VB.NET升级向导 - Artinsoft和CodeArchitects {{3} }。我相信他们对常见的第三方控件和DLL有一些支持 - Artinsoft支持VBMigration。值得联系他们的依赖列表。 VBMigration有these，因为这个原因会列出依赖项。同样值得联系原始供应商，希望有一个.NET等价物。
微软页面也说：
对.NET执行完全重写要花费更多，而且难以做好[转换] ...我们只会在少数情况下推荐这种方法。
在Stack Overflow上有比VB.NET开发人员更多的C＃开发人员，所以你可能会得到几个推荐C＃的答案。从历史上看，微软也倾向于在.NET的新部分的代码示例方面更热情地支持C＃等等。但微软现在free tool告诉我们：
[C＃和VB.NET]都是基于Microsoft .NET Framework的一流编程语言，它们同样强大。
因此，您是否想要选择C＃或VB.NET是个人决定。 Artinsoft工具声称它可以将VB6转换为C＃。
我的判断是，该网站并不像我上面写的两个竞争对手那么详细。这可能是不公平的。微软爱尔兰NewCode的一些人关于他们 - 我认为他们的总部设在爱尔兰。显然，该工具将您的VB6转换为DSL，然后转换为VB.NET Winforms，C＃，WPF，Java ......
答案 1 :(得分：3)
升级;即使存在机械工具，这对你来说也不会有太大作用。它不会使它神奇地适合.NET，或者对框架的使用得到很好的使用。在这种情况下，我总是更喜欢重写，但确实存在相关的风险/成本。例如，我的一些同事目前正在重写一些VB6 / ASP / COM + / xslt代码以使用ASP.NET MVC - 大多数“有趣”的代码实际上是业务逻辑，这并不是很难移植（技巧是测试它;-p）。它有助于我们的VB6代码的布局是精细的，允许我们迁移单个切片，而不必一次推动整个批次。
第三方控制将是一个麻烦，听起来像其他dll可能必须逆向工程。不是微不足道的。
C＃和VB.NET之间的选择主要是次要的。两者都有一些小优势，但总体而言，你可以做大多数事情。如果你需要COM互操作，那么VB.NET可能是有用的（无论是对于一切，还是仅用于特定的程序集） - 但是C＃4.0（在VS2010中）将通过新的dynamic打字来插入这个空白而不是PIA改变了。总体而言，我非常更喜欢C＃，但这必须是当地的决定。
答案 2 :(得分：2)
我谈论这个问题here
第一步也是最重要的一步是将现有应用程序作为.NET使用。 VB6特定或依赖于第三方控件的任何东西都可以获得尽可能多的接口。界面将准确显示您使用第三方的内容以及首先采取的行为。首先在VB6中执行此操作，您可以运行单元和集成测试，以确保行为是保留的。这是保留应用程序行为的关键元素。
关于C＃和VB.NET之间的问题。这两种语言在功能上几乎没有什么区别。我在90年代的一个转换项目是将我公司的CAD / CAM应用程序从一个名为Rocky Mountain BASIC的BASIC方言转换为Visual Basic 3.在此之前我们有一些错误的启动，感觉到后来我们证明了它通过切换到另一个BASIC系列语言比转换为完全不同的语言系列（如C语言）更容易保持行为。
在我们的环境中理解我们有很多数学重子程序，数学是与BASIC语言系列保持相关性的少数几个领域之一。所以我的经验不是100％适用于您的情况。
我认为C风格语言的简洁性不利于长期可维护性（数十年）。然而，公平地说，这至多是一个小问题。我在编写和维护用C ++编写的Mercury和Gemini Space Capsule的模拟时，我在两种语言方面都有丰富的经验，除了我公司的VB6 / VB.NET中的CAD / CAM程序之外，还有一些用C＃编写的实用程序。
现在我们的.NET转换专注于VB.NET。我发现自动化工具几乎没用，因为我们是一个沉重的图形导向程序。幸运的是，我们不直接使用VB Graphics调用，而是将所有内容放在canvas界面后面。为了打印兼容性，我们使用VB Power Pack中的打印机兼容性库作为起点。
我们有一个工具，我们运行我们的代码，将所有整数转换为Int16类型，所有long类型转换为Int32加上一些其他常见的转换。然后我们将转换后的类或例程放入我们的.NET库并运行单元测试。将结果与原始VB6代码上运行的相同测试进行比较。
屁股最大的痛苦就是形式。简单的对话框是可以的，但对于更复杂的表格，我们只需要重新实现。我们的表单在我们原始代码的接口后面，所以当它工作时，我们可以直接看到该做什么。
答案 3 :(得分：2)
我建议你“部分重写”你的申请。这种方法的奇特名称是扼杀（http://martinfowler.com/bliki/StranglerApplication.html）。
我的猜测是它是一个数据库应用程序。看看你是否可以通过直接与DB交谈来重写某些功能。不要担心让用户使用两个应用程序。旧的应用程序已经足够让他们要求更新了。
我的另一个猜测是，因为它是VB6，所以它没有非常好的UI / BusinessLogic分离。这就是为什么自动升级不会让你太多。
也许我对你的情况不对。你需要问你能从现有代码中获得多少。购买/阅读Michael Feather的Legacy代码书。
答案 4 :(得分：1)
我已经开始将我公司用VB6编写的应用程序重新编写为VB.NET。 C＃和VB.NET都依赖于.NET框架，并且在任何一个中编译的应用程序之间的差异可以忽略不计。选择您和在项目中工作的其他人使用的语言。使用VB.NET的一个优点（虽然我对此称之为犹豫不决）是您可以使用Visual Studio中的“升级Visual Basic 6代码”功能。转换器修复了一些东西，而且很多东西都没有。如果你想尝试这个，你将不得不清理你的VB6代码：
即使在尽可能清理现有代码之后，转换仍然不是100％。你可以在一个单独的项目中尝试这个，只是为了看看你能得到什么需要重新设计的想法。有时在转换后表单看起来很难看，而对于某些事情，你最终可能会从头开始重做它们。
我们的很多表单都在.NET中不再存在的组合框和列表框中大量使用ItemData属性。 ListViews的工作方式也不同，并且所有绘图函数都不相同。转换为.NET控件时，我转换的应用程序中的某些表单看起来非常糟糕，并且行为方式不同，所以我最终将从头开始重新编写这些表单。我的优点是我可以重新开始那些效率不高的返工流程，但当然这需要花费更多的时间。再加上我还在学习各种.NET库所做的事情......是的，这需要一段时间。
答案 5 :(得分：1)
如前所述，您可以重写应用程序。
另一个解决方案是完全兼容的真正VB6替代方案。我正在一个想成为真正的VB 7：RAD Basic的项目中工作。您可以在现代环境中继续使用VB6代码库。
答案 6 :(得分：0)
你不会喜欢我的回答，但现在就去了。
a）聘请具有丰富建设大型.Net应用程序经验的人来指导项目并教你。
b）从当前应用程序中提取业务需求并冻结它们。
c）庆祝这应该是最简单的绿地应用程序开发项目，因为你有技术经验的人来指导你，你有成熟的工具来构建应用程序，并有一套明确的需求，所以你确切地知道要建造什么。P.S。在这一点上，我不打扰Winforms。我会直接去WPF，你以后会感谢我。
P.P.S语言无关紧要（C＃或VB.Net）。努力将是相同的。
答案 7 :(得分：0)
问题是明确要求提供有关“从VB6.0升级的最佳开发工具”的信息，用于大型复杂的VB6 / COM升级，其次是关于C＃或VB.NET。
完美的“转化”工具可帮助您实现每次升级的两个关键目标
工具在保留功能方面的作用
大型，成熟的遗留系统可以包含数千个代码文件和数百万行代码。完全描述和验证在那么多代码中体现的功能所需的努力是巨大的。事实上，可能会有如此多的功能性工作，一些具有技术头脑的团队最初看不到它。他们花了大部分时间来担心如何利用最新的.NET设计，语言和框架功能，然后才能完全理解保留和验证遗留功能的难度。这就像他们从巨大的功能性鲸鱼的背后捕鱼，同时担心捕捉小技术鱼。
试图通过手动阅读，解释和重新编码来重现大量代码的团队可能会在此过程中失明......所以任何转换工具的一个关键特性是帮助团队阅读，解释和重写他们的代码同时以保留其语义的形式重写它。计算机科学家已经研究了阅读解释和重写源代码超过60年的问题，他们提出的解决方案被称为编译器。有效的代码“转换器”就像编译器一样工作。
VB6是一种高级语言：Microsoft VB6编译器及其运行时隐式地执行了无数的操作：管理类型推断，隐式转换，隐式ref，后期绑定调用，处理空值，goto样式错误处理，设计表单VB6转换器还必须能够识别和存储代码中未明确显示的无数小细节，并且必须能够在.NET中正确表达这些细节。工业强度转换工具将具有功能强大，可扩展的VB6元语言系统，允许用户控制如何识别和解释VB6代码。VB6也可以通过COM轻松扩展。有数百种不同的COM API正在使用中，并不包括通常成为企业系统一部分的所有内部组件。转换器必须能够识别VB6使用的任何COM类或控件，无论是在UI设计中还是在代码中，并使用其他适当的.NET API或互操作来表达它。我所知道的一个工具甚至可以从VB6中的COM使用信息生成.NET代码框架。工业强度转换工具将具有可扩展的强大COM类型系统，并允许用户控制在生成的代码中如何替换COM。
工具在利用.NET方面的作用
VB6和.NET在很多方面都有所不同，支持这两个平台的各种API也是如此。因此，使用或不使用工具，几乎总会需要进行一些重新设计。此外，每个团队为他们的项目带来不同的偏好，约束和要求：询问10个程序如何编写代码，您将获得至少10个不同的答案。转换器必须帮助团队表达其独特的偏好，约束和要求。这包括提供可重复的，自我记录的方法，在处理之前修改VB6代码，在生成后修改.NET代码，集成手工编写的代码，描述自定义API替换，指导自定义代码重构，以及执行许多其他各种动态和项目 - 根据需要进行特定转换。
全部放在一起
很少提前完全预测和计划大型升级。即使对源代码和所需的.NET编码标准有广泛的了解，工作中也会出现许多问题和机会。必须允许在升级项目期间更改源代码和要求。我们需要的是一种允许使用的敏捷方法 团队适应源代码更改，尝试不同的.NET编码技术，响应对需求的更深入理解，并逐步改进自动升级过程。工业强度转换工具将具有准确性，精确性，灵活性和速度，以实现此类方法。
关于转化工具的另外一条评论。您将在.NET升级中使用的最重要的“工具”就是您的大脑。您必须学习.NET语言，设计模式和框架，并在升级工作中应用您所知道的知识。最好的自动化工具不会决定如何重写代码：它可以帮助您根据您认为合理的设计重新实现遗留功能。
Microsoft在本文中提出了几种工具。 VB6 Upgrade Partner Tools
VB.NET或C＃
当我向.NET社区（即搜索网站）询问有关编程问题的信息，工具，想法，代码和帮助时，我更有可能找到用C＃表达的答案而不是VB.NET。我还发现C＃编译器更适合工具辅助重写，因为它要求生成的代码更加内部一致并明确描述。获取和保持构建是对代码质量的一种粗略但绝对关键的测试，并且是任何升级工作中的关键里程碑。请记住，VB.NET不是VB6。这听起来很明显，但很难记住，因为这两种语言看起来很相似。这种相似性可能是骗人的;所以IMO最好去C＃，提醒你规则是不同的。最后，C＃一直是并且将继续为.NET设计; VB.NET不能这么说。
免责声明：我为Great Migrations工作。还有很多事要讨论。请访问Great Migrations Documentation Portal获取更多文章并获取gmStudio试用版并亲自尝试使用工业强度升级工具。