Получить команду зависает с использованием VS 2012 и TFS 2008 (ошибка TFS TF400307)

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

Я использую Visual Studio Premium 2012 с TFS 2008.

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

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

До сих пор я пробовал различные способы запуска команды get: последняя версия, конкретная версия, карта + получать последние, как внутри VS IDE, так и через командную строку. Также многие другие команды TFS работают хорошо.

Edit:

После некоторых проб и ошибок, оставив процесс в течение часа или около того, я, наконец, наткнулся на сообщения об ошибках в окне вывода исходного кода. Первоначально они не были видны, потому что, когда процесс зависал, он не реагировал на всю IDE. Сообщения одинаковы:

[путь к файлу]: TF400307: операция загрузки завершилась после ожидания 599 секунд для ответа с сервера.

Ответы

Ответ 1

У меня была такая же проблема с TFS, где она зависала и становилась невосприимчивой.

Я нашел решение для этого, обновив файл tf.exe.config или devenv.exe.config со следующими значениями конфигурации:

<system.net>
    <connectionManagement>
        <add address="*" maxconnection="1000"/>
    </connectionManagement>
</system.net>

Я установил предел 1000 на моей стороне, так как я внимательно наблюдал за значением в Resource Monitor, хотя по правде говоря, я никогда не получал более 600 параллельных соединений.

Ответ 2

Итак, что происходит, так это то, что клиент TFS в VS 2012 имеет ошибку, из-за чего он запускает тайм-аут во всех файлах через некоторое время в процессе при запуске команды get для большего количества файлов.

Как уже упоминалось в следующем примере подключения к MS Connect, обходным решением является использование более старого клиента TFS для запуска команд тайм-аута. Я успешно использовал клиент TSI командной строки VS 2010, чтобы выполнить проект.

Ответ 3

Столкнувшись с той же проблемой, получившей последнюю версию с VS 2012 от TFS 2008. Используя отладчик и инструмент Fiddler, я смог поймать момент, когда VS зависает. Похоже, что что-то не так, когда VS 2012 получает сжатые HTTP-ответы сервера TFS, он не может их распаковать и зависать. После того, как я отключил сжатие для HTTP-трафика TFS, VS больше не висит. Надеюсь, это поможет кому-то другому.

Чтобы отключить сжатие TFS, создайте значение реестра и перезапустите VS:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\TeamFoundation\RequestSettings EnableCompression (REG_SZ) = "ложь"

Ответ 4

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

Ответ 5

То же самое, вы очень терпеливы! У меня также есть "TF400324: услуги Team Foundation недоступны с сервера xyz. Техническая информация (для администратора):" Операция завершилась "из" Source Control Explorer "после того, как я отменил" Получить последний процесс "и ждал веков. Возможно, это не количество файлов, а количество данных? Он зависает мне после переноса приблизительно 2 ГБ данных, что происходит именно тогда, когда 32-разрядное целое число со знаком переполнено, но это просто подозрение. Билет: https://connect.microsoft.com/VisualStudio/feedback/details/776506/source-control-explorer-getlatest-hangs-after-certain-amount-of-data-transferred-might-be-integer-overflow#tabs

Ответ 6

Я заметил, что когда я вызвал метод CreateWorkspace с новыми сопоставлениями WorkFolders в качестве параметра, он начал вытягивать все файлы (сопоставленные с $/) на локальные, что объясняет длительное время обработки - было изменено на CreateWorkspace с нулевым значением для WorkFolders, чем добавлено следующее шаг, казалось, сделал трюк