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 文件。
