前两篇文章介绍了 .NET Core 程序在 Linux 平台上的两种部署方式。对于服务器程序，使用 .NET Core 的两种部署方式基本上足以满足需求，但是在很多情况下， .NET Core 仍然不是最佳的选择。

如果你想使用 .NET Core SDK，或者使用 .NET Standard，同时又有以下需求之一：

1. 在非 x86/amd64 架构上部署程序，比如部署到 ARM 或者 MIPS 架构
2. 在 Linux 平台上做开发，但部署的目标包含 FreeBSD 等 .NET Core 并未官方支持的平台
3. .NET Core 2.0 仍未支持你所需要的 .NET Framework API，但 mono 却有较好的支持
4. .NET Core 2.0 对你所需要的发行版支持仍然非常差

那么可以考虑使用 .NET Core SDK 完成开发，但是使用 mono runtime 作为最终的应用分发方式。

除此之外，使用 .NET Core SDK 搭配 mono runtime 使用，还能在 Linux 上生成 Windows 的 .NET Framework 程序。

需要注意的是，这种方式虽说是可行且受支持的，但是在官方文档里并没有被提及，只在 GitHub issue 中提到过。可能使用 mono 的 reference assembly 算是一种 hack。 继续阅读 →

前文讲述了如何在 Microsoft 支持的发行版上使用 Self-contained 方式部署 .NET Core Console App。这种部署方式非常简单，但也有不少问题，主要是以下几个方面：

1. Side by side 部署非常浪费空间。
   每个 app 自带完整的运行环境与基础库，大约占空间 50MB。如果是部署自己编写的服务器软件，那么这个开销还可以接受，但实际上 Console App 除了服务器程序，还有可能是分发给最终用户的客户端程序。如果用户使用的每个 .NET Core 程序都是以这种形式分发，会造成不可忽视的空间浪费。
   另外，虽说这种部署方式有着不同 app 之间环境互不干扰的优点，但是实际上在 .NET Core 环境里，这个优点并不明显，因为 .NET Core 的共享安装方式本身就支持 side by side，安装新版 .NET Core 完全不干扰旧版 .NET Core 程序。
2. 只适用于 ABI 稳定，且被 Microsoft 支持的发行版。
   Self-contained 的 .NET Core App 并非像 golang 程序那样静态链接了所有依赖，而是依赖发行版的很多软件包，因此并非随便扔哪个发行版都能直接跑起来。
   比如 .NET Core 1.x 的 binary 直接链接到带版本号的库文件，换一个发行版就有大概率跑不起来；.NET Core 2.0 改为运行时动态载入库，一定程度上解决了这个问题，但在 Arch Linux 等比较激进的发行版上仍然无法正常运行，总有各种大大小小的问题，比如 OpenSSL 缺少 SSLv3 等。
3. runtime 更新不方便
   每个仍然在支持周期内的 .NET Core runtime 都会定期更新， 这些更新通常并不改变功能或兼容性，但可能包含 bug 修复和安全更新。如果采用 Self-contained 部署方式，意味着 runtime 更新要由应用程序维护者来进行，这样不仅会造成重复工作，也有可能造成更新不及时等问题。

本文以 Arch Linux 和 Ubuntu 为例，介绍 shared runtime 部署方式，用于解决这些问题。选择 Ubuntu 是因为其 dotnet 包支持非常完善，而选择 Arch Linux 则是因为有 .NET Core Runtime 与 .NET Core SDK 的 AUR 包，同时它也是典型的简单粗暴的滚动发行版。 继续阅读 →