.NET Core部署中你不了解的框架依赖与独立部署

作者：依乐祝
原文地址：https://www.cnblogs.com/yilezhu/p/9703460.html
NET Core项目发布的时候你有没有注意到这两个选项呢？有没有纠结过框架依赖与独立部署到底有什么区别呢？如果有的话那么这篇文章可以参考下！
为什么要写这篇文章呢？因为今天同事问我框架依赖与独立部署到底应该选哪个呢？有什么区别。印象中只知道框架依赖发布后文件比独立部署要小很多，然后就是独立部署不占用net core的共享资源，而框架依赖需要与其他net core程序共享net core的一些资源。感觉很模糊，所以查了下资料整理如下，希望对大家有所帮助。

依赖框架的部署 (FDD)

定义

框架依赖的部署：顾名思义，依赖框架的部署 (FDD) 依赖目标系统上存在共享系统级版本的 .NET Core。由于已存在 .NET Core，因此应用在 .NET Core 安装程序间也是可移植的。应用仅包含其自己的代码和任何位于 .NET Core 库外的第三方依赖项。 FDD 包含可通过在命令行中使用 dotnet 实用程序启动的 .dll 文件。例如，dotnet app.dll 就可以运行一个名为 app 的应用程序。
对于 FDD，仅部署应用程序和第三方依赖项。不需要部署 .NET Core，因为应用将使用目标系统上存在的 .NET Core 版本。这是定目标到 .NET Core 的 .NET Core 和 ASP.NET Core 应用程序的默认部署模型。

优点

不需要提前定义 .NET Core 应用将在其上运行的目标操作系统。因为无论什么操作系统，.NET Core 的可执行文件和库都是用通用的 PE 文件格式，因此，无论什么基础操作系统，.NET Core 都可执行应用。
部署包很小。只需部署应用及其依赖项，而无需部署 .NET Core 本身。
许多应用都可使用相同的 .NET Core 安装，从而降低了主机系统上磁盘空间和内存使用量。
缺点
仅当主机系统上已安装你设为目标的 .NET Core 版本或更高版本时，应用才能运行。
如果不了解将来版本，.NET Core 运行时和库可能发生更改。在极少数情况下，这可能会更改应用的行为。

独立部署 (SCD)

定义

独立部署：与 FDD 不同，独立部署 (SCD) 不依赖目标系统上存在的共享组件。所有组件（包括 .NET Core 库和 .NET Core 运行时）都包含在应用程序中，并且独立于其他 .NET Core 应用程序。 SCD 包括一个可执行文件（如 Windows 平台上名为 app 的应用程序的 app.exe），它是特定于平台的 .NET Core 主机的重命名版本，还包括一个 .dll 文件（如 app.dll），而它是实际的应用程序。
对于独立部署，可以部署应用和所需的第三方依赖项以及生成应用所使用的 .NET Core 版本。创建 SCD 不包括各种平台上的 .NET Core 本机依赖项，因此运行应用前这些依赖项必须已存在。
从 NET Core 2.1 SDK（版本 2.1.300）开始，.NET Core 支持修补程序版本前滚。在创建独立部署时，.NET Core 工具会自动包含你的应用程序所指向的 .NET Core 版本的最新服务的运行时。（最新服务的运行时包括安全修补程序和其他 bug 修复程序。）服务的运行时不需要存在于你的生成系统上；它会从 NuGet.org 自动下载。
FDD 和 SCD 部署使用单独的主机可执行文件，使你可以使用发布者签名为 SCD 签署主机可执行文件。

优点

可以对与应用一起部署的 .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 文件

实例演示 .NET Core 应用的部署发布

上面已经说了，可以将 .NET Core 应用程序部署为依赖框架的部署或独立部署，前者包含应用程序二进制文件，但依赖目标系统上存在的 .NET Core，而后者同时包含应用程序和 .NET Core 二进制文件。

不包含第三方依赖的框架依赖的部署

为项目创建一个目录，并将其设为当前目录
在命令行中，键入 dotnet new console 以创建新的 C# 控制台项目
在编辑器中打开 Program.cs 文件，然后使用下列代码替换自动生成的代码。它会提示用户输入文本，并显示用户输入的个别词。它使用正则表达式 \w+ 来将输入文本中的词分开。

640?wx_fmt=png

运行 dotnet restore（请参阅注释）命令，还原项目中指定的依赖项。
使用 dotnet build命令生成应用程序，或使用 dotnet run命令生成并运行应用程序。
完成程序调试和测试后，使用下列命令创建部署
```
dotnet publish -f netcoreapp2.1 -c Release
```
这将创建一个应用的发行版（而不是调试版）。生成的文件位于名为“publish”的目录中，该目录位于项目的 bin 目录的子目录中。
与应用程序的文件一起，发布过程将发出包含应用调试信息的程序数据库 (.pdb) 文件。该文件主要用于调试异常。可以选择不将其与应用程序的文件一起分布。但是，如果要调试应用的发布版本，则应保存该文件。
可以采用任何喜欢的方式部署完整的应用程序文件集。例如，可以使用简单的 copy 命令将其打包为 Zip 文件，或者使用选择的安装包进行部署。
安装成功后，用户可通过使用 dotnet 命令或提供应用程序文件名（如 dotnet fdd.dll）来执行应用程序。
除应用程序二进制文件外，安装程序还应捆绑共享框架安装程序，或在安装应用程序的过程中将其作为先决条件进行检查。安装共享框架需要管理员/根访问权限。

包含第三方依赖项的依赖框架的部署

