大型解决方案全局设置MSBuild /nr:false，配置Directory.Build.Props无效求助

嘿，我来帮你排查这个问题！你遇到的情况其实挺常见的，咱们一步步来分析可能的原因和解决办法：

1. 先确认Directory.Build.Props的位置是否正确 #

这个文件的放置位置是关键：

• 如果要作用于整个解决方案，必须把它放在和你的.sln文件同一层级的目录下；
• 如果只作用于单个项目，就放在该项目文件（.csproj/.vbproj等）的父目录里。
  MSBuild会自动从当前项目目录往上递归查找这个文件，但如果放错了层级，它根本不会被读取到。

2. 移除不必要的ToolsVersion属性 #

你当前的配置里写了<Project ToolsVersion="4.0" ...>，但现在主流的MSBuild版本（比如VS2019/2022对应的16.x/17.x）已经不再依赖这个属性确定构建工具版本了。保留这个属性反而可能导致MSBuild用旧的兼容模式处理配置，影响MSBUILDDISABLENODEREUSE的生效。

修改后的正确Props文件内容应该是：

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <MSBUILDDISABLENODEREUSE>1</MSBUILDDISABLENODEREUSE>
  </PropertyGroup>
</Project>

3. 排查是否有其他配置覆盖了这个属性 #

如果上面的调整还是没生效，要检查是否有其他地方的配置覆盖了MSBUILDDISABLENODEREUSE的值：

• 项目文件本身是否直接设置了这个属性？
• 其他导入的Props/Targets文件（比如Directory.Build.targets）是否重新定义了这个属性？因为MSBuild的属性是后定义的覆盖先定义的，Targets文件的导入时机晚于Props，所以如果Targets里设置了这个属性为0，就会覆盖你的配置。

你可以用MSBuild命令行加诊断日志来验证：

msbuild YourSolution.sln /verbosity:diagnostic

然后在输出日志里搜索MSBUILDDISABLENODEREUSE，看它最终的值是1还是0，就能确定是否被覆盖了。

4. 备选方案：用Directory.Build.rsp直接指定命令行参数 #

如果Props文件的方式始终不生效，更直接的办法是使用Directory.Build.rsp文件（和Props文件放在同一位置），内容只需要一行：

/nr:false

MSBuild会自动加载这个响应文件，把里面的参数当作命令行参数默认添加，这和你手动输入msbuild ... /nr:false的效果完全一样，而且优先级更高，不容易被覆盖。

最后别忘了重启Visual Studio #

如果你是在Visual Studio中构建，VS会缓存部分构建配置，修改完Props或rsp文件后，最好重启一下VS，确保新的配置被加载。

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