VS2019下.NET 5.0引用外部项目依赖未自动传递的方案咨询

你感知到的.NET 5与.NET Framework的引用逻辑差异，本质上不是.NET 5取消了传递依赖能力，是两个场景下使用的引用路径完全不同：

• .NET Framework场景下的依赖自动输出，基于旧的裸DLL引用逻辑：只要被引用的DLL和关联依赖存在于同一路径，构建过程就会顺带着把同目录下的关联DLL同步到输出目录。
• .NET 5 SDK风格项目的传递依赖，基于NuGet包引用体系实现：只有当你以「项目引用（ProjectReference）」方式关联类库、且类库的依赖通过NuGet引入时，传递解析逻辑才会生效。你现在直接引用编译输出的ProjectNet.dll文件，相当于完全绕开了NuGet的依赖追踪体系，构建系统根本读不到这个DLL对应的依赖清单，自然不会自动同步Grpc相关的文件。

• 第一优先级：把对ProjectNet.dll的浏览类引用，替换为对ProjectNet.csproj的项目引用
  修改后构建系统会自动读取ProjectNet项目的NuGet依赖配置，按照标准传递规则把Grpc及其他关联依赖的文件全部同步到ProjectNetRef的输出目录，不需要手动补充任何Grpc相关的包引用。只要两个项目在同一解决方案中，直接在“添加项目引用”的项目页签选择对应类库即可，不要通过浏览路径定位编译输出的DLL。
• 第二优先级：如果因代码隔离、权限限制等原因，只能拿到ProjectNet的编译输出、无法获取源码项目
  不需要盲目猜测依赖，也不用等运行时报错反向排查：只要能拿到ProjectNet项目编译生成的obj/project.assets.json文件，该文件会完整记录项目所有直接、间接引用的NuGet包名称、精确版本、关联依赖路径，把这些包按照匹配版本在ProjectNetRef中统一安装即可，构建系统会自动完成后续的依赖解析和输出拷贝。
• 第三优先级：如果只能拿到孤立的ProjectNet.dll文件，连对应构建资产都无法获取
  可以通过工具扫描DLL的元数据提取依赖关系：用VS自带的对象浏览器、或是dotnet生态下的dotnet-ildasm、ildasm工具打开目标DLL，直接查看元数据中记录的所有外部引用程序集，再对应匹配到NuGet上的对应包安装即可，完全可以提前完成依赖补齐，不用等到运行时报“无法加载文件或程序集”的错误。

• 手动给ProjectNetRef补充Grpc包引用的方式，属于退回到手动管理依赖的老路：只有当依赖链条极短、且完全确认版本匹配关系时才适用，一旦被引用类库的后续版本调整了依赖版本，很容易出现版本错配、运行时冲突的问题，不属于最优解。
• 只有当被引用类库的NuGet依赖刻意设置了PrivateAssets="All"这类阻断传递的元数据时，才会出现项目引用也不传递依赖的情况，这属于包作者刻意设计的逻辑（比如要求宿主端主动初始化相关组件），不属于SDK的默认行为。

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