VB6风险和迁移

我想知道是否有人可以帮助我。我的公司正在决定将用VB6编写的现有应用程序迁移到.Net。我提出了一份关于让VB6帮助他们决定切换到.net的风险列表。各地VB6风险包括以下内容：VB6风险和迁移

功能性降低
安全风险
成绩滞后
用户界面问题
有限的技术支持
不兼容的问题

至于我已被要求扩展安全性在这。该应用程序是内部的，不会暴露给客户。考虑到这一点，它将处于公司安全基础架构的后面，这将减少安全问题。也有从我还没有考虑

感谢

来源

2017-05-11 chrisblue13

你的意思是什么？你是否假设一个NET应用会比旧的VB6应用少*功能？为什么？同样的一些其他问题 – Plutonix

编辑我的问题 – chrisblue13

添加 - 人员配置vb6开发人员 – djv

与保持VB6应用程序的主要风险是未来的可维护性上面除了更多的风险。 VB6运行时不会在任何地方，所以任何VB6应用程序都应该继续运行。然而，VB6 IDE在XP之后的任何操作系统中都越来越薄，需要一些黑客才能正常安装和运行。此外，寻找技术熟练的开发人员将会越来越难，愿意从事这种过时技术的人员越来越少。

很多很多事情都可以在.Net中轻松完成，这是VB6的一大难题。潜在的收益是值得的短期痛苦恕我直言。

（目前正在将我公司的核心VB6应用程序到.NET）

来源

2017-05-11 15:32:40 Slugsie

支出努力端口应用到.NET并没有做出很大的意义。将这些工作转移到Java或B4J之类的东西可能会更好或更好。那么至少你有可移植性，这是Windows或.Net（或两者）消失时的一个重要问题。

在此之前，VB6提供了无与伦比的稳定性，支持由于工具链流失导致的成本几乎不存在。转向任何其他开发工具都会牺牲那些意想不到的但有价值的功能。有人称之为诅咒已经成为一种福音。这与Cobol仍然在生产中的原因是一样的。

即使Windows ARM64也能够运行VB6 x86程序。我没有看到VB6支持死亡，直到Windows本身死亡。

开发美元将花费在清理代码库上好得多，而不是为了移植的缘故而浪费在移植上的努力。

来源

2017-05-12 04:31:47 Bob77

Re“花费精力将应用程序移植到.Net并没有什么意义。“ - 实际上它经常这样做，因为大部分移植都可以自动完成;较老的VS（2008）可以将VB6项目迁移到WinForms.NET领域。可移植性对我们来说甚至不是可选的 - 我们依赖于许多第三方的win组件，而桌面上的Java并不可用;） – Arvo

以我的经验，旧版Visual Studio版本中的转换工具没有足够的价值。除非这个计划很微不足道，否则他们没有太大的帮助。即使他们工作，你现在只是提高了支持应用程序的成本，因为.Net流失。 – Bob77

在这里，我们用MS转换工具转换了我们的项目树（60多个项目）;当然它没有做出出色的工作（我们不得不解决任何小问题，花了一个月的时间）;但如果没有这个工具，我们可能会花一两年重写所有的代码。而且，与.NET相比，我们对.NET的麻烦更少，尤其是在更新的窗口上。 – Arvo

VB6风险和迁移

回答

相关问题