Подтвердить что ты не робот

Visual Studio постоянно висит во время сборки

Вероятно, между 25 и 50% случаев, когда я создаю свое решение, я вижу следующее:

" Запрошенная операция занимает больше времени, чем ожидалось. Это диалоговое окно закрывается после завершения действия."

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

Мое решение составляет около 60 проектов, в основном это библиотеки классов С#, в которых есть несколько веб-приложений, веб-сервисов и консольных приложений. Однако проблема сохраняется даже при создании одного фрагмента кода, при этом большинство (50) проектов не загружаются.

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

Что я могу сделать, чтобы диагностировать и устранять это из моего решения, чтобы я никогда больше его не видел? В общем, как я могу диагностировать проблемы, возникающие во время сборки?

4b9b3361

Ответ 1

Если бы аналогичная проблема, VS будет висеть в течение 45 или около того секунд, то построить в течение 4 секунд и завершить. 45 секунд зависания не выдавали бы никакого результата в GUI, и VS зависал.

Используя ProcMon, я мог видеть 3 миллиона операций с файлами в папке/packages/через файл devenv.exe, когда я буду строить этот проект (и будет продолжаться некоторое время после)! На первых шагах сборки вы можете увидеть, что он проверял КАЖДЫЙ ПАКЕТ, чтобы увидеть, нужно ли ему восстанавливать пакет (это не так)

Поскольку я склонен обвинять NuGet во всем, я отключил Nuget Package Restore "разрешить загрузку пакетов NuGet" в разделе Visual Studio → Параметры → Диспетчер пакетов Nuget → Общие. К моему удовольствию, сборка была очень быстрой. Всего 5 секунд!

Оказывается, что мы включили восстановление пакета при включенной сборке (я думаю, что он по умолчанию включен в VS). И мы также проверили пакеты в исходном элементе управления. Кажется, это заставляет TFS трясти каким-то образом... проверка на восстановление пакета должна инициировать TFS для выполнения некоторых проверок операций управления версиями.

FYI это было VS2013 UPDATE 4 - версия Nuget: 2.8.50926.663.. на sln с NumberOfProjects = 38, но я мог бы воссоздать это зависание, просто строя один csproj с 2 зависимостями.

Обновление:

Локальный хост "Перестроить все" на Sln с SccNumberOfProjects = 53 принимал 7:05 с 2-минутной визуальной студией, замороженной/не отвечающей

  • до 4:14 на двухъядерном i5 без замораживания
  • до 2:44 на 4 ядре i7

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

Ответ 2

Я видел это в больших проектах, когда MSBuild работает с включенным диагностическим переключателем. В Visual Studio перейдите в Инструменты/Параметры/Проекты и Решения /Build And Run, затем проверьте значение многостраничной версии сборки проекта MSBuild. Если он не установлен в Minimal, попробуйте установить минимальное значение и посмотрите, могут ли ваши сборки выполнить.

Ответ 3

Было высказано предположение о Microsoft Connect, что проект моделирования отвечал за замораживание. Я удалил проект моделирования из нашего решения и с тех пор не замораживал (около недели).

Ответ 5

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

Вышеупомянутая настройка может быть установлена ​​в Tool -> Options -> Projects and Solutions -> Build and Run.

Ответ 6

Для меня проблема заключалась в расширении, которое автоматически запускает шаблоны T4 при сборке (AutoT4). Отключение его при работе с решениями с EF исправило проблему.

Ответ 7

Я обнаружил, что Visual Studio очень много висит над созданием больших проектов. Оказывается, это был ReSharper. После того, как я отключил его: Tools → Options → ReSharper → Suspend Now, все построено без проблем (даже на очень больших решениях, более 100 проектов)

Ответ 8

Я переместил платформу разработки VS 2008 с Windows 7 на Windows 10 и столкнулся с ситуацией, когда Visual Studio зависала каждый раз, когда я пытался построить большой проект. Мне пришлось создать проект, а затем использовать диспетчер задач, чтобы убить VS, а затем перезапустить. Излишне говорить, что это сделало отладку действительно трудной! Во всяком случае проблема заключалась в том, что при переходе на Win 10 VS больше не выполнялся как администратор (и, возможно, Win 10 более определенно относится к привилегиям). Изменение свойств так, что программа запускалась, когда администратор разрешил проблему. (IngoB - У меня недостаточно информации, чтобы прокомментировать ваше сообщение, но спасибо, что указали это!)