有没有人可以克服从命令行构建Visual Studio项目和解决方案的MSBuild工具的260个字符限制的方法？我正在尝试使用CruiseControl使构建自动化(CruiseControl.NET不是一个选择，因此我试图将其绑定到普通的ant脚本中)，并且继续遇到路径长度问题。要澄清的是，问题在于解决方案文件中引用的项目的路径长度，因为该工具无法正确折叠路径:(

我也尝试过使用DevEnv，它有时可以工作，有时会引发异常，这对于在单独的机器上进行自动构建是不利的。因此，请不要建议使用它来替代它。

最重要的是，通过常规IDE使用Visual Studio时，项目构建良好。

解决方案

我们是否尝试过DOS路径？还是\？\前缀？ .NET BCL团队博客具有更多信息。

看来这是MSBuild的局限性。我们遇到了同样的问题，最后，我们不得不缩短了路径，因为没有找到其他可以正常工作的解决方案。

SUBST命令似乎仍然存在，因此如果Judah Himango的解决方案不好，则将构建文件夹的根目录重新映射到驱动器号可能会节省一些字符。

有两种与构建有关的长途问题。一种是不太长的路径，但其中包含很多" .. "。通常，这些是引用的HintPath值。 MSBuild应该将这些路径归一化到最大限制以下，以便它们起作用。

另一种路径就是太长了。对不起，但是这些都行不通。看了几分之后，问题在于长路径没有足够的API支持。 BCL团队(请参阅他们的博客)也有类似的问题。仅某些Win32 API支持\？\格式。任意构建工具(可能有98％的应用程序没有)都没有；更糟糕的是，它的行为可能很糟(请考虑所有大小为MAX_PATH的缓冲区)。

我们得出的结论是，除非做出巨大的生态系统努力来使长路径起作用，否则Windows提出了一些巧妙的方法来使它们无论如何都可以工作(例如短路径处理？)，MSBuild无法支持长路径。 。如我们所见，解决方法包括替代。但是如果树太深了，我们唯一的选择是将其分片构建，或者缩短文件夹名称。对不起。

丹/ MSBuild