背景：

这周，心情来潮，想把 Aries 开发框架 和 Taurus 开发框架 给部署到Linux上，于是开始折腾了。

经过重重非人的坑，终于完成了任务：

Aries on CentOS7：mvc.aries.cyqdata.com

Taurus on CentOS7：mvc.taurus.cyqdata.com

不过在发布的过程中，发现有大堆共同的dll（100多个，20多M）：

看见一大堆这些dll，感觉很影响视觉，而且多个项目就要上传多份，很是麻烦。

于是研究了一下，能不能把这些和项目的文件分开，独立到一个指定的目录中去。

研究过程：

为什么要研究，因为网上根本搜不到啊，我X，这.net core 都出这么多年了，就没人有点洁癖，把这事给解决然后写篇文章么！

1、本人机器早期装的是VS2017版本，发布版本时，没有“部署模式”选项。

2、后来升级了一下，发现版本选项里有“部署模式”选项，里面有框架依赖和独立两种，于是看了下相关说明：

.NET Core 应用程序部署

可以为 .NET Core 应用程序创建三种部署：

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

• 独立部署。 与 FDD 不同，独立部署 (SCD) 不依赖目标系统上存在的共享组件。 所有组件（包括 .NET Core 库和 .NET Core 运行时）都包含在应用程序中，并且独立于其他 .NET Core 应用程序。 SCD 包括一个可执行文件（如 Windows 平台上名为 app 的应用程序的 app.exe），它是特定于平台的 .NET Core 主机的重命名版本，还包括一个 .dll 文件（如 app.dll），而它是实际的应用程序。

• 依赖框架的可执行文件。 生成在目标平台上运行的可执行文件。 类似于 FDD，依赖框架的可执行文件 (FDE) 是特定于平台的，而不是自包含的。 这些部署的运行仍依赖于现有的 .NET Core 共享系统级版本。 与 SCD 不同，应用仅包含代码和任何位于 .NET Core 库外的第三方依赖项。FDE 生成在目标平台上运行的可执行文件。

经过研究测试，不管哪种方式，发布后，还是有一大堆Microsoft.XXXX.dll。

然后认真看仔细后发现，FDD部署，也是不处理依赖第三方依赖项的。

你连Microsoft和System打头的都叫第三方依赖项，哥也没办法了。

后来想到配置文件：*.runtimeconfig.json，感觉这里应该能折腾点什么。

{
  "runtimeOptions": {
    "tfm": "netcoreapp2.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "2.0.0"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

百了和runtimeconfig.json相关的文章，发现一篇翻译自老外的文章：

https://www.cnblogs.com/lwqlun/p/9704702.html

按着关键说明，以为找到了春天：

于是在：additionalProbingPaths 这个属性上陷入了不归路，特别是packages这个起名，让我一路以为它和第三方依赖包有关。

结果却不管怎么折腾，都悲催了。

最后只能看原文，然后看源码是怎么加载配置文件的。

配置文件加载的源码：https://github.com/dotnet/core-setup/blob/v2.1.3/src/corehost/cli/fxr/fx_muxer.cpp#L464

结果一堆C++，看的好不头痛，还是暂时放弃了，感觉情绪未到。

休息了一会，又重新把文章给仔细看了一下，开始关注了一下*.deps.json，

毕竟这个文件，默认是不用上传的，所以很自然性的被忽略了。

不过当我把它上传上去的时候，发现它被加载，而且，报错了。

感觉找到了方向：

现在仔细一看，deps应该depends依赖的简写，用于处理依赖包配置的。

解决方案：

 Linux下的web目录是这样的：

于是，把*.deps.json里面 lib/开头的路径，全部给换成 /home/web/package ，然后上传，结果，OK了。

最后的部署目录，就剩下这么干净了：

总结：

虽然最后定位到deps.json可以处理这个事，不过默认产生的deps.json东西有点多，要替换的路径也有点多。

估计再研究一下，应该还可以简化一下这个工作。