随着 .NET Core 3.0版本的正式发布，一系列新特性终于可以使用在实际工程中了。而 .NET Core 3.0 中的一项非常引入注意的功能，就是将应用打包为特定于平台的可执行文件。
在 .NET Core 3.0 以前的版本中，项目选项的生成属性设置为可执行文件，其效果为最终应用会打包为一个app.dll文件。
如果需要运行该应用，需要在终端中输入dotnet app.dll以运行该应用。
全新的 .NET Core 3.0 打包，在项目选项的生成属性设置为可执行文件时，会根据编译平台，自动生成适应于当前操作系统的真·可执行文件。在我的 Mac 电脑上，通过Visual Studio for Mac 集成 IDE 进行生成操作，默认就可以编译成本地可执行的应用程序。
生成的文件夹结构如下
而生成的应用程序，既可以通过双击运行，也可以直接在终端中启动运行。
通过这种形式运行的应用，更接近于原生应用的启动方式，同时极大的简化了应用的启动便捷性。微软为该类型的可执行文件定义为依赖框架的可执行文件 (FDE)。
需要注意的是，通过这种方式生成的可执行文件，仅针对当前操作系统。例如我当前操作系统为 MacOS，则无法生成 Windwos 或者 Linux 操作系统的可执行文件，此时，可以采用两种方式来运行应用程序：
使用传统方式
观察生成文件夹，发现其中仍然包含app.dll文件，因此，我们仍然可以采用在目标操作系统的终端中输入dotnet app.dll的方式来启动应用程序。由此可见，新的打包成可执行文件方式，是在原有基础上针对当前操作系统自动生成了一个应用同名的可执行文件启动器，用该可执行文件可以调用应用的dll文件来实现程序的加载。至于该文件是否是所有应用相同还有待进一步研究。
使用针对运行时编译方式
利用命令行进行项目的编译，可以发布针对给定运行时的应用程序。具体方式：
1 | dotnet build|pubilsh -r|--runtime <RUNTIME_IDENTIFIER> |
其中，
| 参数 | 描述 |
|---|---|
| win-x64 | Windows 64位 |
| win-x86 | Windows 32位 |
| win-arm | Windows 32位ARM版 |
| win-arm64 | Windows 64位ARM版 |
| linux-x64 | CentOS, Debian, Fedora, Ubuntu等发行版Linux系统64位 |
| linux-x86 | CentOS, Debian, Fedora, Ubuntu等发行版Linux系统32位 |
| linux-musl-x64 | Alpine Linux等轻量发行版Linux系统64位 |
| linux-musl-x86 | Alpine Linux等轻量发行版Linux系统32位 |
| linux-arm | ARM版本Linux如树莓派 |
| osx-x64 | MacOS 10.12 Sierra 以上版本64位 |
生成出的文件夹包含全部运行时dll，看起来相当不美观。
为了避免这种尴尬的情况，微软贴心的为我们提供了命令行参数，可以帮助我们将全部文件打包为单一文件，代价就是巨大的可执行文件体积，因为打包会将所有运行时dll都包含在内。在我新建的应用中，一行代码都没有改动，编译出的可执行文件大小为95兆，额…….具体的命令行如下：
1 | dotnet build|pubilsh -r|--runtime <RUNTIME_IDENTIFIER> /p:PublishSingleFile=true |
还可以更进一步，将符号文件一同打包进可执行文件：
1 | dotnet build|pubilsh -r|--runtime <RUNTIME_IDENTIFIER> /p:PublishSingleFile=true /p:IncludeSymbolsInSingleFile=true |
然后可执行文件的体积……就更大了。