ASP.NET Core 2.2 基础知识(十八) 托管和部署 概述

原文: ASP.NET Core 2.2 基础知识(十八) 托管和部署 概述

为了方便演示,以 .NET Core 控制台应用程序讲解.

咱们新建一个控制台应用程序,安装 "Newtonsoft.Json" Nuget 包,而后右键点击该项目,选择"发布":

 

咱们依次选择"文件",设置好路径,最后点击建立配置文件,界面变成了下面这样:

 

而后咱们点击"配置"

 

那么,问题来了."部署模式" 里面有两个选项:

1.当选择框架依赖时,"目标运行时"有:"可移植","win-x86","win-x64","osx-64","linux-x64" 5个选项.

2.当选择"独立"时,"目标运行时"没有"可移植"这个选项.

咱们到底应该怎么选择?

不要作思想的巨人,行动的矮子!

没事儿走两步!

依赖框架的部署 (FDD) : 框架依赖 + 可移植

 

以这种方法发布后,进入发布的文件夹发现,竟然只有5个文件 !

 

1个应用程序的程序集,1个pdb,2个json,1个第三方依赖项.

咦?怎么没有.EXE 文件?没有 .exe 文件,我怎么运行该项目?(其实,进入到该项目的debug文件夹,你会发现也没有.exe文件)

这样运行:(为了方便,我经过 VS Code 进入该文件夹)

如今,咱们回过头来看官方对这种方式的解释:

依赖框架的部署 (FDD) : 顾名思义,依赖目标系统上存在的共享系统级版本的 .NET Core.因为已存在 .NET Core，所以应用在 .NET Core 安装程序间也是可移植的.应用仅包含其本身的代码和任何位于 .NET Core 库外的第三方依赖项.FDD 包含可经过在命令行中使用 dotnet 实用程序启动的 .dll 文件。 例如，dotnet app.dll 就能够运行一个名为 app 的应用程序.

结合咱们的实际操做,大概就是这几个意思:

1.FDD 只会部署应用程序和第三方依赖项,也就是发布生成的这4个文件: MyConsole.dll ,MyConsole.pdb , 应用程序配置文件 MyConsole.deps.json,以及第三方依赖项 Newtonsoft.json.dll .

2.名字既然叫"依赖框架",那依赖的系统确定必需要有框架才行!也就是说,应用程序将要部署到的目标系统上,必需要有 .NET Core ;

3.应用程序将使用目标系统上存在的 .NET Core 版本.这就是最后一个文件的意义.咱们用记事本打开 MyConsole.runtimeconfig.json ,能够看出,该文件指明了咱们须要依赖的.Net Core 的版本: "2.2.0"

{
  "runtimeOptions": { "tfm": "netcoreapp2.2", "framework": { "name": "Microsoft.NETCore.App", "version": "2.2.0" } } }

FDD 也是 .NET Core 和 ASP.NET Core 应用程序的默认部署模型.该部署方式的优缺点以下:

优势：

• 不须要提早定义 .NET Core 应用将在其上运行的目标操做系统。 由于不管什么操做系统，.NET Core 的可执行文件和库都是用通用的 PE 文件格式，所以，不管什么基础操做系统，.NET Core 均可执行应用。 
  

• 部署包很小。 只需部署应用及其依赖项，而无需部署 .NET Core 自己。

• 除非重写，不然 FDD 将使用目标系统上安装的最新服务运行时。 这容许应用程序使用 .NET Core 运行时的最新修补版本。

• 许多应用均可使用相同的 .NET Core 安装，从而下降了主机系统上磁盘空间和内存使用量。

缺点：

• 只有目标系统上安装的 .NET Core 版本不低于应用程序要求的版本时，应用才能运行。

• 若是不了解未来版本，.NET Core 运行时和库可能发生更改。 在极少数状况下，这可能会更改应用的行为。

官方的这个优缺点已经说得很详细了.其中,我对标红的这句缺点实验了一下,结果分享给你们:

首先,咱们将 MyConsole.runtimeconfig.json 文件中的版本号修改为 "2.3.0":

{
  "runtimeOptions": { "tfm": "netcoreapp2.2", "framework": { "name": "Microsoft.NETCore.App", "version": "2.3.0"  } } }

