我公司最近批准的项目是用C#编写的，所以我们有很多VB.Net程序员，但是，我们有一些遗留的应用程序开发人员在VB6。我们有一个时间框架，将这些应用程序重写到.Net Web应用程序中。所以，无论他们将要学习新东西。
今天的开发人员之一专门问“为什么我们应该切换到C#？
我回答说，社区很大程度上决定了C#是大约80％的例子在C#中去的方式。我是一个VB.Net程序员，我很兴奋，终于削减了我的牙齿在C#，但是，因为我是这么新，我不知道我可以回答“为什么？题。我的理由更多是因为我想学习它。
所以没有下降到一个VB与C#我真的很好奇，如果有任何资源，我可以发送给这些开发人员镇静自己的神经。
期待您的投入！
我个人认为你正在做出正确的选择。 VB开发人员的第一本能是切换到VB.NET。这听起来完全合理，但在我看来，这是错误的选择。你真的不得不将原因分为两个类别：为什么切换到.NET，为什么切换到C#？
为什么要通过VB6切换到.NET：
>从编程的角度来看，VB6中的多线程技术是可能的，但如果你想使用IDE，几乎是不可能的。
>我不相信你可以在VB6中创建一个64位的本机应用程序。这排除了很多。
>没有对VB6进行新的增强。
> OK，有这么多的原因，我可以想到，我可能只是停在那里。
为什么要切换到C#而不是VB.NET
>开发人员可能会被误解为对VB.NET的熟悉感觉 – 处理资源就像他们在VB6中一样，而不了解完整的概念。一个例子：你经常看到新的转换VB.NET设置对象到Nothing，相信这是一个神奇的方式释放资源。不是这样。
>这是真的，大多数例子现在在C#。更重要的是，Jeff Richter’s book现在只在C#。如果你想了解.NET如何工作，IMO的书几乎是强制性的。
>在.NET中，您会发现您将始终使用lambda表达式，特别是在使用Linq操作时。 IMO VB’s verbosity实际上成为了理解和可读性的障碍，在这里，它只是不在之前的方式：foo.Select(x => x> 50)是，只是几乎任何标准，更流利和可读性比foo .Select(Function(x)x> 50)。它变得更糟，因为表达式更复杂。
>使用VB6的一些最糟糕的做法是不可能的，或者至少在C#中不可用(例如ReDim保存和错误恢复下一步)。
> VB拥有一些语法，这使得它在创建通用CLR库时非常麻烦和混乱。例如，在C#中，您使用带有括号[]的索引器。在VB中，使用括号。这使得子程序的用户很难判断它是一个索引器还是一个函数。如果有人试图在VB外部使用你的库，差别是很重要的，但是VB开发人员可能倾向于创建应该是索引器作为函数的子例程，因为它们看起来类似。
>我没有这方面的任何数据，但如果你正在试图雇用一个好的程序员，最好的一般不会倾向于在一个商店写的VB.NET在C#。他们通常担心，他们的同事将生成的代码可能是不合格的.NET代码，让我们坦率地说 – 有一个对VB.NET开发人员的污名和他们的代码在社区的质量。那里。我说了。让火焰开始燃烧吧…
作为脚注，从我的角度来看，VB.NET是MS的一个真正错过的机会。它应该是一种方式来无缝地将您的旧VB6代码转换为.NET世界 – 从一开始动态调用和高质量的COM互操作。它最终是一个近克隆的C#的功能集与更详细的语法和很少甚至没有向后兼容性。悲伤，真的。它锁了很多组织的.NET很长时间。然后再次，也许它强迫一个“冷火鸡”从过去的干净的突破…