在过去的半年里，大家都在探讨VB.NET 它和c#的区别，在这里我和大家简单的谈谈关于VB.NET C#区别。
VB.NET C#区别：
对比管理过的和没有管理过的代码
“C#允许我写那些运行在CLS存储器控制之外的非管理代码，我可以直接访问存储器，并且使用指针。让代码自由地运行，包括使用存储器的管理，可以得到更高的效益。”这个观点有3个问题需要考虑：首先，我们不应该在Beta版本的开发环境下讨论性能问题。举个例子：在.NET的Beta1和Beta2版本之间有显著的管理代码运行速度的改善。第二，我们还不能把非管理代码比管理代码能获取多少利益量化，并且是否值得为了这些好处冒险。可以去看看Eric Gunnerson在MSDN上的这篇文章。第三，尽管VB.NET不能建立非管理代码，它能通过System.Runtime.InteropServices 名字空间的使用，来访问并工作于非管理存储器。
C#有内置的XML文件编制器
“C#编译器包括直接被嵌入成为源代码的XML文件编制器在内。如果我使用C#，我同时编写了代码并编制了文件。”使用过JavaDoc的人都知道，把你的文件编制加到你的源代码中是多么的有用。源代码和文件编制可以同时更新，因此至少在理论上讲，你的文档永远都不会过时。不过，以我的经验来看，相对少数的Java开发者还是在使用JavaDoc。这样，问题就变成“你将使用它吗？”如果你的对这问题的解答是“是”，你有足够的理由试试C#。
关于VB.NET又怎么样呢？
在很多真正的开发者看来，VB像玩具语言似的，从某种角度看，也确实是这样的。迄今为止，VB远比我们所知道的那两三个弱点更多。不过VB.NET确实是和C#同样强大的.NET开发语言。有些人说它更强大。
VB.NET有内置的（插入特点）支持；而C#没有 ，“VB.NET内置了很多东西像字符串操作(Mid, InStr, 等等)和类型转换（例如CInt）。C#缺乏这些内置的支持，所以，我所需要的东西，在C#中很难找到。如果你抓住这些你应该Mid 或者 CInt功能不放，而最终认为这就是VB.NET强于C#的证据，你最好去看看Microsoft.VisualBasic namespace。你将在那里发现大部分VB.NET内部命令和应用功能。这些功能在namespace中被保存之后，任何CLS兼容的语言都能使用他们，就像列表A中所显示的那样。这些例子削弱了我们的争论，不是吗？
更好捆绑的支持就是不支持
“VB.NET与COM实体的捆绑支持更好一些。”我也只是看到了一点点而已，并且我决定再也不在支持方面作任何推理。从我迄今为止所观察到的，这不是真的。C#和VB.NET必须采用runtime callable的包装以及等量的源代码来执行一个早期的实体。同样地，执行一个晚期的实体也需要相同数量的代码。
VB.NET使用IDE中的后台编译
如果你不能找到其他的认为VB的开发环境好的例子，你至少不得不承认它的源代码编辑是很有特点的。你能一边打字一边字面上排除你的代码的错误。麻烦就是那些很弱智的编译错误信息框总是弹出来，并且如果你把你的喇叭声音开得过大的话，报错的嘀嘀声也许会吓到你。Visual Studio.NET避免了这种惊吓，直到你修改完成，并且处理了一些消极的错误，提示系统经过了微软的改进：他会在那些错误语句的下面打上弯弯曲曲的下划线。
VB.NET背景编译程序/句法检验器非常复杂，而且很客气地指出你的错误。从某些方面看，它能更准确地告诉你如何修改你源代码中的错误。当C#有它自己的语法检查器，并且可以查出括弧的匹配，计算圆括弧的多少，显示丢失的分号，但是它还是不能像VB.NET那样使用简单。再继续讨论这两种语言的优越性确实会让我心烦的，不过微软的话确实是一个真理，那就是所有的.NET语言都是平等建立的。那些主张C#优于VB.NET的人（反之亦然）和那些攀比工资的开发者们一样错了。
我要强调的是，那些有远见的技术公司不再会去寻找具有某种开发语言经验的程序员，而是去寻找那些有.NET类库开发经验的程序员。因此我劝你不要过分的担心自己的选择到底是什么：随便找一个你觉得有兴趣学的语言，认真地学好他的框架结构就行了，上边就是简单的分析VB.NET C#区别，希望大家选择自己喜欢的语言。
【编辑推荐】
