Visual Studio / TFS 2010 / Get Latest / Сбой компиляции для некоторых не для других с ошибкой ссылки - PullRequest
0 голосов
/ 01 июля 2011

setup:

  • вся разработка выполняется на виртуальных серверах (Win Server 2003)
  • все компиляции выполняются в VS 2010
  • весь код проверен в TFS 2010

Мы переносим наши решения с VS 2008 на VS 2010. Я создал ГЛАВНУЮ ветвь для размещения наших преобразованных проектов VS 2010.Затем я начал работать над переносом проектов с 2008 года. Компиляции были (в конце концов) успешными.Другой разработчик работал над другими проектами в той же ветке.

Затем все эти проекты компилировались также через TFS Build 2010.

Это наша ОСНОВНАЯ ветка.Затем другой разработчик создал папку ветви DEV и разветвил все решения из ветви MAIN в ветку DEV для дальнейшей разработки.

К нашему большому удивлению, мы обнаружили, что хотя мы можем скомпилировать код, если мы выполнимПолучите последние новости о ветке MAIN, когда мы получили последние новости о ветке DEV (предположительно, тот же код), * ​​1021 * некоторые из нас (назовем их неудачливыми разработчиками) получили массу ошибок, связанных сделать со ссылкой на проект, содержащийся в решении.Но два разработчика (к счастью) скомпилировали его просто отлично. Когда два неудачных скомпилировали отдельный проект (тот, который вызывает ошибку ссылки), он строится нормально, но когда мы строим решение или ссылочный проект,со ссылкой на этот проект происходит сбой.

Мы попытались стереть наше рабочее пространство и сделать код свежим - без радости.

Счастливый человек, создавший ветку, сделал то же самое (удалил их рабочее пространство, получил последнюю версию и запустил компиляцию), и он все еще компилируется.Затем у нас был разработчик, который не участвовал в миграции, выполнил последнюю задачу и запустил компиляцию.Их компиляция тоже прошла отлично!Это привело нас к мысли, что это должен быть компьютер.

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

Тогда ... мы отсоединили рабочее рабочее пространство от счастливого разработчикаВиртуальный и один из несчастливых разработчиков, прикрепленных к нему (нет, просто скомпилируйте, что там).Это хорошо скомпилировано.

Так что у нас может быть какая-то особенность, связанная с несчастными разработчиками, из-за которых наши Gets будут другими.Одно из различий, которое я только что понял, состоит в том, что у нас двоих есть неудачные наборы полок, которые мы сохранили в TFS в версиях 2008 года (но в TFS 2010).

ОК, тогда ... тот же незадачливый разработчик уничтожил рабочее пространство счастливчика, удалив файлы, а затем выполнил включенные переключатели принудительной перезаписи get / latest / both.Это успешно скомпилировано !!

Затем он вернулся к своей первоначальной виртуальной машине.Он удалил файлы в своем рабочем пространстве и включил специальные / последние / оба переключателя принудительной перезаписи. Эта компиляция снова не удалась!

У нас заканчиваются идеи ...

Ответы [ 3 ]

0 голосов
/ 11 июля 2011

Ну, мы получили еще раз. Проблема была связана с длиной пути к исходному коду. Конечно, в действительной ошибке нет указаний на это. Это, наверное, восьмой раз, когда я столкнулся с этим. Это разочаровывает, пытаясь сохранить смысл в пространствах имен, чтобы постоянно обрезать эти пути.

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

Мне кажется, я понял почему. Мой компилятор был настроен на «Смешанные платформы», а те, которые могли компилироваться, были установлены на «Любой процессор».

Решение было (еще раз - это становится действительно старым), чтобы переместить проект на несколько папок вместо того, чтобы содержать его там, где мы надеялись. Это уменьшило количество символов в пути, и компиляция прошла нормально. Тьфу.

0 голосов
/ 21 декабря 2013

я должен был сделать пару вещей убедитесь, что моя сборочная машина и VS2010 были на том же уровне исправлений, что и TFS-сервер (они не были), что принесло мне новые ошибки.

Я удалил все рабочие области в моей системе, как указано выше

сделал для моего кода. (разрешенные конфликты) (включая шаблоны и решения, с которыми я работал)

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

о, между прочим, ЭТО ОТКРЫТАЯ ОШИБКА ... в 2010 и 2012 годах ... MS пытается найти решение для этого. : Р

0 голосов
/ 01 июля 2011

Похоже, что (неудачные) разработчики могут иметь настраиваемые сопоставления рабочего пространства (определяет, какие папки в TFS извлекаются, где на жестком диске).

Вид -> Team Explorer -> Контроль исходного кода -> Щелкните раскрывающийся список в рабочем пространстве и выберите Рабочие пространства ...

Удалить все рабочие пространства там (или хотя бы проверить их).

Создать единую новую рабочую область и оформить заказ на корневом уровне (чтобы сохранить ссылки на проекты без изменений)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...