Microsoft.NETCore.App与Platforms传递依赖版本解析规则咨询

NuGet依赖解析的核心规则是默认采用最低适用版本策略：所有依赖链中声明的最低版本要求只要被满足，就不会主动升级到更高版本，不会因为项目目标框架是.NET 6就自动把所有传递依赖拉到6.x版本。

出现这类过时告警的本质原因可归纳为三点：

• 案例中引入的System.Data.SqlClient 4.8.3是兼容.NET Standard 2.0的旧适配包，它的nuspec依赖清单里明确声明了对Microsoft.Win32.Registry 4.7.0、System.Security.AccessControl 4.7.0等基础库的最低版本要求，未配置浮动版本规则，NuGet解析时会直接选中它声明的最低版本，不会主动向上匹配共享框架自带的高版本。
• 元包和共享框架的版本不会自动覆盖传递依赖版本。虽然net6.0项目隐式引用了对应版本的Microsoft.NETCore.App元包，元包中确实包含这些基础库的6.0版本引用，但NuGet做全局依赖版本统一计算时，只要依赖链里出现了更低的版本要求，且没有显式的高版本声明覆盖，最终解析结果就会被拉到低版本。
• 这类告警绝大多数是假阳性。.NET 6运行时加载程序集时，会优先加载共享框架中自带的高版本实现，根本不会用到NuGet解析出来的低版本dll，只是dotnet list package --outdated命令仅做静态依赖树版本号扫描，不会判断运行时实际加载逻辑，才会输出一长串过时提示。

不需要把这些传递依赖逐个加为项目直接引用，两种方式即可解决问题：

• 用PackageReference的Update语法批量覆盖传递依赖版本，该操作不会修改项目的直接依赖列表，仅调整NuGet对已有传递依赖的版本解析结果，示例配置直接加入csproj即可：

<ItemGroup>
  <!-- 对齐.NET 6对应的基础包版本，覆盖SqlClient引入的低版本传递依赖 -->
  <PackageReference Update="Microsoft.NETCore.Platforms" Version="6.0.3" />
  <PackageReference Update="Microsoft.Win32.Registry" Version="5.0.0" />
  <PackageReference Update="System.Security.AccessControl" Version="6.0.0" />
  <PackageReference Update="System.Security.Principal.Windows" Version="5.0.0" />
</ItemGroup>

• 如果不想手动维护这些版本号，可以直接调整构建流水线的包检查规则，把System.*、Microsoft.NETCore.*、Microsoft.Win32.*这类属于.NET共享框架自带的基础包排除在过时检查范围外。这类包的实际运行版本永远和项目目标框架绑定，单独升级NuGet解析出来的版本号没有实际意义，反而会增加不必要的维护成本。

补充：System.Data.SqlClient本身已经处于功能冻结状态，微软后续的bug修复、功能迭代均已转移到Microsoft.Data.SqlClient包，长期维护的项目建议直接迁移到新包，从根源上减少这类旧适配包带来的传递依赖问题。

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