要使用一个或多个第三方依赖项来部署依赖框架的部署，需要这些依赖项都可供项目使用。在运行 dotnet restore命令之前，还需执行额外两个步骤：

向 csproj 文件的
部分添加对所需第三方库的引用。以下部分包含 Json.NET 的依赖项（作为第三方库）：

<ItemGroup><PackageReference Include="Newtonsoft.Json" Version="10.0.2" />
</ItemGroup>

如果尚未安装，请下载包含第三方依赖项的 NuGet 包。若要下载该包，请在添加依赖项后执行 dotnet restore命令。因为依赖项在发布时已从本地 NuGet 缓存解析出来，因此它一定适用于你的系统。
请注意，如果依赖框架的部署具有第三方依赖项，则其可移植性只与第三方依赖项相同。例如，如果某个第三方库只支持 macOS，该应用将无法移植到 Windows 系统。当第三方依赖项本身取决于本机代码时，也可能发生此情况。 Kestrel 服务器就是一个很好的示例，它需要 libuv 的本机依赖项。当为具有此类第三方依赖项的应用程序创建 FDD 时，已发布的输出会针对每个本机依赖项支持（存在于 NuGet 包中）的运行时标识符 (RID) 包含一个文件夹。

不包含第三方依赖项的独立部署

部署没有第三方依赖项的独立部署包括创建项目、修改 csproj 文件、生成、测试以及发布应用。一个用 C# 编写的简单示例可说明此过程。该示例演示如何使用命令行中的 dotnet 实用工具创建独立部署。

为项目创建一个目录，并将其设为当前目录。
在命令栏行中，键入 dotnet new console，在该目录中创建新的 C# 控制台项目
在编辑器中打开 Program.cs 文件，然后使用下列代码替换自动生成的代码。它会提示用户输入文本，并显示用户输入的个别词。它使用正则表达式 \w+ 来将输入文本中的词分开。

640?wx_fmt=png

在 csproj 文件（该文件用于定义应用的目标平台）的
部分中创建标记，然后指定每个目标平台的运行时标识符 (RID)。请注意，还需要添加分号来分隔 RID。请查看运行时标识符目录，获取运行时标识符列表。
例如，以下部分表明应用在 64 位 Windows 10 操作系统和 64 位 OS X 10.11 版本的操作系统上运行。

<PropertyGroup><RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers></PropertyGroup>

请注意，元素可能出现在 csproj 文件的任何中。本节后面部分将显示完整的示例 csproj 文件。

运行 dotnet restore命令，还原项目中指定的依赖项。
运行 dotnet restore（请参阅注释）命令，还原项目中指定的依赖项。特别是如果应用面向 Linux，则可以通过利用全球化固定模式来减小部署的总规模。全球化固定模式适用于不具有全局意识且可以使用固定区域性的格式约定、大小写约定以及字符串比较和排序顺序的应用程序。要启用固定模式，右键单击“解决方案资源管理器”中的项目（不是解决方案），然后选择“编辑 SCD.csproj”。然后将以下突出显示的行添加到文件中：

<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><OutputType>Exe</OutputType><TargetFramework>netcoreapp2.1</TargetFramework></PropertyGroup><ItemGroup><RuntimeHostConfigurationOption Include="System.Globalization.Invariant" Value="true" /></ItemGroup> </Project>

在命令行中，使用 dotnet run 生成命令。
调试并测试程序后，为应用的每个目标平台创建要与应用一起部署的文件。
同时对两个目标平台使用 dotnet publish 命令，如下所示：

dotnet publish -c Release -r win10-x64dotnet publish -c Release -r osx.10.11-x64

这将为每个目标平台创建一个应用的发行版（而不是调试版）。生成的文件位于名为“发布”的子目录中，该子目录位于项目的 .\bin\Release\netcoreapp2.1 子目录的子目录中。请注意，每个子目录中都包含完整的启动应用所需的文件集（既有应用文件，也有所有 .NET Core 文件）。

与应用程序的文件一样，发布过程将生成包含应用调试信息的程序数据库 (.pdb) 文件。该文件主要用于调试异常。可以选择不使用应用程序文件打包该文件。但是，如果要调试应用的发布版本，则应保存该文件。
可按照任何喜欢的方式部署已发布的文件。例如，可以使用简单的 copy 命令将其打包为 Zip 文件，或者使用选择的安装包进行部署。
下面是此项目完整的 csproj 文件。

<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><OutputType>Exe</OutputType><TargetFramework>netcoreapp2.1</TargetFramework><RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers></PropertyGroup></Project>

包含第三方依赖项的独立部署

部署包含一个或多个第三方依赖项的独立部署包括添加依赖项。在运行 dotnet restore命令之前，还需执行额外两个步骤：

将对任何第三方库的引用添加到 csproj 文件的
部分。以下部分使用 Json.NET 作为第三方库。

<ItemGroup><PackageReference Include="Newtonsoft.Json" Version="10.0.2" /></ItemGroup>

如果尚未安装，请将包含第三方依赖项的 NuGet 包下载到系统。若要使依赖项对应用适用，请在添加依赖项后执行 dotnet restore命令。因为依赖项在发布时已从本地 NuGet 缓存解析出来，因此它一定适用于你的系统。
下面是此项目的完整 csproj 文件：

<Project Sdk="Microsoft.NET.Sdk"><PropertyGroup><OutputType>Exe</OutputType><TargetFramework>netcoreapp2.1</TargetFramework><RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers></PropertyGroup><ItemGroup><PackageReference Include="Newtonsoft.Json" Version="10.0.2" /></ItemGroup></Project>