是否有任何原因VB6无法移植到.Net？

Question

我不是在谈论将VB6应用程序移植到.Net（这里已经讨论过很多）。

我只是想知道，如果你可以做IronPython，IronRuby，Phalanger，H＃等，是否有任何技术原因会妨碍创建VB6.Net？

我认为其中会有LOT of money。

更新对于所有的纯粹主义者，我知道VB.Net是“更好”，但是当你有数十万行代码时，这不是一个足够好的论点。 Here是Joel的帖子，这是这个问题灵感的一部分。

Answer 1

从技术上讲，我觉得这很难。而且我认为没有任何需求。

People are investing用于将VB6代码移植到.Net的工具，而不是创建“VB6.Net”。客户需要将他们的VB6代码资产提供给支持的编程平台。就个人而言，我需要很多说服VB6的端口是可靠和支持的。

相反，迁移供应商会处理运行时库等问题。例如VBMigration.COM announced this month他们正在为ADO.Net添加一个包装器。这是一组本机.NET类，其行为与ADODB类似，但在后台使用ADO.Net。如果你可以使.Net仿真这样的VB6运行时行为，就不需要自己移植VB6语言了。

编辑：我刚刚遇到another idea：生成支持多个平台的VB6克隆，例如RealBasic：Windows，Mac，Linux ......可能会有一些需求。你仍然需要说服人们你继续支持这门语言。

Answer 2

1/2是和1/2否。完全100％的工作将是一个相当困难的转换，因为VB6的假设是建立在COM上的。 COM的假设与.NET不同。你真正遇到问题的地方是模拟VB6 IDE。

编写与Vb6兼容的文本编译器要容易得多。记住您可以编写可以使特定VB6特性适应.NET的程序集的技巧。例如一个打印机对象，vb6图形对象。文件访问等等。还有问题格式的问题，你需要一个FRX文件的转换器。您仍然会遇到行为问题，但理论上您可以在VB6支持库中将其最小化。

没有任何事情阻止微软这样做。原始.NET团队的傲慢导致了他们必须“修复”VB6的道路。是的，作为一种语言VB.NET比VB6有很多很酷的功能。但是VB6比QuickBASIC有很多很酷的功能。但是使用VB6，我可以使用QuickBASIC代码并将其转储到VB6中，并且有合理的机会让它工作。特别是对于只有业务逻辑的模块。从VB6到VB.NET不一样。大多数问题是由16位到32位的整数变化引起的。

即使是最小的向后兼容性的损失仍然是一个问题。随着Ruby，Python和其他语言被移植到.NET，原始VB.NET团队所选择的任意性质被暴露出来。

此时的最佳解决方案可能是最小的方法。既然我们有多年的VB.NET经验，那么最有问题的领域是众所周知的。

有些偏离我的头脑

1）引入OPTION INT BASE语句。默认情况下，整数为32位，long为64位。但是，如果使用OPTION INT BASE 16.然后Integer将编译为Int16，而Longs将编译为Int32。这还需要对Intellisense进行一些修改。因此，当它查询元时，在提示中报告了基础的正确类型。理解元数据中的一切都是Int16s和Int32s。

2）拥有强大的打印机，屏幕和vb6图形助手程序集。 Microsoft有3/4实现的Printer Object。 Vb6 Graphis对象埋在那里，可以用.NET反射器提取并单独使用。但是需要做很多适合和完成的工作。

3）有一个选项使用原始VB6关键字使用那些帮助程序集。编译器将它们转换为对辅助程序集的调用。

数据库访问和其他不同领域还有其他问题。通过扩展VB.NET的选项和关键字，可以解决大部分问题。

当然，现在Microsoft Basic社区存在重大差异。如果添加这些选项，则会出现大量静态和投诉。可能如果我是VB.NET管理器，我会将VB.NET编译器分成VB6.NET编译器以最小化这个。这将取决于这些选项是否会影响当前版本的VB.NET。

您可以阅读有关相关问题的更多信息here。

Answer 3

为什么有VB.NET和tools to aid in migration from VB6时会烦恼？这个事实否定了你的金钱论点。当然，它可能技术上可能，但这将是一项艰巨的任务。障碍不是技术性的，而是财务和动机。

Answer 4

几年前我听了一个DotNetRocks podcast with Paul Vick。这是VB6团队中的那个人。 Iirc，他被问到一个类似的问题。他的回答是，它太复杂了，因为多年来的开发VB6（以及之前的vb5,4,3,2,1）代码库已经获得了大量的弊端，这将非常难以移植到一个全新的平台

Answer 5

Visual Basic 4,5和6基于COM。 COM定义了组件（ABI）和对象模型（包括内存管理）之间的二进制接口。

.NET也定义了这些东西，但是以一种根本不同的方式（例如GC而不是引用计数）。

由于VB6以COM的工作方式为基础，因此与“纯.NET”存在潜在的阻抗不匹配，就像您在C ++ / CLI中看到的那样，您必须处理.NET和本机对象并且类型有点不同

请记住，您可以通过COM互操作使用.NET中的VB6组件，反之亦然，因此可以逐步更改。

Answer 6

我猜它绝对可以移植。如果你认为有钱可以用（并且你很可能是正确的），那就去上班吧。 ; - ）

关闭我的头脑，我看不出阻止这种情况的原因，而且我已经使用了VB6和.NET很长一段时间了。另一方面，我没有从中看到很多好处。将VB6与框架的其余部分有意义地集成可能非常困难; VB6简单地缺少许多功能，这使得这比必要的更难。将VB6应用程序移植到.NET环境（通过将VB6移植到.NET）因此没有任何实际好处。此外，新的.NET代码可以与现有的VB6代码连接，反之亦然。

唯一的好处是获得一个现代化的IDE，但这与移植语言完全不同。