为了方便演示,以 .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 文件。
随时随地看视频
