.NET类库使用Google.Cloud.Firestore如何降低额外依赖开销

.NET Standard类库默认构建不复制依赖DLL到输出目录是平台的设计行为，并非配置错误。类库本身仅负责声明依赖关系，依赖的解析、复制逻辑默认由最终引用该类库的可执行入口项目（控制台应用、Web服务、桌面应用等）统一处理，不需要类库自身携带所有依赖。

方案1：保持类库默认构建设置，由消费项目统一管理依赖（推荐） #

完全不需要在类库项目中开启CopyLocalLockFileAssemblies配置：

• 编译生成的类库DLL已经写入了Google.Cloud.Firestore的依赖引用元数据，只要最终使用该类库的可执行项目通过NuGet安装对应版本的Google.Cloud.Firestore，构建时会自动把所有相关依赖复制到入口项目的输出目录，不会出现运行时找不到程序集的问题。
• 如果类库是以NuGet包形式分发，只要在包配置中正确声明Google.Cloud.Firestore的依赖项，用户安装类库包时会自动拉取对应的Firestore依赖，无需额外操作。

如果是直接拷贝类库DLL给其他项目引用的场景，只需要在消费项目中单独安装一次Google.Cloud.Firestore包即可，不需要改动类库的任何构建设置。

方案2：嵌入依赖生成单文件DLL（适用于强制单文件分发类库的场景） #

如果要求类库输出仅包含单个DLL、不需要消费方额外安装Firestore依赖，可以通过构建时嵌入依赖的方式实现，不会生成零散的依赖文件：

1. 在类库项目中安装Costura.Fody NuGet包
2. 保持CopyLocalLockFileAssemblies为默认关闭状态，正常执行构建
3. 构建输出的主DLL会自动将Google.Cloud.Firestore及所有相关依赖作为压缩资源嵌入内部，运行时会自动加载嵌入的程序集，不需要额外的DLL文件

• 注意事项：
  • 使用该方案前需要确认你符合Google.Cloud相关组件的许可证要求，拥有二次打包分发这些程序集的权限
  • 如果消费方项目本身也引用了其他版本的Google.Cloud.Firestore，可能出现程序集版本冲突，这类场景优先选择方案1

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