写给从老平台升级或是刚刚进来的菜菜中有选择恐惧症的童鞋。
个人觉得ms.net的整合思路是一种大胆的创新，整合后的同一平台可以实现跨语言编译，sdk的内容也很丰富，可以用来弥补windows api和类库中的一些问题。但是从1.1开始就是个半成品导致后面3.5以后的版本内部实现有很大的变化，但也只是修补以前的不足，为保持连续性也难有作为。枚举几个设计问题吧：
1. VB.net 和vb就没什么关系，不要想VB6的工程可以顺利升级，准确的说这个vb应该叫.net framework for basic 就是用basic语言描述的.net 框架，目前看老的VB工程师升级到JAVA的比较多，但不是很明显
2. C#.net 就是翻版Java ，IDE中窗口控件的设计分明就是delphi的思路，其中缘由不难想象，当初微软 搞C#的时候就是从这两个阵营中挖的人，VJ因为专利问题没有搞成，把项目组合并到了C#中，所以将很多VJ没有完成的使命也带了进来，但是就是弄的C#定位很模糊，对于Java 开发者C#略复杂，支持的特性比Java多，但是SDK和代码库却不如JAVA的丰富，delphi的开发人员当然不能容忍.net 冗长的类库和环境，以及不给力的执行效率
3. C++ 从VS6.0 。经过2003,2005，VS2008 到VS2010 个人感觉C++的编译器没什么进步，和VC6时代编译的差不多，升级主要为了更新OS的一些头文件，大概crt对多线程的支持更好吧，那个mfc一向不喜欢，而且越来不好用，不久gdi编程将死，这个mfc也不长了，推荐使用std的库和开源的第三方的库，个人推荐boost，使用mfc内置的一些类库，你会明白，性能那是一个差~~
总结了吧，.net framework 的主要问题在于大而全，就是工艺糙了点，刚开始的1.1版本那性能，那bug多的，能急死你，根本不靠谱，运行起来比vb6解释执行还慢，基本vb5水平，可能那时候JIT还不成熟吧；
VJ被抹杀后ms路子有点乱C#和VB的特性太多不是好事情，高级语言的任务是把问题简化，快速实现功能，这把C#和VB弄得再花哨也替代不了C++何苦呢，支持多线程、继承、重载、代理。。。把一切需要指针做的事情都封装起来，即使这样C++的程序员也不会改用C#，反倒是C#和VB的程序员很困惑，太多的特性支持也使得JIT优化的难度加大，有些费力不讨好
- .net framework 1.1 和 2.0 都是半成品 3.5开始才靠谱起来，只是觉得太晚了，如果当初的1.1是3.5这样的，现在的.net 应该已经很不错 ，或许是受vista的拖累吧。。。身不逢时啊；
- .net framework 应该分为核心库和扩展包，这样更好一些，反倒ms在命名空间和版本协同上下了很大的功夫，让人费解；
- .net framework 上集成太多过时的特性和技术，相信随着技术应用的转型，这些都需要做调整以适应发展的要求。
---------------------------------------------
我心中理想的.net framework 包括
C++ （这个不可替代），希望多一些可以跨平台的考虑（windows、linux、mobile os）CPU x86 x64 arm
C# （整合VB VJ VF）致力于中等规模应用开发：布局简洁、代码高效，结构清晰 。易于同其他语言进行整合，不是现在的非托管代码模式
？？ 敏捷模式，用于小型应用、WEB开发和移动开发，需要一种通俗、简单、敏捷的编程语言，更接近于自然语言和自然逻辑，很显然目前go 和RoR 都是这个方向的
- 1楼shu_nt前天 15:07
- C#.NET一直也是在作为桌面开发的主力。至少中小企业是这样，自从delphi陨落之后，桌面开发的便捷就指望这东西了。 说白了就是个做界面的工具，我们公司就是用C\C++写底层DLL，C#负责调用一下。