使用集中式包管理后测试项目.csproj缺失PackageReference是否为预期行为？

背景 #

我有一个包含30多个.NET项目的解决方案，此前NuGet包版本在多个.csproj文件中单独定义。在迁移至Centralized Package Management（集中式包管理）时，使用了CentralisedPackageConverter工具，生成了单个Directory.Packages.props文件来集中管理包版本。

迁移前，测试项目SampleTest.csproj中包含：

<PackageReference Update="Microsoft.NET.Test.Sdk" Version="17.14.1" />

迁移后：

• Directory.Packages.props中包含：

<PackageVersion Include="Microsoft.NET.Test.Sdk" Version="17.14.1" />

• SampleTest.csproj中不再包含任何对Microsoft.NET.Test.Sdk的引用（既无Include也无Update）。

尽管解决方案构建成功、CI/CD流水线正常通过，但存在以下疑问：

1. 迁移期间PackageReference条目从.csproj中完全移除是否属于预期行为？ #

是预期行为，但仅针对被其他包间接依赖的NuGet包。CentralisedPackageConverter会扫描项目的依赖树，若某个包不是项目直接需要的，而是由已显式引用的包（比如xUnit、NUnit等测试框架）引入的间接依赖，工具就会将其从.csproj中移除，只在Directory.Packages.props中保留版本定义，以此消除冗余的显式引用。

2. 若项目文件中未显式引用，该依赖是如何被解析的？ #

依赖解析由NuGet的机制自动完成：

• Directory.Packages.props中的<PackageVersion>节点为所有项目定义了该包的版本基线；
• 当项目中显式引用的包（比如测试框架）声明了对Microsoft.NET.Test.Sdk的依赖时，NuGet会自动从Directory.Packages.props中读取预定义的版本，将这个间接依赖引入项目，无需在.csproj中显式声明。

3. 测试项目中未显式列出Microsoft.NET.Test.Sdk存在哪些潜在影响或风险？ #

主要有三类风险：

• 维护成本提升：其他开发者查看.csproj时，无法直接知晓项目依赖了测试SDK，排查测试相关问题（比如测试无法运行、构建报错）时会增加排查难度；
• 版本失控风险：如果间接依赖的包更新了对Microsoft.NET.Test.Sdk的版本依赖范围，而你未在Directory.Packages.props中严格锁定版本，可能会引入不符合预期的版本，引发兼容性问题；
• 依赖断裂风险：若未来测试框架包不再默认依赖Microsoft.NET.Test.Sdk（概率极低但存在可能性），你的测试项目会突然缺失核心依赖，导致构建或测试执行失败。

4. 是否应手动在.csproj中重新添加<PackageReference Include="Microsoft.NET.Test.Sdk"/>？ #

建议手动添加，理由如下：

• 符合.NET测试项目的最佳实践：Microsoft.NET.Test.Sdk是测试项目运行的核心依赖，显式声明能让项目依赖关系更清晰；
• 提升项目可读性和维护性，降低后续开发者的理解成本；
• 规避未来间接依赖变更带来的风险，确保测试项目的核心依赖始终可控。
  添加时无需指定Version属性，版本会自动从Directory.Packages.props中读取。

内容的提问来源于stack exchange，提问作者santosh kumar patro