接着,咱们在命令行中输入 dotnet myconsole.dll 运行该项目:

运行失败!

错误信息大概意思以下:

第1句:没有找到任何能够兼容的 framework 版本.

第2句:没有找到指定的 2.3.0 版本的 framework "Microsoft .NETCore.App" .

最后一句:(该系统)只安装了 2.2.0 版本.

如今 ,咱们将版本号修改为 2.1.0 试试看:

{
  "runtimeOptions": { "tfm": "netcoreapp2.2", "framework": { "name": "Microsoft.NETCore.App", "version": "2.1.0" } } }

正常运行了:

 

又 12点 了.睡了.明天继续

---------------------------------------------------------------------------

2019.1.10

依赖框架的可执行文件 (FDE) : 框架依赖+win-x86/win-x64/osx-64/linux-x64

这是.Net Core 2.2 才开始有的方式.咱们将"目标运行时" 设为 win-x64 ,演示效果,左边是 该方式发布后的文件,右边是用 上述 FDD 方式发布的文件:

 

 

能够看出来,FDE 只比 FDD 多了一个 .exe 文件而已,意义也很明显了.

 

独立部署 (SCD) : 独立+win-x86/win-x64/osx-64/linux-x64

一样,咱们将"目标运行时"设为 win-x64 演示效果:

 

 

只截取了一小部分,实际一共有218个文件.共 66.7MB , 而上面的 FDD,FDE 只有 700KB 左右.

看了实际效果后,咱们回头看看官方对于 SCD 的解释:

对于独立部署，能够部署应用和所需的第三方依赖项以及生成应用所使用的 .NET Core 版本。 建立 SCD 不包括各类平台上的 .NET Core 本机依赖项，所以运行应用前这些依赖项必须已存在。从 NET Core 2.1 SDK（版本 2.1.300）开始，.NET Core 支持修补程序版本前滚。 在建立独立部署时，.NET Core 工具会自动包含你的应用程序所指向的 .NET Core 版本的最新服务的运行时。 （最新服务的运行时包括安全修补程序和其余 bug 修复程序。）服务的运行时不须要存在于你的生成系统上；它会从 NuGet.org 自动下载。有关详细信息，包括有关如何选择退出修补程序版本前滚的说明，请参阅独立部署运行时前滚。

下面是我结合实际效果,对这段解释的理解:

1."能够部署应用和所需的第三方依赖项..." : 实际效果就是这4个文件:MyConsole.dll ,MyConsole.pdb , 应用配置文件 MyConsole.deps.json,以及第三方依赖项 Newtonsoft.json.dll ,同时,因为 SCD 部署的是可执行文件,且选择的是 win-x64,,因此还有 MyConsole.exe 文件.

2."...以及生成应用所使用的 .NET Core 版本.": 除了第一条的5个文件,剩下的文件就全是这句话所实现的了.

3."建立 SCD 不包括各类平台上的 .NET Core 本机依赖项，所以运行应用前这些依赖项必须已存在":不一样系统安装 .NET Core ,确定也须要依赖一些其余东西.而用 SCD 部署时,这些东西是不会生成的,因此,须要确保应用要部署到的系统上已经存在这些.NET Core 所依赖的东西.

4. "运行时前滚。": 这个后面再说.

为何要部署独立部署？

SCD 主要有两个优势：

• 能够对与应用一块儿部署的 .NET Core 版本具备单独的控制权。 只有你才能维护 .NET Core。

• 请放心，目标系统能够运行你的 .NET Core 应用，由于你提供的是应用将在其上运行的 .NET Core 版本。

它也有几个缺点：

• 因为 .NET Core 包含在部署包中，所以必须提早选择为其生成部署包的目标平台。

• 部署包相对较大，由于须要将 .NET Core 和应用及其第三方依赖项包括在内。

  从.NET Core 2.0 开始，能够经过使用 .NET Core 全球化固定模式在 Linux 系统上减小大约 28 MB 的部署大小。 一般，Linux 上的 .NET Core 依赖于 ICU 库来实现全球化支持。 在固定模式下，库不包含在部署中，而且全部区域性的行为均相似于固定区域性。

• 向系统部署大量独立的 .NET Core 应用可能会使用大量磁盘空间，由于每一个应用都会复制 .NET Core 文件。