需要特别注意的是，.NET Core不是.NET Framework的升级版，而是一个从头开始开发的全新平台，因此在.NET Framework下开发的程序并不能直接在.NET Core下运行。但是这并不意味着.NET Core和.NET Framework没有任何关系。.NET Core的很多代码都是直接从.NET Framework中迁移或改造过来的，因此.NET Core中的大部分技术、类库都和.NET Framework保持一致，绝大部分类的用法都没有变，这样就保证了.NET Framework开发人员掌握的技术并没有过时。
读者可能知道有一个技术叫作Mono。Mono是一个诞生于开源社区的、跨平台版本的.NET Framework。可以借助于Mono把由ASP.NET开发的网站放到Linux服务器上运行。既然Mono已经可以让.NET Framework跨平台运行了，那么为什么微软还要推倒重来，开发全新的.NET Core呢？
可以从微软官方对ASP.NET Core的定义中一探究竟，微软对ASP.NET Core的官方定义是：ASP.NETCore是一个跨平台的、高性能的开源框架，用来构建基于云且通过互联网连接的应用程序。这里的关键词是“跨平台”和“基于云”。
“基于云”是指程序可以运行在云服务平台上，并且可以和云服务平台的其他产品进行集成。云服务平台的大部分技术都是开放的，而不是绑定某个具体语言的，因此主流的编程语言都能用于“基于云”的开发，用.NET Framework也可以进行“基于云”的开发。但是“可以”不等于“适合”，就像C语言也能用于开发网站后台，但是很少有开发人员用C语言来开发网站后台一样。
为什么.NET Framework不适合用来开发“基于云”的程序呢？因为经典的“基于云”的场景是把程序部署到容器等运行环境中，这些运行环境不是一个完整的操作系统，所以要求运行在其中的应用程序有很好的自治能力并且占用更少的资源。
考虑到.NET Framework具有如下缺点，故其不适合用来开发“基于云”的程序。
（1）.NET Framework属于系统级别安装的程序。操作系统内的所有程序共享一个.NET Framework安装实例，如果一个应用程序需要升级.NET Framework或者为.NET Framework安装补丁，则其他程序也会受影响。
（2）.NET Framework必须安装到操作系统上才能使用，不能和应用程序打包到一起独立部署。
（3）ASP.NET框架和IIS（internet information services，互联网信息服务）[1]深度耦合。在生产环境中，ASP.N ET只能运行在IIS上，而IIS只能运行在Windows上，且不同Windows版本的IIS版本也不同。
（4）ASP.NET消耗的资源比较多。为了兼容旧版程序，ASP.NET在运行的时候有很多不必要的内存和CPU消耗。据估计，ASP.NET程序在运行时占用的内存是它实际需要内存的3倍。再如，在ASP.NET MVC（model-view-controller，模型-视图-控制器模式）中，当用户请求到达IIS后，中间要经过非常多的处理管道，最后才能到达控制器。这些管道大多是硬编码的，即使用不到它们，也无法将它们移除，因此ASP.N ET程序无法最大化地发挥硬件的性能。
（5）.NET Framework诞生的时候是没有云计算的概念的，因此.NET Framework从创立之初其开发人员就没有考虑到程序会运行在云服务环境中，而且对很多.NET Framework组件的设置都要求被放到Windows系统级别，这导致.NET Framework程序无法做到完全自治。
除此之外，.NET Framework还有很多历史包袱问题。在.NET Framework诞生之初，ASP.NET就等同于ASP.NET Web Forms，但是用ASP.NET Web Forms开发的系统不符合新一代项目开发的要求，因此ASP.NET Web Forms早已被淘汰了，它被2009年正式发布的ASP.NET MVC以及更晚出现的ASP.NET Web API（application program interface，应用程序接口）所取代。从微软的定位来说，ASP.NET运行时应该为.NET平台下的所有Web框架提供基础支持，无论是ASP.NET Web Forms，还是ASP.NET MVC、ASP.NET Web API等，都应该是基于ASP.NET运行时的平等关系。但是微软在早期开发ASP.NET运行时的时候，在ASP.NET运行时中有很多专门为ASP.NET Web Forms编写的代码，而这些代码是ASP.NET MVC、ASP.NET Web API所不需要的，但是ASP.NET MVC、ASP.NET Web API也只能带着这些它们不需要的代码去运行，这导致使用ASP.NET开发出来的系统无法最大化地利用硬件资源。
可以看到，.NET Framework已经有很多不满足新一代的软件设计要求的地方了，而且已经背负很重的历史包袱。如果微软强行把.NET Framework进行跨平台移植，那么这个跨平台版本的.NET Framework为了兼容以前Windows版本的.NET Framework，需要做很多兼容性的处理工作，这样它身上背负的历史包袱就会越来越重，也会把.NET Framework的设计缺陷都带过来。这也是Mono在移植.NET Framework到其他平台时所遇到的困难，正因为这些困难，Mono对于.NET Framework的移植一直是不完善的，这种不完善也导致了没有大的商业项目使用Mono构建Web系统。Mono目前的成功应用反而是用来开发跨平台游戏的Unity和开发手机App的Xamarin，因为它们不是Web系统，所以只用到了.NET Framework的核心功能，没有用到历史包袱重的Web模块。
基于以上这些考虑，微软做出了艰难的决定：推倒重来，从头开发.NET Core。这样.NET Core开发团队就可以摆脱历史包袱来开发.NET Core，因此.NET Core有如下优点。
（1）.NET Core采用模块化开发。.NET Core核心只包含很少的文件，所有其他模块都需要单独安装。我们开发的程序用到什么模块，就安装什么模块，这样各个模块都可以单独升级。不同的程序可以选择适合自己版本的组件，不用受系统上安装的其他程序的影响。比如，A程序可以用一个模块的1.5版本，而B程序可以用这个模块的1.8版本，它们不会互相干扰。
（2）.NET Core支持独立部署，也就是说，可以把.NET Core运行时环境和开发的程序打包到一起部署。这样就不需要在服务器上安装.NET Core运行环境，只要把程序复制到服务器上，程序就能运行，这对容器化、无服务器（Serverless）等非常友好。
（3）程序的运行效率更高。.NET Core的所有管道都是可以插拔的，我们可以决定程序需要哪些管道及它们的执行顺序，因此用.NET Core开发出来的程序运行效率更高。
（4）ASP.NET Core程序内置了简单且高效的Web服务器—Kestrel。Kestrel被嵌入ASP.NET Core程序中运行，因此整个ASP.NET Core程序其实就是一个控制台程序。Kestrel可被配置上安全、HTTPS、限流、压缩、缓存等功能，从而成为直接面向终端用户的Web服务器，这样网站运行不依赖于IIS；也可以将其配置成轻量级的Web服务器，而安全、HTTPS、限流、压缩、缓存等功能则由部署在它前面的IIS、Nginx等反向代理服务器完成。
（5）.NET Core更符合如今的软件设计思想。由于.NET Core是重新开发的，因此它可以更好地实现如今的编程理念，比如依赖注入、单元测试等。
虽然.NET Core是从头开发的，但.NET Core更多是对底层的调整，而对于开发人员使用的API，微软则尽力保证.NET Core和.NET Framework的一致性，也就是开发人员在.NET Framework中学到的绝大部分技术都可以迁移到.NET Core中，因此不会浪费开发人员在“.NET Framework时代”的技术投资。