VB.net与C#哪个比较好？技术、性能及发展前景！（高分呀！）

VB6通向VB.NET的路不会容易，但我认为你值得花时间学习这种新语言。同时，我推荐你开始学习OOP风格的编程，在.NET世界的编程中肯定需要。无论你选择哪一种语言，你将发现.NET平台对创建桌面，Internet，intranet和分布式应用是极其好的。
面向对象的编程在.NET世界是不可避免的。你该选择哪一种语言呢？随着VB.NET的推出，微软已经赋予了VB程序员多年来长期要求的所有特性，即一种真正的面向对象的编程语言。你也许听到过VB.NET改动之大甚至你都无法认识的嗡嗡讨论声。确实，他们不得不去掉语言中的一些次要的东西，并且改变一些对象、属性和方法。但这对大多数VB程序员来说不是一个大的负担。事实上，我认为当你开始经常使用后，你会发现它比以前的VB版本更简单、直观。因为对VB.NET将存在着学习曲线，你也许会对C#好奇而想知道是否该放弃VB。
假如你现在是一位VB程序员，特别是有多年的编程经验，你完全不必转到另一种编程语言象C#、Delphi。虽然它们有一些细小的差别，你会发现VB的核心语言仍然是相同的。主要的变化是你在VB.NET中使用的对象、属性和方法。你必须学习这些新东西而不管选择使用哪一种.NET语言。
现在，假如你从古老的DOS岁月就一直使用BASIC，那么你会受到一些打击，因为他们已经去掉了GoSub， While/Wend，Let a=b和其它大量的陈旧命令。但是微软一直在警告你任何地方都不要使用这些非结构化的声明。
VB.NET的优点
VB.NET有着C#不具备的特性。例如，IsDBNull()函数在VB.NET存在，而C#没有。VB.NET有求幂功能并能使用Redim重新分配数组，这些在C#中也不可能。C#对关键词和变量是大小写敏感的，大部分VB程序员不习惯于这点。而这会浪费时间除非你在输入时确实保持了一致。个人来说，我喜欢VB中使用If. . .End If和Do. . .Loop，反对C#中使用curly braces。我发现很难跟踪这些braces。Select Case声明比C#更容易、简洁。在C#中，你必须始终使用break语句来跳出select声明。在VB中，你能用Case 1 to 50；在C#中你必须编写50个单独的case声明来实现此功能。微软创建C#时怀有几个目的。首先，他们需要一个Java的替代品。随着他们和这种语言的持续法庭斗争，以及大多数人认为Java是Sun的产品，微软需要自己的类似Java的语言，并且能很明显看出是他们自己的。另外，微软想要一种新的、干净的语言，没有用户仍然需要维持的任何遗留代码。结局就是一种干净的语言，没有大量的包袱。最愿意使用C#语言的是Java，C和 C++ 开发人员。这些开发人员已经熟悉了语言的结构和大小写敏感。他们也需要对待到.NET的学习曲线，因此他们不会比VB程序员有太多的优势。 C#的优点我无可否认的是一个VB支持者，但是C#确实有一些优点。例如，多行注释的能力，不需要重复注释字符是相当灵活的。C#也能做前和后的自增、自减

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

