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