TFS Изменение рабочего каталога агента сборки

Question

Я получаю ту же ошибку, что и , описанную здесь . Я бегу к пределу имени файла Windows в сборке TFS. Ответы на этот вопрос предлагают переопределить рабочий каталог агента сборки. Я не уверен, должен ли я сделать это. У меня есть несколько вопросов ...

1. Влияет ли изменение рабочего каталога агента сборки на меня или на всех, кто использует агент сборки?

2. Агент по сборке не запущен мной, он находится на другом компьютере, управляемом другим отделом нашей компании. Я могу добраться до настроек «Управление сборкой контроллера», и я, кажется, могу внести эти изменения, я просто боюсь!

Answer 1

Здесь есть несколько вариантов: изменить каталог сборки в агенте сборки, в Team Explorer щелкните правой кнопкой мыши папку «сборки» и выберите «Управление агентами сборки». Выберите сервер (ы) сборки и измените папку сборки на что-то вроде «e: \ b» (или даже «e: \», если это все, для чего вы используете этот диск). Это изменит рабочий каталог сборки для этого сервера сборки. Это сбрит несколько символов с рабочего каталога.

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

например. Если ваше рабочее пространство сопоставлено с $ / TeamProject = $ (SourceDir), это означает, что TFS получит весь код в командном проекте для сборки. Даже если вы хотите только 1 решение из 1 филиала

Рассмотрим групповой проект, подобный этому

`$/TeamProject/DevBranch/Docs
                        /Source/Solutions/Solution1
                                         /Solution2
                                         /etc...
                        /More Stuff
              /MainBranch/[Same As Dev]
              /HotFixBranch/[Same As Dev]
              /ReleaseBranch/[Same As Dev]`

Если ваше рабочее пространство сопоставлено с $ / TeamProject, вы будете получать все из TFS, когда все, что вам действительно нужно, - это код в папке «solution2» из ветви dev. Измените отображение на $/TeamProject/Devbranch/Source/Solutions/Solution2, и вы только что побрили около 60 символов длины пути. В дополнение к этому вы ускорите сборку, поскольку она будет получать только тот код, который им нужен.

Answer 2

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

Answer 3

Полное имя не должно превышать MAX_PATH, которое находится на Windows 260 символов. На самом деле для разных инструментов используются разные значения.

GAC , например отклоняет имена файлов, которые превышают 256 символов. Под именем файла подразумевается путь и само имя файла. TFS построен на Windows, поэтому для сборок TFS существуют те же ограничения. Единственное возможное решение - использовать каталог рабочей области, который является максимально коротким, чтобы ограничить количество проблем, с которыми вы столкнетесь. Вы можете попытаться подставить каталог рабочей области, чтобы сделать его еще короче, но основные ограничения файловой системы не исчезнут.

Да, Microsoft должна решить эту проблему, но в действительности это неосуществимо в ближайшее время. Любой инструмент (MS и не MS), который используется во время сборки, будет иметь те же ограничения. В лучшем случае инструменты будут зависать, когда имена файлов становятся слишком длинными. В худшем случае вы получаете испорченные двоичные файлы, не замечая этого. Все приложения, написанные на C / C ++, используют для буферов имен файлов буфер размером MAX_PATH + 1. Даже если Windows разрешит такие имена файлов (есть способы, но ...), буферы почти всех приложений будут слишком малы, чтобы их использовать.

Вы не одиноки, мы все страдаем. С другой стороны, это ограничение не позволяет разработчикам придирки применять соглашения об именах, которые превышают только MAX_PATH с целевым именем.