.NET5.0 单文件发布打包操作深度剖析

最新推荐文章于 2024-08-17 17:41:27 发布

dotNET跨平台

最新推荐文章于 2024-08-17 17:41:27 发布

阅读量888

点赞数

文章标签： python java 编程语言 linux 大数据

.NET5.0 单文件发布打包操作深度剖析

前言

随着 .NET5.0 Preview 8 的发布，许多新功能正在被社区成员一一探索；这其中就包含了“单文件发布”这个炫酷的功能，实际上，这也是社区一直以来的呼声，从 WinForm 的 msi 开始，我们就希望有这样一个功能，虽然在 docker 时代，单文件发布的功能显得“不那么重要”，但正是从这一点可以看出，.NET 的团队成员一直在致力于实用功能的完善。

在 Java 的世界里，单文件发布一直伴随着他们的成长，War 文件可以直接上传到 Tomcat 上运行，话说我们还是有那么一丢丢的羡慕的，不过凡事有利就有弊，单文件发布对于细分模块的热更新来说，还有有一点点的不方便。

不过瑕不掩瑜，在微服务概念越来越火热的今天，相信单文件发布的功能带给大家更多的是兴奋。

什么是单文件发布

首先，我们要清楚的了解，什么是单文件发布。

官方的目标定义：

.Net 5.0单个文件解决方案应为：

广泛兼容：可以将包含IL程序集，随时运行的程序集，复合程序集，本机二进制文件，配置文件等的应用程序打包为一个可执行文件。
可以直接从打包软件直接运行应用程序的托管组件，而无需提取到磁盘。
可与调试器和工具一起使用。

从上面的目标可以看出，和以往版本最大的不同在于：将所有依赖打包到一个可执行文件中，可直接运行，不影响调试操作。

注意上面的这句话“将所有依赖打包到一个可执行文件中”，而在以往，我们使用 dotnet publish 将应用程序进行发布之后，我们会看到，在 publish 下有许多项目依赖的 dll 文件，在 .NET5.0 到来之后，这些依赖文件可收纳到一个文件中，瞬间让人感受到了清凉。

发布操作指令相关

命令

可选参数

配置文件设置参数

除了可以使用命令行参数的形式，还可以通过配置文件的形式设置发布参数，编辑项目文件，添加配置节点到文件中并保存即可。

关于 RID 说明见：https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

这是截止本文发布前的 RID 版本，不排除 .NET5.0 有新的发布

其它参数

除了上面的三个可选参数，我在查询文档的过程中还发现，官方还提到了其它参数的使用，目前不确定是否有效

还可以通过设置 ExcludeFromSingleFile 元素，该设置将指定某些文件不嵌入单个文件之中。

编写待打包的应用程序

为了更直观的看出正常发布和单文件发布的区别，我们特别准备了一个 Web 应用程序，并对两个程序集进行依赖引用。

准备好项目，编译成功，尝试发布，打开 PowerShel 控制台，分别输入以下命令

linux-x64 和 win-x64 两个目录下，分别有 publish 目录，由于平台的不同，所引用的依赖也不一样，这是我们早就了解过的，我们看看打包前后的区别

以上执行的两条命令语句，会为我们生成 Linux 和 Windows 两个平台的程序包，从上图中可以看出，在打包之前，项目的各种引用依赖都被复制到了发布目录下，这也是我们之前的程序发布方式，在经过打包后，所有依赖文件都被装入了一个可执行文件中，在 Linux 平台下表现为：PreviewWebApplication ，Windows 平台下则为：PreviewWebApplication.exe。从打包效果来看，迁移将变得更加方便了。

运行打包程序

打包后的程序和未打包的发布程序在运行方式上没有太多的差异性，在 Windows 平台上，只需要双击 PreviewWebApplication.exe 就可以运行该打包程序了，本示例创建的是一个 WebApi 的程序，直接访问程序侦听的地址后得到接口返回的结果，如果您创建的是带有 Razor 视图或者携带其它资源文件的，可能无法访问指定的 url。

在程序成功运行起来后，我们发现，打包程序并没有解压缩文件到磁盘，而是直接从包中加载文件到内存中运行；这是巨大的进步，也是和 War 文件根本的区别。

需要注意的是，该 .exe 文件并不能单独复制到别的地方运行，你必须把 .exe 当前目录完整的复制才能运行，这涉及到主机探测的问题，下面我们将会一一提到。

跨平台的打包文件

通过上面的示例我们了解到，打包程序总是为不同的平台生成独立的包程序，这是为什么呢？这里就涉及到一个概念，也就是 Tool Interface Standard (TIS)

Executable and Linking Format(ELF)

Common Object File Format（COFF）于1983年引入，最初使用在 AT&T 的 UNIX 系统上。由于 COFF 的各种局限性，比如：节的最大数量受到限制，节名称，所包含的源文件的长度受到限制，并且符号调试信息无法支持实际的语言。最后，在 System V Release 4 (SVR4) 发布后，AT&T 使用 ELF 替代了 COFF。

工具接口标准委员会援引委员会规范文件的说明：可执行文件和链接格式最初由 UNIX 系统开发和发布实验室（USL）作为应用程序二进制接口（API）的一部分。工具接口标准委员会（TIS）选择将不断发展的 ELF 标准作为便携式对象文件。该标准适用于各种操作系统的 32 位英特尔架构环境的格式。ELF 标准旨在通过向开发人员提供具有一组跨多个操作环境的二进制接口定义。这将减少不同接口实现的数量，从而减少需要重新编写和编译的代码。

ELF 文件结构又分为三种类型，分别是：

Portable Executable (PE)

在 Windows 阵营，微软在此 COFF 标准的基础上，又进行了创新和发展出了 PE 文件标准

PE Format 该规范描述了Windows操作系统家族下的可执行文件（图像）和目标文件的结构。这些文件分别称为可移植可执行（PE）和公用对象文件格式（COFF）文件。

从上面的两种规范中可以看出，LinuX 和 Windows 都有各自的文件格式规范，而这种规范在一定程度上是不兼容的，不论是从文件结构还是解析方式；所以 .NET5.0 中的打包程序必须为不同的平台实现独立的打包器。打包器的实现在 runtime 中的 Microsoft.NET.HostModel 库中。

认识了 ELF 和 PE 文件结构之后，我们就可以对打包器代码进行阅读理解。