自包含.NET发布中引用非自包含工具项目的问题咨询

X-Y问题 #

需要部署一个ASP.NET应用，由于IoT TLSC环境无法使用winget，且认为微软没有可用于预配脚本的无人值守.NET运行时安装方法（已知CI/CD场景下有dotnet-install-script），因此选择将项目发布为自包含类型。

具体问题 #

发布时触发如下错误：

`Utility.B` is a non self-contained executable. A non self-contained executable cannot be referenced by a self-contained executable.

目前通过将Utility.B也发布为自包含类型，并合并两个发布目录的方法解决了问题，但该方法未在官方文档中被推荐，想了解其中原因。已知Utility.B依赖于主项目，框架和包不存在差异，想知道自己忽略了什么。

官方不推荐合并自包含发布目录的原因 #

• 冗余浪费资源：每个自包含应用都会打包完整的.NET运行时及依赖组件，合并后两个包中的重复文件会占用额外磁盘空间，对于资源有限的IoT设备来说，这种冗余会加剧存储压力。
• 版本冲突隐患：即便当前主项目与Utility.B的框架和依赖版本一致，后续任一项目单独更新版本时，合并目录会导致不同版本的组件共存，极易引发运行时异常，且排查难度高。
• 维护成本升高：手动合并目录没有官方工具支持，无法标准化，在批量部署或CI/CD流程中容易出现遗漏、文件覆盖错误，增加维护复杂度。

你忽略的关键要点 #

• 组件定位错误：Utility.B作为被主项目引用的依赖，更适合以**类库（Class Library）**形式发布，而非独立可执行文件。将其改为类库项目后，主项目自包含发布时可直接引用编译后的dll，不会触发兼容性报错，这才是符合官方设计逻辑的用法。
• 存在可行的无人值守安装方案：除dotnet-install-script外，还可使用.NET运行时的离线安装包实现无人值守部署：
  • Windows环境：下载对应版本的exe/msi安装包，通过静默参数执行安装，例如：dotnet-runtime-xxx-win-x64.exe /quiet /norestart
  • Linux环境：下载二进制压缩包，解压后配置环境变量即可完成部署，全程可通过脚本自动化执行，无需依赖winget。

内容的提问来源于stack exchange，提问作者Jeroen3