Методы обхода структуры каталогов MSBuild

Question

Есть ли у кого-нибудь способ преодолеть ограничение в 260 символов инструмента MSBuild для построения проектов и решений Visual Studio из командной строки? Я пытаюсь автоматизировать сборку с помощью CruiseControl (CruiseControl.NET не вариант, поэтому я пытаюсь связать его с обычными муравьиными сценариями) и продолжаю сталкиваться с проблемами с длиной путей. Для пояснения проблема заключается в длине путей проектов, на которые есть ссылки в файле решения, так как инструмент неправильно свернул пути: (

Я также пытался использовать DevEnv, который иногда работает, а иногда выдает исключение, что не подходит для автоматической сборки на отдельной машине. Поэтому, пожалуйста, не предлагайте использовать это в качестве замены.

И в довершение всего, проект прекрасно работает при использовании Visual Studio через обычную IDE.

Answer 1

Кажется, что SUBST команда неподвижна, поэтому переназначение корня вашей папки сборки на букву диска может сохранить некоторые символы, если решение Джуды Химанго не годится.

Answer 2

Похоже, это ограничение MSBuild. У нас была та же проблема, и в итоге нам пришлось сократить пути, потому что не нашли другого решения, которое работало бы должным образом.

Answer 3

Я решил похожую проблему, настроив CSPROJ-файл:

<BaseIntermediateOutputPath>$([System.IO.Path]::GetFullPath('$(MSBuildProjectDirectory)\..\..\..\Intermediate\$(AssemblyName)_$(ProjectGuid)\'))</BaseIntermediateOutputPath>

В результате при компиляции CSC.EXE получает полный путь вместо относительного.

Спасибо harrydev за подсказку о том, как CSC.EXE работает с путями.

Answer 4

Существует два типа длинных путей, связанных со сборкой. Один из них - это пути, которые на самом деле не слишком длинные, но содержат много ".. \". Как правило, это значения HintPath ссылок. MSBuild должен нормализовать эти пути ниже максимального предела, чтобы они работали.

Другой вид пути слишком длинный. Извините, но это не сработает. Если взглянуть честно, проблема в том, что API для поддержки длинных путей просто недостаточно. У команды BCL (см. Их блог) были подобные проблемы. Только некоторые из Win32 API поддерживают формат \? \. Произвольные инструменты сборки, и, вероятно, 98% приложений там, нет; и хуже, вероятно, будет вести себя плохо (подумайте обо всех буферах, размер которых указан для MAX_PATH).

Мы пришли к выводу, что до тех пор, пока не будут предприняты большие усилия в экосистеме, чтобы заставить работать длинные пути, или пока Windows не придумает какой-то оригинальный способ заставить их работать в любом случае (например, искажение коротких путей?), Длинные пути просто невозможны для MSBuild для поддержки. Обходные пути включают в себя sub, как вы нашли; но если ваше дерево просто слишком глубокое, ваши единственные варианты - построить его по фрагментам или сократить имена папок. К сожалению.

Dan / MSBuild

Answer 5

Я обнаружил, что проблема в том, что когда вызывается компилятор C # (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, чем от visual studio. Не знаю почему.

В любом случае проблему можно решить, изменив один или оба пути PROJECTDIRECTORY и / или OUTPUTPATH.

Answer 6

Я знаю, что уже есть принятый ответ, но у меня была другая проблема при использовании msbuild, которая выдала мне ту же ошибку и вывела меня на круговую погоню. Итак, для будущих googlers, здесь идет:

У нас есть пакетный файл, который вызывает msbuild, но, поскольку сборочный компьютер может собираться для нескольких версий Visual Studio, каждый пакетный файл вызывает vcvarsall.bat, прежде чем запустить msbuild. Это имеет неприятный побочный эффект, когда вы снова и снова набиваете путь, полностью заполненный одним и тем же. Когда он заполняется, вы получаете сообщение об ошибке, показанное в приведенном выше вопросе: The input line is too long. Простой поиск в Google может заставить вас думать, что ваши пути вдруг слишком длинные для msbuild.

В моем случае это было так же просто, как убить сеанс cmd.exe и перезапустить, так как это вернуло переменные среды в их исходное состояние.

Answer 7

Если длина пути равна 260, то имеется ссылка для разрешения предупреждения, для 259 или 261 этой ошибки не происходит. Я думаю, что есть ошибка msbuild.

Answer 8

Вы пробовали пути DOS? Или префикс \\? \? В блоге .NET BCL есть больше информации.