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

概述原文: ASP.Net Core on Linux (CentOS7) 共享第三方依赖库部署 背景： 这周，心情来潮，想把 Aries 开发框架 和 Taurus 开发框架 给部署到Linux上，于是开始折腾了。 经过重重非人的坑，终于完成了任务： Aries on CentOS7：mvc.aries.cyqdata.com Taurus on CentOS7：mvc.taurus.cyqdata 原文: ASP.Net Core on Linux (CentOS7) 共享第三方依赖库部署

背景：

这周，心情来潮，想把 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东西有点多，要替换的路径也有点多。

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

总结

以上是内存溢出为你收集整理的ASP.Net Core on Linux (CentOS7) 共享第三方依赖库部署全部内容，希望文章能够帮你解决ASP.Net Core on Linux (CentOS7) 共享第三方依赖库部署所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。