VS2019下nuget.exe打包链式NuGet项目传递性依赖丢失问题咨询

问题触发逻辑 #

你当前使用的nuget.exe pack mx_logging.vbproj -IncludeReferencedProjects打包流程，在VS2019、NuGet 5.7.0版本环境下存在固定的行为边界：

• 该参数仅会识别项目中直接通过项目引用逻辑关联的项目类依赖，自动将这类依赖写入生成nupkg的依赖列表
• 不会自动识别项目中通过NuGet传递安装的第三方公共依赖
  结合你提供的第二个项目packages.config内容，Log4Net是被MX_Logging包传递引入的、并非你在第二个项目中主动从NuGet源直接安装的包，这就是打包时仅识别到MX_Logging、未识别到Log4Net的核心原因。

注：只要MX_Logging本身的nupkg配置了Log4Net的依赖项，下游安装第二个项目生成的nupkg时，会自动顺着MX_Logging的依赖链拉取Log4Net，并不需要在第二个项目的依赖列表里重复显式声明Log4Net。

可落地的修复操作 #

• 如果你不需要在第二个项目的nupkg里显式罗列Log4Net依赖：保持现有打包流程即可，打开MX_Logging.nupkg对应的nuspec配置文件，确认<dependencies>节点下已经正确写入对应版本的Log4Net依赖，即可保证整条依赖链的自动传递。
• 如果你需要在第二个项目的nupkg里显式将Log4Net列为直接依赖，需跳过自动打包的依赖识别逻辑，手动维护包清单：
  1. 在第二个项目根目录执行nuget spec，生成与项目对应的.nuspec清单文件
  2. 打开生成的nuspec文件，在<dependencies>节点下手动补充需要声明的依赖项：

     <dependency id="log4net" version="2.0.8" />
     <dependency id="MX_logging" version="1.2.7668.29513" />
     

  3. 打包时直接指向手动维护的nuspec文件执行命令，避免自动参数的识别偏差：nuget pack 你的第二个项目.nuspec
• 长期优化建议：你当前项目使用的是packages.config格式的NuGet包管理模式，该模式下打包对传递依赖的识别能力本身存在缺陷，可逐步将项目迁移为PackageReference格式，该格式下打包流程会自动梳理完整的依赖传递关系，无需手动重复声明重复依赖。

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