C# 独立的部署模型

    完整的.NETFramework最常被安装到将运行开发人员创建的程序的计算机或服务器上。这么做的一个好处是，只需要安装框架一次，所有应用程序就可以根据需要引用和使用该框架，从而节省本地存储空间。但是，有可能发生这样一种不期望遇到的场景：所有的应用程序引用相同的框架程序集，但是程序集被意外更新，破坏了一些代码功能。

    对于完整的.NETFrameworic,有两种差别很大的升级类型：并行和就地升级。并行升级代表主版本的变化。例如，安装.NETFramework2.0和.NETFramework4.0可支持基于2.0或4.0版本的程序。当CLR和框架组件发生重要修改或优化时，可能出现这种情形。如果一个程序面向.NET Framework 2.0,但是安装的是.NET Framework 4.0，那么产生影响的风险很小，因为这两个版本是并行安装的。与之相对，就地升级(例如从.NET Framework 4.5升级到.NET Framework 4.6.2)，则可能包含对mscorlib.dll和其他.NET程序集的修改，而当程序 面向.NETFramework 4.x时，是需要运行这些文件的。

    .NET Core通过实现独立性(也称为应用程序本地框架)解决了这个问题。应用程序本地框架的含义是，程序内引用的程序集与模块或可执行文件包含在一起，当部署程序后，程序包含运行时需要的所有程序集(运行库、编译器和引用的框架组件)。程序不再依赖于在机器范围内安装的任何.NET Framework,对机器范围内的.NET Frameworic版本所做的任何并行或就地修改，不会影响.NET Core程序。最后，因为程序集很小、很简洁(如针对云优化)，所以占用的本地存储空间有限。

    这意味着对于开发人员和公司来说，当交付产品后，他们可以确信即使在计算机或服务器上升级框架，程序也仍将继续工作。在过去，当发生破坏性升级后，开发人员和IT支持人员要参加问题升级会议，在危机状态下解决程序无法继续运行的问题。在企业中，这是非常复杂的情形，因为小组、团队和流程要想修改生产环境,

    需要获得许多人的同意和批准。常见的做法是，当开发完成后，代码所有权就转交给支持团队，而这就是问题变得复杂和需要获得批准的根源所在。这些限制使得问题更具挑战性。

    而选择.NET Core作为框架时，这种危机场景将不会发生。相反，升级只在应用程序级别进行，在升级之前，可先进行大量的开发、集成和性能测试。如果升级到新的程序集版本时，在开发周期中发现了问题，开发人员和公司可决定采取什么行动。在开发环境中决定升级代码来支持新版本，或者回滚到升级前能良好工作的版本，要比在生产危机情形下做决定更容易。