为何将非CPM相关配置放入Directory.Packages.props文件？

你的直觉其实没错——按常规职责划分，Directory.Build.props确实是存放通用构建配置的标准位置，但把这两个属性放到Directory.Packages.props里，通常是出于以下几个实际考量：

• 加载时机的优先级：Directory.Packages.props的加载阶段比Directory.Build.props更早，处于项目评估的最前期。对于TargetFramework这种基础属性，提前设置能让CPM（Central Package Management）在解析包依赖时，基于正确的目标框架去匹配对应版本的包（不少包会针对不同TFM发布不同版本）。如果等到Directory.Build.props阶段再设置，可能会导致CPM解析依赖时TFM还未确定，引发版本匹配的潜在问题。

• CPM相关约束的聚合：虽然TreatWarningsAsErrors不是CPM专属配置，但很多团队会把所有和包管理、项目基础约束相关的统一规则集中到Directory.Packages.props里——因为启用CPM的项目会自动加载这个文件，不需要额外做导入配置。相比之下，Directory.Build.props更多聚焦于构建流程的细节（比如编译输出路径、自定义任务等），但这只是约定而非强制规则。

• 减少配置冗余：如果你的解决方案里所有项目都启用了CPM，那么Directory.Packages.props会被所有项目自动识别。把TargetFramework和TreatWarningsAsErrors放在这里，能确保所有项目无需额外配置就能继承这些基础约束，不用在多个文件里重复设置。

当然，这并不意味着你必须这么做。如果团队更倾向于严格划分配置职责，把这两个属性移回Directory.Build.props完全可行——只要保证TargetFramework在CPM处理依赖前已经被正确设置就行（比如在Directory.Build.props的早期节点定义）。

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