Ответ 1
Кажется, что это ограничение MSBuild. У нас была та же проблема, и, в конце концов, нам пришлось убирать пути, потому что не находили никаких других решений, которые работали должным образом.
Структура каталогов MSBuild ограничивает обходные пути
Есть ли у кого-нибудь способ преодолеть предел в 260 символов для инструмента MSBuild для создания проектов и решений Visual Studio из командной строки? Я пытаюсь получить автоматическую сборку с помощью CruiseControl (CruiseControl.NET не вариант, поэтому я пытаюсь привязать его к обычным сценариям ant), и я продолжаю сталкиваться с проблемами с длиной путей. Чтобы уточнить, проблема заключается в длине путей проектов, на которые ссылается файл решения, поскольку инструмент не сбрасывает пути вниз должным образом: (
Я также пробовал использовать DevEnv, который иногда работает и иногда выдает исключение, что не подходит для автоматической сборки на отдельной машине. Поэтому, пожалуйста, не предлагайте использовать это как замену.
И в довершение всего, проект строит отлично при использовании Visual Studio через обычную среду IDE.
Ответы
Ответ 2
SUBST-команда, похоже, существует, поэтому переназначение корня вашей папки сборки на букву диска может сэкономить некоторые символы, если решение Judah Himango ничего хорошего.
Ответ 3
Я решил подобную проблему, настроив CSPROJ файл:
<BaseIntermediateOutputPath>$([System.IO.Path]::GetFullPath('$(MSBuildProjectDirectory)\..\..\..\Intermediate\$(AssemblyName)_$(ProjectGuid)\'))</BaseIntermediateOutputPath>
В результате во время компиляции CSC.EXE получает полный путь вместо относительного.
Спасибо harrydev за подсказку о том, как CSC.EXE работает с путями.
Ответ 4
Существует два типа проблем с длинными дорожками, связанных с построением. Один - это пути, которые на самом деле не слишком длинны, но в них много "..". Как правило, это ссылки на значения HintPath. MSBuild должен нормализовать эти пути вплоть до максимального предела, чтобы они работали.
Другой вид пути просто слишком длинный. Извините, но это просто не сработает. Посмотрев на это честно, проблема в том, что для длинных путей просто недостаточно поддержки API. У команды BCL (см. Их блог) были подобные проблемы. Только некоторые из Win32 API поддерживают формат \? \. Произвольные инструменты сборки и, вероятно, 98% приложений там нет; и хуже, вероятно, будет плохо работать (подумайте обо всех буферах, размер которых равен MAX_PATH).
Мы пришли к выводу, что до тех пор, пока не будут предприняты большие усилия по созданию длинных путей, или Windows придумает какой-то изобретательный способ заставить их работать в любом случае (например, короткие пути, искажающие?), длинные пути просто невозможны для MSBuild для поддержки. Методы обхода включают subst, как вы нашли; но если ваше дерево просто слишком глубокое, ваши единственные возможности - создать его в фрагментах или сократить имена папок. К сожалению.
Dan/MSBuild
Ответ 5
Я обнаружил, что проблема заключается в том, что при вызове компилятора С# (csc.exe) он использует путь к каталогу проектов PROJECTDIRECTORY вместе с выходным путем OUTPUTPATH, просто добавляя их как:
PROJECTDIRECTORY + OutputPath
Однако, если OUTPUTPATH является относительным, то есть ".. \..\Build\ProjectName\AnyCPU_Debug_Bin \", а каталог проекта довольно длинный, тогда общая длина длиннее 259 символов, так как путь будет:
PROJECTPATH + ".. \..\Постройте\ProjectName\AnyCPU_Debug_Bin \"
вместо абсолютного пути.
Если csc.exe сделает абсолютный путь до вызова функций Win32, это сработает. Так как в нашем случае длина абсолютного пути меньше 160 символов.
По какой-то причине вызов csc.exe из visual studio отличается от MSBuild, чем от визуальной студии. Не знаю, почему.
В любом случае проблема может быть решена путем изменения путей или PRODECTDIRECTORY и/или OUTPUTPATH.
Ответ 6
Вы пробовали пути DOS? Или префикс \\? \? . Блог группы NET BCL содержит больше информации.
Ответ 7
Если длина пути равна 260, тогда есть ссылка для разрешения предупреждения, для 259 или 261 этой ошибки не возникает. Я думаю, что есть ошибка msbuild.
Ответ 8
Я знаю, что уже есть принятый ответ, но у меня была другая проблема при использовании msbuild, которая давала мне тот же самый вывод ошибок и приводила меня к круговой охоте на диких гусей. Итак, для будущих googlers, здесь идет:
У нас есть пакетный файл, который вызывает msbuild, но по мере того, как машина сборки может создавать для нескольких версий Visual Studio, каждый командный файл вызывает vcvarsall.bat до запуска msbuild. У этого есть неприятный побочный эффект наполнения пути, полностью наполненного одним и тем же снова и снова. Когда он заполнится, вы получите сообщение об ошибке, указанное в вопросе выше: The input line is too long. Простой поиск в Google может заставить вас думать, что ваши пути слишком длинны для msbuild.
В моем случае это было так же просто, как убить сеанс cmd.exe и перезапустить, поскольку это вернуло переменные среды в их собственное состояние.