CLR的各方面简直是无可挑剔的。但可能正是因为CLR太好了，让微软从2003年开始，对unmamanged world的投资就不大了。

　　为了争取企业客户，全力推广CLR是最正确的做法。毕竟绝大多数的程序员，一辈子都是和数据库，和UI代码打交道。你总不能让他们一辈子都用C去管理内容，创建窗口句柄吧。CLR的性能也很有竞争力，与之对应的编程语言和开发工具也非常给力，每个新版本都带来长足进步。但是，这些再好，也无法掩饰一个悖论: 要用C#写出性能可以和C++一个数量级的程序，不是不可能，而是花费的代价往往比直接用C++写更大。这里面有很多原因，比如系统最底层的API还是unmanaged的，通过CLR作interop的性能损失无法忽略。比如用C#的话，程序员的控制力很弱，从工具和语言层面上很难对性能精雕细作，一不注意就box/unbox了。比如JIT编译器为了实现自己的安全模型和异常处理，每次访问成员函数的都是都要生成代码确认this指针是否为空。这个世界上还是有很多程序，是需要对性能做严格控制的。在CLR高速发展的几年中，对应的系统平台，Win32 API, C++开发工具，只有完善性的改善，并没有重大突破。这个问题对Windows平台本身影响不大，但如果寄希望于在移动设备上，大家都指着C#来开发，就有点天方夜谭了。这样的失衡，使得微软在移动设备和消费者产品这两个严重需要unmanaged和系统投入的领域缓慢发展了很长时间。

unmanaged 非托管的

interop　　Visual Studio .NET 通过引入面向CLR(Common Language Runtime 通用语言运行时)的托管代码概念，使开发人员在创建和运行应用程序的方式上有了重大改变。托管代码提供了包括自动内存管理、基于属性的编程和公共类型系统等在内的许多优点。不幸的是，正是这些功能强大、独树一帜的特性也使得它与以往基于 Windows API 和 COM 对象的编程有了本质区别。虽然 Visual Studio .NET 也在尽力使得使用和创建非托管代码容易一些，但有些情况下使用非托管代码是很困难的。 让受管代码对象和非受管对象协同工作的过程称为互用性(interoperability)，通常简称为 interop。