我与工作项目文件进行了比较，唯一的主要区别是非工作项目文件中缺少这一行：
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
修复方法是将该行添加为<Project>的第一个子元素：

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
    ...

This answer很好地说明了省略这一行时会发生什么。

这里可能有几件事在起作用。
在设置属性的值之前测试属性是否已经设置是一个很好的做法-参见MSBuild best practices。但是项目模板中的CodeAnalysisRuleSet定义不检查。即.csproj文件中

<CodeAnalysisRuleSet>RuleSetPathAndName</CodeAnalysisRuleSet>

Directory.Build.props文件将提前导入。在Directory.Build.props文件中为CodeAnalysisRuleSet设置的任何值都将被项目覆盖。
这听起来像是你想要的行为：为没有定义CodeAnalysisRuleSet的项目提供一个“全局”默认规则集。
由于响应能力和性能的原因，Visual Studio IDE有时候“太聪明了”。GUI中显示的规则集可能是错误显示和/或可能是缓存问题。
一些尝试的步骤：
1.完全关闭Visual Studio。
1.验证源文件Directory.Build.props和.csproj文件的设置是否正确。
1.在VS 2022中，解决方案文件夹中将有一个.vs文件夹。这是Visual Studio缓存。（注意.vs文件夹永远不应受版本控制。）删除.vs文件夹。Visual Studio将在下次打开解决方案时重新生成它。
1.在开发提示符下运行解决方案的命令行构建。验证是否使用了正确的规则集。如果CLI构建的行为与预期不同，则MSBuild代码中可能存在问题。
1.打开Visual Studio，然后在Visual Studio中打开解决方案。运行生成并验证是否使用了正确的规则集。VS构建和CLI构建应该在所使用的规则集方面相匹配。
1.最后检查UI中的项目属性。如果UI现在显示正确的值，则问题可能是缓存损坏。