.NET Framework（packages.config）的OpenTelemetry依赖处理与GAC适用问题

1. 下游项目是否需要单独添加NuGet包？ #

需要。因为packages.config是项目级的依赖管理机制，完全没有依赖传递能力——核心库自己引用的NuGet包，不会自动同步到引用它的下游项目里。

如果下游项目只是调用核心库封装好的方法，没直接用到依赖包的类型（比如没直接写Newtonsoft.Json.JObject或者OpenTelemetry的API），可能编译时不会立刻报错，但运行时大概率会出现“找不到程序集”的异常；要是下游项目直接用到了这些依赖的类型，编译阶段就会失败。所以稳妥起见，下游项目必须在自己的packages.config里添加所有需要的NuGet包引用。

2. 避免重复添加包引用的推荐模式 #

优先迁移到PackageReference #

这是最彻底的解决方案。从.NET Framework 4.7.2开始，官方就支持PackageReference替代packages.config，它原生支持依赖传递——核心库引用的NuGet包会自动传递给下游项目，不用每个项目都手动添加相同的引用。而且PackageReference还支持集中包管理、版本锁定等更灵活的功能，维护起来省心很多。

打包核心库为内部NuGet包 #

把你的内部核心库打包成NuGet包，在.nuspec文件里声明所有依赖项（比如OpenTelemetry、Newtonsoft.Json等）。这样下游项目安装这个核心库NuGet包时，NuGet会自动下载并安装所有依赖的包，不管是用packages.config还是PackageReference都能生效。

批量操作减少重复劳动（针对packages.config） #

如果暂时没法迁移到PackageReference，可以用NuGet包管理器的“管理解决方案的NuGet包”功能，一次性给多个项目添加相同的包引用；或者用NuGet控制台的批量安装命令，比如：

Install-Package Newtonsoft.Json -ProjectName ProjectA,ProjectB,ProjectC

另外，也可以创建一个共享的MSBuild.targets文件，把公共的包引用逻辑写进去，让所有项目导入这个文件。不过这种方式对packages.config的支持不如PackageReference顺畅，仅作为临时过渡方案。

3. GAC是否适合作为共享依赖方案？ #

非常不建议使用GAC，理由如下：

• 版本冲突风险极高：GAC里同一程序集只能存一个版本，如果不同项目依赖不同版本的库，必然会出现运行时错误。
• 部署成本高：安装到GAC需要管理员权限，CI/CD流程很难自动化，生产环境部署也很麻烦。
• 调试与维护困难：本地开发时，很容易和GAC里的全局版本混淆，切换版本、回滚操作都极不方便。
• 脱离NuGet生态：没法利用NuGet的依赖解析、版本管理、自动更新等功能，完全靠人工维护，出错概率大。
• 不适合频繁更新的库：像OpenTelemetry、Microsoft.Extensions这类迭代快的库，用GAC会导致版本滞后，更新起来非常繁琐。

内容的提问来源于stack exchange，提问作者lr-pal