Восстановите привязки контроля исходного кода TFS.
У меня есть около десятка проектов Visual Studio 2010, над которыми я работаю, и которые созданы в TFS-репозитории. Недавно я отправился в отпуск и обновил операционную систему моего компьютера до Windows 7 64 бит.
Я переустановил Visual Studio, и я могу подключиться к своему Team Foundation Server и увидеть мои проекты... только мои привязки работают неправильно. В большинстве случаев ни один из моих файлов, похоже, не находится под контролем исходного кода, но в нескольких проектах мои привязки контроля исходного кода в корневой папке в порядке, но не работают в подпапках корневого каталога проекта.
Я попытался отменить привязку, открыть из системы контроля версий, удалить папку и получить последнюю версию. Ни один из них не устранил проблему.
Есть мысли о восстановлении моих привязок?
ОБНОВИТЬ
После осмотра я вижу, что в пути к моим "недействительным" проектам, похоже, есть дополнительная папка... Я понятия не имею, как она туда попала, но это, кажется, отбрасывает мои сопоставления.
7 ответов
Вы говорите, что пытались отменить привязку, но пытались ли вернуться к исходному контролю?
В Visual Studio:
- Откройте решение с проблемой
- Выберите решение в обозревателе решений
- Выбрать файл-> Контроль источника-> Изменить контроль источника
Visual Studio 2013/2015: Файл-> Контроль источника-> Дополнительно-> Изменить контроль источника - Удалите все проекты, которые связаны, но не работают правильно.
- Свяжите все проекты, которые сейчас не связаны.
Если у вас недопустимая привязка и открепление / привязка проекта не работает, попробуйте следующее:
- Отменить привязку проекта в Change Source Control
- Выгрузить проект в обозревателе решений (для сайта-проекта "выгрузить проект" находится не в контекстном меню, а в меню "Веб-сайт")
- Перезагрузить проект в обозревателе решений
У меня все время работает...
Я согласен с Джоэлом - обычно это устраняет привязка и повторная привязка.
Однако, если перепривязка не работает, вы можете попробовать редактировать файлы решения напрямую. Я видел случаи, когда привязки TFS дважды присутствовали в файле решения и по какой-либо причине выглядели неточными. Возможно, у них неправильное число проектов и проектов, для которых задано только одно значение, но они все еще перечислены в файле решения.
Когда это происходит (довольно редко), я редактирую файлы и делаю их такими, какими они должны быть. Например, я удалю 2-й набор привязок TFS (GlobalSection(TeamFoundationVersionControl)) или исправлю любые другие обнаруженные несоответствия. Затем я перезагружаю решение, и это обычно решает проблему. Я определенно буду использовать это исправление только в качестве последнего средства хоть.
Я увидел эту проблему, когда впервые открыл существующее (и ранее работавшее) решение во вновь установленной Visual Studio с недавно созданной рабочей областью.
Открепление и повторное связывание не решили проблему для меня. Но это ушло, когда я сделал последнюю версию Get. TFS показала файлы как конфликтующие, и я решил конфликты путем переопределения локальной копии. Ранее недействительные привязки были показаны как действительные.
Если вы все еще боретесь с недействительным статусом привязки TFS, я сообщаю здесь о "жемчужине", которую я нашел на старом (2005) форуме MSDN (https://social.msdn.microsoft.com/Forums/en-US/801b2490-776d-43a8-afef-adcedd78f02d/vsts-change-source-control-status-invalid?forum=tfsgeneral):
Это связано с эвристикой, используемой в коде проверки для привязки. Эвристика проверяет наличие всех файлов в проекте и возвращает "действительный" только в том случае, если в репозитории системы управления версиями присутствует не менее половины файлов. Поскольку у веб-проектов нет файла проекта, любой файл, находящийся в папке веб-проекта, считается "частью проекта". По-видимому, у вас было достаточно неконтролируемых файлов, чтобы увеличить процент контролируемых файлов проекта до менее 50%, что привело к недопустимому статусу.
Другими словами, если у вас есть проект, в котором много неконтролируемых файлов (это особенно верно, когда вы отказываетесь от регистрации для таких папок, как node_modules или public, в веб-проекте) и количество этих файлов составляет более 50% общее количество файлов в папке, статус привязки TFS недействителен, что бы вы ни делали.
Я мог проверить это правило, просто удалив правильное количество файлов, пока статус привязки не стал недействительным, и просто добавив новый (неконтролируемый), получил недопустимый статус.
Это поведение по-прежнему присутствует в VS 2019 6.3 (Azure DevOps).
Я не знаю, есть ли способ отключить эту эвристику, но я почти уверен, что это поддельный статус Invalid, т.е. привязка tfs на самом деле работает правильно, и это просто ошибочное сообщение.
Была точно такая же проблема, но затем в рамках Visual Studio 2017.
Отвязывание и повторное связывание не работали для меня. В конце концов я решил эту проблему, отсоединив все проекты в soluting + самом файле решения, а затем выполнил "Получить последнюю версию" для всей ветви. Это привело к серии конфликтов: "Файл с неконтролируемой версией или доступный для записи файл с таким именем уже существует локально". Устранил эти ошибки, выбрав опцию "Перезаписать локальный файлер или папку"
Когда я переименовал свое решение, я столкнулся и с этой ошибкой. Я попробовал все вышеперечисленное, и это не разрешило ситуацию.
Фактическим решением для меня было редактирование определения сборки с новым названием решения
- Мои сборки> Щелкните правой кнопкой мыши по определению сборки> Изменить определение сборки> Процесс
- Обратите внимание, что "1. Обязательный> Решение для сборки" ссылается на старое имя Soluton.
- Нажмите "..." рядом с "Решение для сборки",
- Найдите свое новое решение. Нажмите его
- Сохранить определение сборки
- перестраивать
Я вижу здесь множество ответов, предлагающих разные решения. У меня такое случалось несколько раз в прошлом, и обычно отвязывание / повторное связывание помогало. Однако я недавно боролся с этой проблемой, и, похоже, НИЧЕГО не работало.
Итак, я просто удалил каталоги решений на своей машине, а затем получил последнюю версию из источника. Работал как шарм. Однако все мои изменения были зарегистрированы, поэтому мне не пришлось беспокоиться о том, что что-то потеряю. YMMV.
Я собираюсь добавить это здесь, потому что я столкнулся с одним из вариантов и должен был найти решение самостоятельно.
TL; DR::
1) Убедитесь, что проект не привязан.
2) Вручную выберите все файлы проекта и добавьте их в sourcecontrol (не в сам проект) - это должно создать корневую папку проблемного проекта в TFS
3) В проводнике управления версиями перейдите в корневую папку проблемного проекта и вручную добавьте его.csproj для управления версиями
И полный рассказ о том, как / почему я туда попал:
ЕСЛИ все вышеперечисленные ответы не работают (* ответ adospace может быть связан с этим, но я этого не совсем понял:P)
В моем решении было 2 проекта из 9, которые были чисто ресурсными. Когда я перенес все это в tfs и сопоставил его с системой управления версиями, они решительно останутся с недопустимыми привязками (только два проекта ресурсов), я ничего не исправил. Когда я наконец попытался вручную добавить отдельные файлы проекта в tfs (.resx), TFS выдала предупреждение об игнорировании файлов, как и.exes, чего он никогда не делал ни разу при добавлении - переназначении - исправлении моего решения. Предупреждение позволило мне в любом случае добавить файлы в TFS и в то же время создать полную структуру папок проекта, в то время как сами проекты остались полностью несвязанными. Но оттуда я смог вручную добавить каждый.csproj в TFS, и волшебным образом проекты теперь правильно связаны и находятся под контролем версий. Я'Я не уверен, почему эти типы файлов игнорировались из-за добавления в систему управления версиями, это могут быть некоторые настройки по умолчанию в TFS или VS.
Убедитесь, что решение уже добавлено в систему контроля версий: "Файл"> "Управление версиями"> "Добавить решение в систему управления версиями".