ASP.Net Core on Linux (CentOS7) 共享第三方依赖库部署

背景:

这周,心情来潮,想把 Aries 开发框架 和 Taurus 开发框架 给部署到Linux上,因而开始折腾了。html

通过重重非人的坑,终于完成了任务:git

Aries on CentOS7:mvc.aries.cyqdata.comgithub

Taurus on CentOS7:mvc.taurus.cyqdata.comweb

不过在发布的过程当中,发现有大堆共同的dll(100多个,20多M):json

看见一大堆这些dll,感受很影响视觉,并且多个项目就要上传多份,非常麻烦。mvc

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

研究过程:

为何要研究,由于网上根本搜不到啊,我X,这.net core 都出这么多年了,就没人有点洁癖,把这事给解决而后写篇文章么!框架

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

二、后来升级了一下,发现版本选项里有“部署模式”选项,里面有框架依赖和独立两种,因而看了下相关说明:spa

.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东西有点多,要替换的路径也有点多。

估计再研究一下,应该还能够简化一下这个工做。

补充说明:*.runtimeconfig.json里的additionalProbingPaths,这个属性也要加,不加会提示找不到文件。

相关文章
相关标签/搜索