在C#方面　　作为微软公司最新的一种语言，并且由于它又是Java语言的小翻版，C#引起了广大的关注。　　人们看上去喜欢一种语言仅仅取决于它是最新的，程序开发者们总是喜欢用最新的工具工作。其它的一些选择使用C#的理由更为具体一些。　　领导潮流的东西总是无懈可击的　　“如果我正准备学一门新的语言，我还是应该学C#。”这也许也是你经常听到的言论。那些推理总是这样进行的：“VB6转变到VB.NET变化已经非常大了，以至于它基本上就是一门是新的语言。如果我无论如何打算学习新语言，我想还是学C#吧，因为它是特别为.NET类的库设计的。” 　　这也是我听到过的关于这两方面的最苍白的争论。你也可以同样理直气壮的说，如果我无论如何打算学习新语言,我想还是学VB.NET吧，毕竟它也是一门新的语言。另外，让我们想想为什么VB.NET从其先驱者那里如此激烈地演变到现在的样子：它为了适应.NET类的库而被重新设计了。　　对比管理过的和没有管理过的代码　　“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的人（反之亦然）和那些攀比工资的开发者们一样错了。
在C#方面　　作为微软公司最新的一种语言，并且由于它又是Java语言的小翻版，C#引起了广大的关注。　　人们看上去喜欢一种语言仅仅取决于它是最新的，程序开发者们总是喜欢用最新的工具工作。其它的一些选择使用C#的理由更为具体一些。　　领导潮流的东西总是无懈可击的　　“如果我正准备学一门新的语言，我还是应该学C#。”这也许也是你经常听到的言论。那些推理总是这样进行的：“VB6转变到VB.NET变化已经非常大了，以至于它基本上就是一门是新的语言。如果我无论如何打算学习新语言，我想还是学C#吧，因为它是特别为.NET类的库设计的。” 　　这也是我听到过的关于这两方面的最苍白的争论。你也可以同样理直气壮的说，如果我无论如何打算学习新语言,我想还是学VB.NET吧，毕竟它也是一门新的语言。另外，让我们想想为什么VB.NET从其先驱者那里如此激烈地演变到现在的样子：它为了适应.NET类的库而被重新设计了。　　对比管理过的和没有管理过的代码　　“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的人（反之亦然）和那些攀比工资的开发者们一样错了。
"都很好!"当然这是废话,上手当然是VB.NET快拉，但你要进入编程高手的殿堂那就非C#莫属了!想找到更好的工作,学C#吧!
Vb.net 和C# 都是用来开发asp.net程序的工具，对於工具来说，那个方便使用那个
发展前景：若《集团采购法》真的明确规定政府机关必须用国产的办公软件，并逐步屏弃win操作系统的话, 那么发展前景就不妙了。
我个人看法还是C#好用一些，C#是.NET下的主推编程语言，综合了其它几种语言的优点，实现了简单易用但又功能强大的特点。
如果你有VB基础话用VB.NET会上手比较快,C#也不错
C#前景更好写，而且刚出来，今后的可以提升的地方应该还很多，虽然VB现在也不错，但是今后的发展空间有恐怕不多了。
.NET中语言没有太大区别,都是使用.net framework,选择哪种个人喜好而已.
这世界上没有什么比编程工具更加牵动程序员的心。VC、VB、DELPHI、JAVA……这些耀眼的名字不仅占据了程序员的生活，而且似乎已经成为了某种信仰。可是，伴随着新世纪的脚步，这些信仰又一次遭遇了重大的挑战。微软，这头被法官和黑客们折腾得既疲惫又恼怒的狮子，发誓要保住它头上的王冠，拼尽全力，拿出了看家的本事——.NET战略。作为 .NET的核心开发语言，C# 顺理成章地浮出了水面。程序员们也就不得不做出一个痛苦的选择，跟在谁的后面？要找出答案就不得不作一番比较和预测。笔者作为一个资深的程序员，斗胆在此狂言，权作抛砖引玉。如果抛开一切非技术方面的因素，C# 无疑是这个星球上有史以来最好的编程语言，它几乎集中了所有关于软件开发和软件工程研究的最新成果。面向对象、类型安全、组件技术、自动内存管理、跨平台异常处理、版本控制、代码安全管理……你不可能在另外的一种语言中找到所有这些特性。尽管像很多人注意到的一样，当我罗列上述特性时，总是让人想到JAVA，然而C# 确实走得更远。但现实的情况是，非技术的因素往往更能决定一个产品的未来，尤其在计算机软件的历史上，技术卓越的产品，如OS/2、Mac OS、UNIX等，都败在了Windows那漂亮的脸蛋儿下。而这一次，微软的角色好像从一个赤手空拳的革命者变成了仗势欺人的老地主，如果真是要变天，那C# 这孩子岂不是投错了胎？可能情形并非如此糟糕，毕竟瘦死的骆驼比马大，而且C# 已经提交给了一个标准化组织，一旦成了国际标准，说不准真有哪个手痒的大侠（也有可能是微软自己）给移植到Linux 和别的平台上。那样的话，JAVA可就惨了。因为JAVA的用户主要是网络服务的开发者和嵌入式设备软件的开发者，嵌入式设备软件不是C# 的用武之地，而在网络服务方面，C# 的即时编译和本地代码Cache方案比JAVA虚拟机具有绝对的性能优势。何况C# 一旦成为一个像C++ 一样的公共的标准，软件开发商既可以省去JAVA的许可证费用，也不必担心成为微软的奴隶，那些反微软的人士和主张厂商独立的人士可能也不会有什么意见。这可能正是微软所期待的。如果把C# 和 JAVA 在网络服务领域的争夺比作未来制空权的争夺的话，那么C# 和传统通用快速开发工具——VB、DELPHI等的较量将是地地道道的白刃战。可能最惨的程序员就是VB程序员，在微软，VB就像离任的克林顿，不但失去了所有的光辉，而且乱事缠身。想想吧，VB6写的项目必须用转换工具转换成基于.NET的代码才能在VB7中调入，几乎面目全非。由于VB7遵循为迎合.NET而建立的通用语言规范（CLS），几乎把所有原来只在C++、JAVA等语言中可以运用的特性统统加了进来，只是语法和原来兼容。如果你是第一次在VB7中看到自己的旧VB6项目转换之后的代码，一定要当心你的心脏！所以，努力吧，别告诉我你将就此退休。DELPHI的状况也好不到哪里去，原来的看家本领是做起应用来又快又好，可现在看看最新的VS.NET Beta 1, 你会感到如此熟悉，众多的属性列表、组件……谁让你穷呢，连总设计师都养不住。其实在编程语言中真正的霸主多年来一直是C++，所有的操作系统和绝大多数的商品软件都是用C++作为主要开发语言的。JAVA的程序员绝大多数也是C++的爱好者，PHP的成功里面也有类似C++的语法的功劳。在操作系统、设备驱动程序、视频游戏等领域，C++在很长的时间内仍将占据主要地位，而在数量最大的应用软件的开发上，C# 很可能取代C++的位置。首先，C# 和JAVA一样，简直就是照搬了C++的部分语法，因此，对于数量众多的C++程序员学习起来很容易上手，另外，对于新手来说，比C++要简单一些。其次，Windows是目前占垄断地位的平台，而开发Windows应用，当然微软的声音是不能忽略的。最重要的是，相对于C++，用C# 开发应用软件可以大大缩短开发周期，同时可以利用原来除用户界面代码之外的C++代码。但是，C# 也有弱点。首先，在大量的现有Windows平台上，C# 的程序还不能运行，因为C# 程序需要 .NET运行库作为基础，而 .NET运行库将作为新一代的Windows（Whistler）的一部分发行，或以Service Pack的形式提交给Windows Me 和 Windows 2000用户。所以在近期，C# 会主要在服务器上得到应用。其次，C# 能够使用的组件或库还只有 .NET 运行库等很少的选择，没有丰富的第三方软件库可用，这需要有一个过程，同时各软件开发商的支持也很重要。第三，JAVA的成功因素里有一些是反微软阵营的吹捧，虽然“只写一次，到处运行”只是一句口号，但毕竟已经是一种成熟的技术。而C# 的鼓吹者目前只有名声不佳的微软，且只能运行在Windows上。实际上这两种语言都不是不可替代的，理智的说，对软件开发商而言，什么用的最熟什么就是最好的工具。尤其对C++的使用者，C# 没有带来任何新东西，因为.NET运行库在C++中也可以使用，没有要换的绝对的理由。
　　综上所述，我个人认为，近几年，C# 将不可避免地崛起，在Windows平台上成为主角，而JAVA将在UNIX、Linux等平台上成为霸主，C++ 将继续在系统软件领域大展拳脚。非常有意思的是，这些语言的语法极其接近，因为JAVA和C# 都是由C++发展而来的。其他的开发工具当然还会在
相当长的时间里继续他们的旅程，不过在市场份额上，将不可避免地受到冲击。转载。。
两个一起学吧，两个一起用吧，要想成为.net高手，这个不应该是问题吧？
C#和VB.Net开发应用程序的重点是不一样的，C#更偏重于Web Application和分布式计算系统，VB.Net更偏重于window application。在我看来，还是学用C#更有前途，现在的系统更多的是向BS结构模式转，C#在这方面更胜一筹。
楼上的没说错吧?.NET都是面向WEB应用程序。开发WEB程序的程序员用VB.NET最多了。
只要不学JScript.NET, J#就行了。
VB系列是MS的发妻，C#是MS的新宠。
只要不学JScript.NET, J#就行了。
VB系列是MS的发妻，C#是MS的新宠。
C sharp up,vb字母太多根写英文一样
WantGoWorld(碧海蓝天) 明显的吾人子弟
如果有VB基础，就先通VB.NET
等以后再通C#，
如果是新手，就直接学C#吧。
每个组织迁移到.NET将选择采用哪种.NET语言。微软提供了四种语言：C#, VB.NET, 可管理的C++和 JScript。本文简要的讨论了我们关于这些语言和哪种语言将被使用的看法。简而言之，我们相信C#将占据主要的市场份额；JScript是没有竞争力的；C++将被忽视，VB.NET显现出对市场的准备不足。失败者JScript我们希望JScript在很少用户的基础上结束它的使命。现在很少有关于这方面的资料而且在.NET论坛中也不大有关于JScript的内容。它已经不是主流了。不要在把钱投到这项技术上，放弃它才是最明智的。可管理的C++C++，即使它新的可管理的形式也将渐渐的被忽视。当越来越多的开发者趋向于语法清晰的语言，例如JScript, Java, VB.NET和C#, 使用C++ 的圈子越来越小。另一个C++ 面临的问题是他不能作为一种教学语言。无疑，尽管如此，有经验的C++开发者将继续使用它的能力，模板，多重代码的继承性和决定性的最终确定。其余的人都能轻松的应付。胜利者们在这里确切的说应该是胜利者。因为我们相信C# 是唯一的真正的胜利者。VB.NET处在尚无人支持的境地。C#具有相当的优势大多数专业的软件开发者，即使独立开发微软平台，如今也将采用一些Java语言中的形式。Java相对于C++和VB6较有利。他去处了许多C++ 中的语法特性而没有丝毫降低它的功能（因此C++的开发者转向使用Java是非常容易的）。它在支持面向对象的工具方面要优于VB6。Java以其清晰的面向对象的语法结构和巨大的类库在大多数主流的具有生产性的语言中占据了最高地位。正是由于这个原因，许多擅长面向对象技术的C++ 和 VB 开发者开始向Java转移。C# 为那些原本不支持微软的人转向使用微软的开发工具提供了依据。实际上它和Java是一致的，只不过在它们的不同之处，C# 更显示出了它无可厚非的优越性。此外，它是一种ECMA标准的语言，因此它提供了跨越多平台的潜在能力。严肃的讲，开发者想要微软的最有生产能力和主流的.NET语言，C# 是最明智的选择。VB.NET孤立无助还剩下VB.NET。我们仍旧对微软为什么仅仅使VB.NET成为一个更复杂的C# 而提出疑问。也许这两门语言的历史背景是知道这个转变的关键，但是我们要讨论的是技术方面的问题而不是市场的问题。无疑，VB.NET已经成长到一个新的阶段。它现在已经成为了面向对象俱乐部中快速成长的一员。但是现在谁关心它呢？也许是一群对其不满的人和非面向对象的程序员，但他们将立刻得到它。随着C#的产生，VB.NET看上去更象是个过时的产品，而不是改进。DecHand代码生成器能在VB.NET或C#中生成代码。如果你选择VB.NET选项，你会得到一个文件，它和C#实现同样功能，但却要比C#生成的文件大33% 左右。读某人用VB.NET编写的的代码时，冗长的语句会带来很多麻烦。当我们把这和前面所提到的原因结合起来时，我们只能希望有经验的面向对象的开发者应该喜欢C# 胜过VB.NET。 那么什么样的市场会丢掉VB.NET呢? 目前的市场却使软件公司仅使用VB来作为开发工具,并造就了一大批VB爱好者.不幸的是,说实在话VB.NET并不是为这些人所开发的。从VB6移植只用VB编写程序的工作间可能正期望从VB6更新到VB.NET，而且能象现有的VB升级一样容易。不幸的是，他们可能会遭到严酷的打击。尽管已经有一种工具可以自动完成操作过程，但升级到VB.NET仍然会累人的多。正如我们上面提到的，VB.NET是一种面向对象的语言，而VB6不是。问题在于，如果你不按照面向对象的方式思考，而许多机构也正是这样做的，你就无法体会到VB.NET转换经历的乐趣。因为这不仅仅是一个结构，而是一种范例的转变，而这种转变是很昂贵的。很多组织可能会觉得如果他们想改变思维方式，他们不如改变语言。如果VB.NET被很快淘汰掉，也没什么可惊讶的。过去曾经辉煌而如今孤寂的爱好者最终的市场分割造就了爱好者。对他们而言，VB6是一种可选择的语言。它提供了简单而功能强大的工具来构建简单的应用程序包括GUIs。VB.NET不是这么简单的。正像我们前面说过的那样，它是一种功能强大的面向对象的语言。但对于一般的爱好者来说，他们不想也不需要了解‘-isms’和面向对象领域中的抽象事务。他们只想把一项任务尽快完成，而忽略我们某些专业人士所要求的精细之处。为此，过不了不久这些VB爱好者可能不会再继续使用VB6，或者他们对其不再报有太大的希望了。VB.NET的未来上述注解仅仅是公开发布的.NET BETA版信息的一小部分。当我们看到最终的.NET的产品距离现在还有相当一段长时间，微软会采用它们当中的一些去生产隐藏着VB.NET复杂性的Visual Studio.NET特性的产品。我们只能翘首以待。我们对此不能做什么，只能相信他们能作到，为了发展，让我们给微软以传统的爱护，这样他们就会更加努力的去做。关于运行时间的执行如果你看到这里与你所想的相差甚远，你可能会问“性能怎样？”，当你在决定用哪一种语言来更快的完成一项产品时，这是每一个人所自然而然所要问的。 毫无疑问.NET完全排除了那些标准。为了去理解为什么.NET 语言运行会一样快（或慢），我们需要去看一下编译程序，或正好是两个阶段的编译程序。第一阶段发生在你用Visual Studio按Ctrl-Shift-B键时。在这一点上，执行一个编译，你的语言编译器正在创建中间语言（IL）。第二阶段发生在你运行了应用程序时。第二阶段有时被看作是JIT编译（我们会觉得奇怪，但是我们不能解释）。它为特别使用CPU而使用了IL和产生本土代码。微软对第一阶段编译的IL而产生的代码并不乐观。相反，他们开始扩展他们所有的能力去优选第二阶段IL---本土代码编译。他们这样做是为了使语言的不可知的原因。所有的.NET语言在运行时间的执行上是一样的。关于调试和编译者的支持Visual Studio.NET提供了同样复杂的调试和编译者使用所有语言的工具。当在Managed C++译码时你不会看到更细节的东西，例如，与其他的语言相比。你可以达到你所希望达到的深度。同样，自动完成的方法也适用于其他语言。总结如果你想找到更安全的办法，那就使用C#。我们肯定现在VB.NET的功能如此强大，而且C#更是如此，选择它你不会后悔的，因为我们已经向你清晰地描述了它的生产性能。
C＃
可是那个很难学的
我用vb.net
see.NET and "language of choice"
http://weblogs.asp.net/jlerman/posts/22704.aspx
现在 c#比vb.net要火
以后谁也不知道
说不定来个  c##  也讲不定啊——————————@_@————————
               good  good   study
               day    day     up
__________________^@^_________________