创建附带多个第三方DLL的Wix安装程序是否为最佳实践？

你提到的三个依赖中，Microsoft.Bcl.AsyncInterfaces.dll、System.Threading.Tasks.Extensions.dll是微软官方推出的向下兼容补分包，作用是给低版本.NET框架提供高版本新增的异步接口、Task扩展能力；Autofac.dll是第三方开源DI容器组件。确实有方案不需要单独把这些DLL逐个加入WiX安装包配置，具体方案如下：

• 升级目标框架消除系统类依赖
  如果把项目目标框架升级到.NET Core 3.0+/.NET 5+，或是.NET Framework 4.7.2及以上版本，上述两个微软补分包包含的API已经被框架原生内置，不需要再单独分发这两个DLL。注意这个方案只能消除两个系统类依赖，Autofac本身不属于框架组件，没有额外处理的话仍然需要随应用分发。
• 编译时嵌入依赖实现单文件输出
  如果是.NET Core 3.0+项目，可以配置单文件发布参数，编译发布时所有依赖（包括Autofac和系统依赖）会被捆绑到同一个exe可执行文件中，安装目录下不会散落各个DLL文件，也不需要在Product.wxs里逐个维护DLL条目。
  如果是传统.NET Framework项目，可以引入Costura.Fody这类编译时织入包，构建时会自动把所有引用的DLL作为资源嵌入主程序集，运行时自动加载嵌入的依赖，同样不需要单独打包分发各个DLL文件。

• 不要手动维护安装包的DLL列表
  给WiX项目配置自动收集构建输出目录的文件，使用Heat工具自动收集依赖项，避免手动加DLL导致的漏文件、版本号不匹配问题。
• 不随意依赖用户机器上的已有DLL
  除非你明确把对应版本的.NET运行环境、组件可再发行包设为安装前置，在安装流程中做版本校验和自动部署，否则不要默认用户机器上已经存在你需要的DLL——哪怕是微软官方的系统DLL，不同Windows版本、不同已安装软件附带的版本可能存在差异，很容易触发运行时找不到文件、版本不匹配的异常。
• 统一管控依赖版本
  整个解决方案内所有项目对同一个依赖的引用版本要保持一致，在应用配置文件中做好绑定重定向，避免运行时出现版本冲突。如果选择随包分发DLL，要确保打包的DLL版本和你编译测试时用的版本完全一致。
• 按需裁剪依赖
  发布时可以开启未使用程序集裁剪，移除没有被实际调用的依赖文件，缩小安装包体积，注意裁剪后要做完整的功能测试，避免误删动态加载的依赖导致运行时错误。

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