有没有人有办法克服 MSBuild 工具的 260 个字符限制，以便从命令行构建 Visual Studio 项目和解决方案？我正在尝试使用 CruiseControl 使构建自动化（CruiseControl.NET 不是一个选项，所以我试图将其绑定到普通的 ant 脚本中）并且我一直遇到路径长度问题。澄清一下，问题在于解决方案文件中引用的项目路径的长度，因为该工具没有正确折叠路径:(
我也尝试过使用 DevEnv，它有时可以工作，有时会引发异常，这对于在单独的机器上自动构建并不好。所以请不要建议使用它作为替代品。
最重要的是，当通过普通 IDE 使用 Visual Studio 时，项目构建良好。
似乎这是 MSBuild 的限制。我们遇到了同样的问题，最后，我们不得不缩短路径，因为没有找到任何其他正常工作的解决方案。
SUBST 命令仍然存在，因此如果 Judah Himango 的解决方案不好，将构建文件夹的根重新映射到驱动器号可能会节省一些字符。
我通过调整 CSPROJ 文件解决了类似的问题：
<BaseIntermediateOutputPath>$([System.IO.Path]::GetFullPath('$(MSBuildProjectDirectory)\..\..\..\Intermediate\$(AssemblyName)_$(ProjectGuid)\'))</BaseIntermediateOutputPath>
结果在编译期间 CSC.EXE 收到完整路径而不是相对路径。
感谢 harrydev 提供有关 CSC.EXE 如何使用路径的线索。
有两种与构建相关的长路径问题。一种是路径不太长，但其中有很多“..\”。通常，这些是引用的 HintPath 值。MSBuild 应该将这些路径标准化到低于最大限制，以便它们工作。
另一种路径太长了。对不起，但这些只是行不通。在仔细研究之后，问题是对于长路径没有足够的 API 支持。BCL 团队（见他们的博客）也有类似的问题。只有部分 Win32 API 支持 \?\ 格式。任意构建工具，可能有 98% 的应用程序，不这样做；更糟糕的是可能会表现得很糟糕（想想所有为 MAX_PATH 调整大小的缓冲区）。
我们得出的结论是，除非有大量的生态系统努力让长路径工作，或者 Windows 想出一些巧妙的方法让它们无论如何都工作（比如短路径损坏？）MSBuild 不可能支持长路径. 如您所见，解决方法包括 subst；但是如果你的树太深了，你唯一的选择就是将它构建在片段中，或者缩短文件夹名称。对不起。
丹/MSBuild
我发现问题在于，当调用 C# 编译器（csc.exe）时，它使用项目目录路径 PROJECTDIRECTORY 以及输出路径 OUTPUTPATH，只需将它们附加为：
项目目录+输出路径
但是，如果 OUTPUTPATH 是相对的，即“..\..\Build\ProjectName\AnyCPU_Debug_Bin\”并且项目目录很长，那么总长度会超过 259 个字符，因为路径将是：
PROJECTPATH+"..\..\Build\ProjectName\AnyCPU_Debug_Bin\"
而不是绝对路径。
如果 csc.exe 在调用 Win32 函数之前创建一个绝对路径，这将起作用。因为在我们的例子中，绝对路径长度小于 160 个字符。
由于某种原因，从 Visual Studio 对 csc.exe 的调用与 MSBuild 不同，而不是从 Visual Studio 调用。不知道为什么。
在任何情况下，都可以通过更改 PROJECTDIRECTORY 和/或 OUTPUTPATH 路径中的一个或两个来解决问题。
你试过DOS路径吗？还是 \\?\ 前缀？.NET BCL 团队博客有更多信息。
如果路径长度为 260，则有警告解析参考，对于 259 或 261 不会发生此错误。我认为有 msbuild 错误。
我知道已经有一个公认的答案，但是我在使用它时遇到了一个不同的问题，msbuild它给了我相同的错误输出，并导致我进行了一次循环的野鹅追逐。所以，对于未来的谷歌人来说，这里是：
我们有一个调用的批处理文件msbuild，但是由于构建机器可以为多个版本的 Visual Studio 构建，每个批处理文件vcvarsall.bat在运行之前都会调用msbuild. 这有一个令人讨厌的副作用，就是一遍又一遍地将路径完全填满相同的东西。当它填满时，你会得到上面问题中显示的错误：The input line is too long.一个简单的谷歌搜索可能会让你觉得你的路径突然太长了msbuild。
就我而言，它就像终止会话cmd.exe并重新启动一样简单，因为这会将环境变量恢复到它们的本机状态。