将VB6应用程序迁移到.NET平台几乎就像重写一样，无论是VB.NET还是C#。您认为将其迁移到Java平台是否需要比.NET平台更多的努力，因为无论如何它都需要重写？请分享您的想法！
VB6应用程序迁移
4
- WinFXGuy
4
团队中有很多Java开发人员，目前正在Java平台上实现一个项目。但是他们有一个遗留的VB6应用程序，希望将其迁移到一些更新的技术上。它使用一些带有宏的VBA和Word模板，但他们希望将其替换为PDF解决方案。 - WinFXGuy
可能是重复问题：http://stackoverflow.com/questions/395/how-do-you-migrate-a-large-app-from-vb6-to-vb-net - Brian Willis
1并不完全是这样！我的问题具体是关于将vb6应用迁移到Java的利弊，而不是.NET。 - WinFXGuy
1@Brian，这不是重复的。每个应用程序都不同，每个开发团队也都不同。这些因素会产生很大的影响。 - MarkJ
8个回答
9
没有冒犯的意思，但是你错了。将代码移植到 .Net 平台通常比重写要容易得多。
这里是Microsoft UK的官方建议：
“完全重写到 .NET 的成本和难度远高于转换...我们只建议在少数情况下采用这种方法。”
来自一位微软顾问的博客文章：
“在 .NET 的早期阶段，我与许多公司合作，他们首先考虑重写，部分原因是强烈希望在转移到 .NET 的同时改进底层架构和代码结构。不幸的是，其中许多项目遇到了困难，有几个项目从未完成。他们试图解决的问题太大了。”
我建议按以下两个步骤进行，按顺序执行。
这里是Microsoft UK的官方建议：
“完全重写到 .NET 的成本和难度远高于转换...我们只建议在少数情况下采用这种方法。”
来自一位微软顾问的博客文章：
“在 .NET 的早期阶段，我与许多公司合作，他们首先考虑重写，部分原因是强烈希望在转移到 .NET 的同时改进底层架构和代码结构。不幸的是，其中许多项目遇到了困难，有几个项目从未完成。他们试图解决的问题太大了。”
我建议按以下两个步骤进行，按顺序执行。
- 记录迁移或重写的原因。它会带来哪些好处？这些好处可能只是为了让开发团队满意-这可能已经足够好了，我不知道。确保你知道，并且你的经理/用户同意。
- 查看Microsoft UK 建议，其中有一个演示视频解释了.Net迁移的5个基本选项。决定哪个是最好的。也许是重写，但要睁大眼睛看清楚。
回答你实际的问题：用.Net还是Java进行完全重写更容易？那 主要取决于你的团队更熟悉哪个。这也有点取决于应用程序是否与COM交互，就像SLaks所说的那样。
- MarkJ
4
你们的标志很漂亮，哈哈哈 :) - SoftwareGeek
@BhejaFry 谢谢，我一段时间以前放置了这个徽标，很高兴它最终得到了赞赏！ - MarkJ
感谢MarkJ。你在上面发布的链接中提到的完全重写的原因对我们的情况来说是非常合理的。但作为一名.NET顾问，我需要说服经理，将其移植到.NET平台而不是Java平台更好。他手头有一些内部Java开发人员，所以他认为这样可以省钱。我仍然需要查看现有的VB6代码，以评估此应用程序的COM依赖性。但是，你确实有很好的观点，就像其他人关于COM依赖性所说的那样。 - WinFXGuy
@WinFXGuy 可能这个组织确实支付其内部 Java 开发人员的工时费用。告诉经理，重写为 Java 需要更多的开发人员工时，而不是转移到 .NET，也就是说，这样做可能会更便宜。他需要决定愿意为 Java 应用程序支付多少额外费用，而不是使用 .Net。最重要的是，他需要确定委托移植/重写的确切原因。对业务有什么好处？ - MarkJ
1
重写VB6应用程序的工作量不仅仅是针对哪种语言的问题。 VB应用程序通常依赖于COM对象和某些VB特定的库方法，这些方法在Java中可能没有等效物 - 但在.NET中可能具有一定的可移植性。
除非您愿意放弃项目的所有依赖项，否则您可能会发现.NET更容易重新编写，特别是如果您需要保留现有应用程序的某些行为，这些行为源自库或其他依赖项。
另一个考虑因素将是您的团队最熟悉的平台 - 如果您拥有大量的Java专业知识，但几乎没有.NET专业知识，那么也许Java是一个不错的选择。
- LBushkin
4
我认为问题远不仅限于COM本身，而是涉及到另一个框架中是否存在等效组件的问题。COM只是组件技术，通常由VB6代码粘合在一起的预打包代码的功能才是更大的问题。不要把组件想象成“依赖项”。这有点像把汽车引擎称作“依赖项”。 - Bob77
@Bob 我认为这就是LBushkin的意思：这些方法/组件是否在Java中有相应的等价物，也就是说它关乎功能。顺便说一句 - 你曾经真正用不同类型的发动机更换过汽车引擎吗？比如汽油->电动或汽油->柴油？当然可能，但我认为相当昂贵。 - MarkJ
@Bob Reimersma：实际上有两个问题需要解决——第一个是代码依赖的（如果有的话）COM组件，以及这些组件的功能。无论使用何种技术，软件组件很少是100%可互换的，如果将其中一个替换为另一个，则可能导致不同的最终用户行为。在进行移植/重写工作的一部分将是确定如果选择不同的平台系统的最终行为将是什么样子。 - LBushkin
@MarkJ 和 LBushkin，也许你们只是比我更清楚地阐述了我的观点。我希望提出建议，即更改组件套件可能会导致您放弃原始程序中最棘手的代码：与这些组件一起工作。 - Bob77
1
有一些工具可用于从VB6迁移到VB .Net，包括集成在Visual Studio中的工具。这个工具将VB6迁移到C#。无论使用哪种工具，您仍需要对工具输出的代码进行大量手动工作，但这可能比完全重写Java要少。
根据您现有应用程序的架构以及代码结构的良好程度，您可能会决定最好完全重新设计和重写它，在这种情况下，.Net和Java之间可能没有太多选择。
- Polyfun
3
1那个工具听起来相当薄弱。请查看 Artinsoft.com 或 VBMigration.com，据我所知，他们拥有领先的迁移工具。他们都声称迁移后的代码需要最少人工操作，肯定比重写要少得多。哦，另外要谨慎重写。https://dev59.com/Bk3Sa4cB1Zd3GeqPxrkx#2815414 - MarkJ
我曾经使用过Netcoole工具和Artinsoft。我同意Netcoole相当弱，但它非常便宜！你需要在输出上做很多手动工作。除了工具之外，Artinsoft还提供了出色的迁移服务--价格更高，但你不必自己进行任何迁移工作。Artinsoft还编写了Visual Studio中提供的升级向导，这是他们主要工具的简化版本。 - Polyfun
但是，如果应用程序使用了大量的第三方COM对象，最好还是坚持使用.NET。 - WinFXGuy
1
在迁移过程中，不仅要减少总体工作量，还要降低迁移后的维护成本，这一点非常重要。TCO受许多因素影响，但所有事情都相等的情况下，我认为.NET工具、社区、框架和C#语言在开发人员生产力、操作可管理性和性能方面比Java更胜一筹——假设你的目标是Windows操作系统。
我认为保持COM易用性也不应该成为决定因素。事实上，我认为将VB6迁移到.NET，但在不必要的情况下保留COM，会破坏进行VB6迁移的一个关键目的：通过转移到一个得到良好支持和可行的平台来降低开发成本和风险。我会告诉你原因：
大多数与VB6一起使用的流行COM库和控件在许多年内没有得到发展；许多小型供应商已经消失了，或者如果他们仍然支持他们的产品，则现在也提供新的和改进的.NET版本。
在迁移后使用旧的COM意味着在调试、构建和部署方面增加了额外的复杂性。此外，请注意，COM组件并不真正“使用” .NET（即它们不使用.NET类型和约定），因此它们与.NET的使用通常会导致编码和设计中的额外复杂性。
仍有一些坚持不变和例外情况，.NET替代品并不总是最佳选择，但通常情况下，迁移团队将能够找到至少一个.NET替代选项来替换所使用的每个COM组件。花时间深思熟虑地评估、选择和升级其中一个选项，在迁移后会获得回报。
您不会想要互操作任何您计划迁移的VB6内容。自己的代码进行互操作将导致更长、更复杂的过渡，并且通常需要回溯和重新工作/重新测试已迁移的代码。显然，这不是最有效和易于理解的升级路径。
免责声明：我为 Great Migrations 工作。
- mark
0
如果应用程序使用COM，将在.Net中重写它比在Java中更容易。否则，将可能更容易移植到.Net。
如需更具体的答案，请提供有关您的应用程序的更多详细信息。
- SLaks
0
你也可以使用Jabaco，它是一个Java字节码编译器，有自己的IDE和与VB6非常相似（几乎相同）的语法。
你可以在以下链接中找到更多信息：
http://www.jabaco.org/
http://www.jabaco.org/board/
- OlimilOops
0
使用迁移工具，例如ArtInSoft，将其迁移到.NET。
- ScaleOvenStove
0
您可以使用内置的VS迁移工具将VB 6应用程序迁移到VB.Net。尝试看看是否有帮助。如果您正在考虑将VB 6迁移到C＃，那么我也建议您遵循ScaleOvenStove用户的建议。
- KZoal
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接