Microsoft.VisualBasic命名空间是“真正的.NET”代码吗？
我的开发团队正在准备开始一个新的项目。 自从VB3开始，这家商店就成了“VB商店”，但现在stream行的观点是，我们是“.NET商店”，而C＃是专门为.NET创build的，而VB.NET是一个改进，我们已经决定只向C＃前进。 争论的焦点在于Microsoft.VisualBasic命名空间在新开发中是否具有合法的位置，或者只是为了向后兼容VB6（及更早版本）的代码。 另一个更有趣的问题是，Microsoft.VisualBasic命名空间下的代码是否甚至是.NET代码，如果它真的是旧的VB运行时仔细打包在一个.NET包装，使其实际上是一个COM互操作控制类似于WinForms如何封装非.NET Win32窗口API，但仅暴露.NET API以供使用）。
为了使这更加混乱，我们的开发团队有一位Microsoft咨询服务顾问告诉我们，Microsoft不再支持Visual Basic， 包括Microsoft.VisualBasic命名空间下的VB运行时 。
我正在寻找的是链接 – 最好是无懈可击的微软源代码 – 以某种方式明确地回答这个问题的文档。 我已经在Google上尝试了几种search排列方式，而没有深入到这个问题的底部。
编辑：显然我没有让我的问题清楚。 我不问，如果VB.NET是真正的.NET代码。 我试图确定是否是“下”的Microsoft.VisualBasic命名空间是.NET代码，或者如果是旧的VB6运行时仔细打包和暴露为.NET代码。 有人已经说过，命名空间的9/10只是从.NET的其他地方打包代码; 那另外1/10呢？
Microsoft.VisualBasic.dll <> Microsoft.VisualBasic.Compatibility.dll !!!
（或者，如果您愿意， Microsoft.VisualBasic.dll！= Microsoft.VisualBasic.Compatibility.dll; ）
Microsoft.VisualBasic.Compatibility命名空间专供VB6升级向导使用，在将来的版本中可能会被删除，不应该用于新的开发。
Microsoft.VisualBasic命名空间绝对是100％真正的.Net，完全支持，并且只要.Net在其周围。
一些相关的链接：
- 讨论： Microsoft.VisualBasic是否被弃用？
- 文章： 用VB.NET实现纯.NET开发
- 请参阅此MSDN VBFAQ博客文章上的评论
编辑：添加从这个MSDN文章的官方词汇：
Visual Basic Runtime为全局Visual Basic函数和语言特性（如Len，IsDate和CStr）提供底层实现。 虽然新的Visual Basic运行时提供了与其前辈类似的function， 但完全是在公共语言运行库上执行的托pipe代码（用Visual Basic .NET开发） 。 此外，Visual Basic Runtime是.NET Framework的一部分，所以它绝不是独立的，您的应用程序必须携带或部署。
和
Visual Basic 6.0兼容性库与Visual Basic运行时不同。 将Visual Basic 6.0代码升级到Visual Basic .NET的工具使用Microsoft.VisualBasic.Compatibility命名空间。 这是支持Visual Basic 6function的一个桥梁，它不直接受Visual Basic的.NET实现支持。 与Visual Basic运行时不同，兼容性库不是由所有Visual Basic .NET应用程序隐式引用的 。 当您将Visual Basic 6项目升级到Visual Basic .NET时，升级向导将添加对Microsoft.VisualBasic.Compatibility的引用。
兼容性类不应该用于新的开发 。 Microsoft.VisualBasic.Compatibility命名空间为您的Visual Basic .NET应用程序增加了一层复杂性，并引入了一些可以通过重新编码应用程序部分来消除的最低性能成本。 此外，兼容性命名空间通常包含许多包装COM对象的类，如前所述，依赖于COM对象不如纯粹的托pipe实现最佳。
使用.NETreflection器，并窥探它。 我经常这样做。 Microsoft.VisualBasic命名空间中的10个调用中有9个只是.NET方法的包装。
你的顾问正在做顾问最擅长的事情：炫耀自己的存在，使你的预算更大。 MS不再支持VB6，但是VS 2008有VB .NET的事实应该表明他们将支持VB .NET至less几年。
就我个人而言，我将Microsoft.VisualBasic视为其他.NET类的外观。 我使用它是一个个人项目，我可以比使用BCL类更快，更容易地完成我的工作。 比较好的例子是Microsoft.VisualBasic.Strings.Right与String.Substring。 但是，对于VB命名空间中的许多函数（如Val），在框架的特定于语言的部分中有更强大和更强大的版本。 如果我正在编写工作代码，我不使用VB库。 这使得不熟悉VB的C＃开发人员不会有更难理解我的代码。
像FCL中的一些function一样，一些Microsoft.VisualBasic命名空间代码是用托pipe代码编写的，其中一些代码将调用包装为非托pipe代码。
在vb6运行时肯定没有任何依赖，它肯定不会安装在引擎盖下的vb6运行时。
您应该加载.NET Reflector并查看Microsoft.VisualBasic命名空间中的代码。
如果你想继续使用C＃这个命名空间的function，那么继续这样做，它不会消失。 某些代码可能会被标记为已弃用/过时，但我预计在15年后您仍然可以使用Microsoft.VisualBasicfunction运行相同的应用程序，而不会有任何问题。
更新：以及使用.NETreflection器，您现在可以看到/debugging源Microsoft.VisualBasic命名空间/ Microsoft.VisualBasic.DLL代码：
去抓取框架大量的下载，并仔细阅读代码在你的闲暇时间：
我相信他们都编译到相同的字节码。
这是我的参考： http : //www.codinghorror.com/blog/archives/000128.html
声明“Microsoft不再支持Visual Basic”可能意味着几件事情，因为有几个版本的Visual Basic – VB 1到6，VBA和VB.NET。
“微软不再支持Visual Basic.NET”的说法如果是真的， 那将是大新闻， 但事实并非如此 。 （我检查了谷歌）。 对VB6的支持已经结束，但VB.Net仍然非常活跃，并获得新的function。
VB.Net编译为MSIL字节码，该字节码取决于某些.Net库，具体取决于您使用的.net框架类。 其中一些库不是用纯净的.Net编写的，或者仅仅是Windows API的包装器。 这是必须的，因为那些没有内置到.net中的function（例如线程）必须以受控的方式暴露给它。
C＃的确如此。 运行时并不关心哪个语言生成它执行的MSIL。
微软的目标是使VB.NET和C＃具有不同语法的相同语言。 这是真的。 然而，变化总是像VB9的新的XML文字处理蠕变。 他问的是他们重新实现了所有的旧VB6和以前的function作为.NET托pipe代码。 我的猜测是否定的。
正如OwenP所说，Microsoft.VisualBasic命名空间中的大部分调用只是现有.NETfunction的包装。 那么为什么要创build包装？
当创buildVB.NET时，Microsoft希望开发人员能够将现有的VB6项目导入到.NET中。 这只有在VB.NET函数和方法调用具有匹配的function时才可行。 所以他们创build了Microsoft.VisualBasic命名空间来将VB6function映射到.NETfunction。 （纯粹的猜测，但它是有道理的）
随着.NET进步到新的版本，他们不能删除Microsoft.VisualBasic命名空间 – 许多代码可能仍在使用它。 所以它仍然在那里。
此外，你可以编写VB.Net代码，而不用使用Microsoft.VisualBasic命名空间。 （正如Kev所暗示的，你可以使用C＃中的Microsoft.VisualBasic命名空间。）VB.Net只是一种语言，.NET框架仍然是一样的。
有一堆.NET代码，微软实际上只是包装COMfunction。 我不是一个授权专家，但是你总是可以抓取Reflector，看看这个名字空间，亲眼看看。
我认为开始的一个好地方是Microsoft提供的有关VB.net的MSDN文档
http://msdn.microsoft.com/en-us/library/2x7h1hfk.aspx该链接将是最新的Visual Studio 2008写的关于语言。
VB在CLR下的编译方式与C＃相同，所以我不知道你的顾问来自哪里。
我没有用VB.NET做过多的工作（更多的是用C＃），但据我所知，它们都编译为相同的字节码，因此.NET运行时的解释是相同的，而且它们在function上是等价的，只是语法上的不同而已。
虽然VB.NET在我上次使用它时似乎与VB6有很大的不同。
VB.NET代码不是直接编译为二进制文件。 它像C＃一样被编译为IL （中间语言）。
这意味着无论你在VB.NET中构build什么，它都可以在C＃项目中重用，没有任何问题。
我无法find任何直接相关的问题。 主要原因是VB.NET是一个新的积极开发框架的一部分。 没有计划使这种语言过时。 无论其他顾问在说什么。
据我所知，VB.NET是“真正的.net”代码，就像你说的那样。 有很多不同的语言（C＃，VB.NET，F＃，Cobol.NET等）都可以编译成IL代码。 这个IL代码实际上是由.NET VM运行的，并被解释为机器代码。 您在这两种语言之间交互的对象仍然是相同的底层.NET对象。
例如，在C＃中：
DataTable dt = new DataTable（）;
编译成与VB.NET等价的完全相同的IL代码：
Dim dt as DataTable = new DataTable（）
实际上，在.NETreflection器这样的反编译工具中，直接看IL代码，可以用C＃或VB.NET显示输出，无论哪个更适合。
这也意味着我可以在VB.NET“myVbCode.dll”中编写一个类库，并且直接与C＃“myCSharpCode.dll”中编写的类库兼容。 事实上，这两个DLL将只包含编译的IL代码。
所有这些可能都有一些例外，但从根本上来说，它是如何工作的。
直接回答你的问题是，VB.NET和C＃一样是“真正的.NET代码”。
当然，这两种语言的语法特性都不能直接在其他语言中使用（例如，VB.NET具有一些C＃不支持的语法的XML特性），但在VB中没有什么可以做的。 NET你不能用C＃做，反之亦然，至less据我所知。
我会说，如果你有在VB的经验，那么过渡到VB.NET当然会比C＃的过渡更容易。
