Зависает visual studio 2019
Вероятно, между 25 и 50% случаев, когда я создаю свое решение, я вижу следующее:
Моя проблема заключается в том, что окна вывода ничего не говорят мне в тот момент, когда он зависает, и я не знаю, как еще определить причину этой блокировки. Если бы я мог догадаться, я бы предположил, что это тупик в файловой системе или что-то в этом роде, но я не знаю, как это доказать, а тем более как предотвратить это.
Что я могу сделать, чтобы диагностировать и устранять это из моего решения, чтобы я никогда больше его не видел? В общем, как я могу диагностировать проблемы, возникающие во время сборки?
Если бы аналогичная проблема, 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
Также: это было на машине с различными инструментами защиты файлов файлов, что, вероятно, не добавило скорости для всего этого процесса. и, возможно, виноват.
Вероятно, между 25 и 50% случаев, когда я строю свое решение, я вижу это:
Моя проблема в том, что выходные окна ничего не говорят мне в тот момент, когда они зависают, и я не знаю, как еще определить причину этой блокировки. Если бы я догадался, я бы предположил, что это тупик в файловой системе или что-то в этом роде, но я не знаю, как это доказать - тем более, как предотвратить это.
Что я могу сделать, чтобы диагностировать и устранить это из моего решения, чтобы я больше никогда его не видел? В общем, как я могу диагностировать проблемы, возникающие во время сборки?
Если бы схожая проблема, VS зависал в течение примерно 45 секунд, затем собирался в течение 4 секунд и завершал работу. 45 секунд зависания не приведут к выводу GUI, а VS зависнет.
Используя ProcMon, я мог видеть более 3 миллионов операций с файлами в папке/packages/через devenv.exe, когда я собирался построить этот проект (и продолжу некоторое время после этого) !! Первые шаги сборки показывают, что он проверял КАЖДЫЙ ПАКЕТ на предмет необходимости восстановления пакета (это не так).
Поскольку я склонен винить во всем NuGet, я отключил восстановление пакета Nuget «разрешить NuGet загружать отсутствующие пакеты» в поле Visual Studio -> Параметры -> Диспетчер пакетов Nuget -> Общие. К моему удовольствию, сборка была очень быстрой. Всего 5 секунд!
Оказывается, у нас было включено восстановление пакетов при сборке (я думаю, что это включено по умолчанию сейчас в VS) И мы также проверили пакеты в системе контроля версий. Похоже, что это приводит к некоторому перебору TFS . проверка на восстановление пакета должна инициировать TFS для выполнения некоторых проверок работы системы контроля версий.
К вашему сведению, это было VS2013 ОБНОВЛЕНИЕ 4 - Nuget версия: 2.8.50926.663 .. на sln с NumberOfProjects = 38, но я мог бы воссоздать это зависание, просто создав один csproj с 2 зависимостями.
Локальный хост «Rebuild All» на Sln с SccNumberOfProjects = 53 занимал 7:05 с 2 минутами визуальной студии, замороженной/не отвечающей
- до 4:14 на 2-ядерном i5 без заморозки
- до 2:44 на 4-ядерном i7
Кроме того: это было на машине с различными инструментами безопасности наблюдателя файлов, вероятно, не увеличивающими скорость всего этого процесса . и, возможно, виноватыми.
Я видел это в больших проектах, когда MSBuild работает с включенным диагностическим переключателем. В Visual Studio перейдите в Инструменты/Параметры/Проекты и решения/Построить и запустить, а затем проверьте значение детализации выходных данных сборки проекта MSBuild. Если он не установлен как минимальный, попробуйте установить минимальный и посмотреть, смогут ли ваши сборки завершиться.
Похоже, что запуск Visual Studio в качестве администратора решил проблему для меня! (Для того, чтобы всегда запускать программу от имени администратора см. Как запустить Visual Studio от имени администратора по умолчанию )
Я обнаружил, что Visual Studio сильно зависает при создании больших проектов. Оказывается, это был ReSharper. После того, как я выключил его: Инструменты -> Параметры -> ReSharper -> Приостановить сейчас, все прекрасно работало без проблем (даже на очень больших решениях, более 100 проектов)
Было высказано предположение о том, что Microsoft Connect что проект зависел от зависаний. Я удалил проект моделирования из нашего решения и с тех пор не зависал (около недели).
В моем случае установка «максимальное количество параллельных сборок проекта» на 1 вроде помогла (т.е. сборка проекта из чистого состояния вызывает 1-минутное замораживание с последующей нормальной сборкой, и каждая последующая сборка работает нормально).
Вышеупомянутая настройка может быть установлена в Tool -> Options -> Projects and Solutions -> Build and Run .
Просто попробуйте команду ниже в режиме администратора. Перед запуском этой команды обязательно закройте все экземпляры VS.
Примечание: devenv находится в C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE.
Для меня это было связано с автоматической установкой пакета npm. Я пошел в Инструменты> Параметры> Проект и решения> Внешние веб-инструменты и снял флажки со всех внешних инструментов и перезапустил VS. После этого я смог построить его снова. Я знаю, что мне нужно проверить их, но мне нужно выяснить, что их вызывает и что не так с этим файлом решения.
Visual Studio 2017
Удаление Anaconda3 из установки исправило его. В procmon я видел сотни тысяч звонков в поисках файлов в папке Anaconda3 из сотен экземпляров powershell, порожденных msbuild.
В дополнение к ответу Феликса который решает (или почти решает) эту проблему для сборок:
Кроме проблемы во время сборки, у меня также была проблема с Консолью управления пакетами. Ожидание заняло около минуты. Используя procmon, я обнаружил, что папка репозитория NuGet анализировалась при каждом открытии этого окна (очень умно, Microsoft!). В этой папке было около 1000 пакетов. После удаления всего из вышеуказанной папки проблема с производительностью исчезла.
Обратите внимание, что мой ответ относится к VS 2015 (и может быть ниже). Я не проверял, но подозреваю, что в VS 2017 все должно быть в порядке.
Для меня проблема заключалась в расширении, которое автоматически запускает шаблоны T4 при сборке (AutoT4). Отключение при работе с решениями с EF решило проблему.
Проблема 1) Cтабильно после закрытия моего приложения, запущенного из-под Visual Studio 2019 (билд 16.8.2)
VS начинает что-то делать усиленно секунд 30-60 после чего выдает ошибки (см.аттач).
Could not retrieve IDesignToolClient for project Personal.
The connection to the server has been lost.
То ли коннектится куда . на какой то сервер. Какие то внутренние процессы запускает .
Проблема 2) Рендеринг даже простых и почти пустых форм в дизайн-тайме в VS стал дико тормозить и выдавать ошибки (см.аттач)
И не только рендеринг, но и просто открытие cs-файлов, кликом на Solution Explorer тоже работает не быстро.
Вот такие траблы с VS.
На пустом проекте не тормозит и не выдает ошибки.
Возможно виноваты мои контролы, сделанные на основе UserControl, да их неправильно оформил.
Вот и гадаю,
то ли я криво перешел на Core, то ли рендеринг WinForms под Core еще сырой.
VS переустанавливал, не помогло.
Однако дикие тормоза в разных местах (при правках кода, при переключении Code/Form, после остановки программы, запущенной из среды и т.д. остались.
Сегодня VS полоской сверху сообщила об ошибке среды (увидел в Activity Monitor Log
Я использую компоненты DevExpress для Winforms for Core, и консультировался у них, не из-за их ли компонентов столько багов в DesignTime.
Пока не понял из-за DevExpress или нет, но дали ссылку
см.абзац под подзаголовком "Now the Bad News – Known Issues"
Есть еще вот эта статья, правда не особо помогла мне
Ошибки дизайнера форм последнее время перестали выдаваться, не понял после чего.
Теперь попробую поставить вопрос проще.
После остановки Debug'а проги (трассировки), да и просто остановки в возврата в Visual Studio, студия через 2-3 сек начинает что-то усиленно делать - то ли вычищает что-то, но делает это секунд 20-30 с показом WaitCursor и VS не отвечает ни на какие действия мыши и клавиатуры.
С этим подзависоном приходится жить, хотя сложно. Хочется избавиться. Переустановка VS не помогла. И на другом ПК тоже самое.
Что-то в проекте Core 3.1 полагаю.
Что за /censored/.
Вэб приложение, в режиме отладки, даже, когда ничего не происходит,
отгребает процесс DevEnv.exe порядка 20% CPU.
Вот чем он занят.
Я получил новый NoteBook, поставил на нем всё с нуля — та же "нехорошесть", что и на старом
Здравствуйте, Yuri Abele, Вы писали:
YA>Привет!
YA>Что за /censored/.
YA>Вэб приложение, в режиме отладки, даже, когда ничего не происходит,
YA>отгребает процесс DevEnv.exe порядка 20% CPU.
YA>Вот чем он занят.
YA>Я получил новый NoteBook, поставил на нем всё с нуля — та же "нехорошесть", что и на старом
Может из-за "Enable Diagnostic Tool while debugging". Но дебаг в любом случае медленнее релиза.
Re[2]: Visual Studio 2019 - дико тормозит в debug режиме в idle состоянииB_R>Может из-за "Enable Diagnostic Tool while debugging".
Попробую
B_R>Но дебаг в любом случае медленнее релиза.
Это если о самом приложении речь вести, а тут Visual Studio
Оно (Visual Studio) вообще отгребает это 20% CPU, даже, если не в отладке находится.
Причем именно, что сам DevEnv.exe, а не его дочерние процессы.
И Resource Monitor показывает, что сеть и диск не напрягаются, а вот CPU прям сильно сильно
Если открыть VS без проекта, то тихо всё, такое только с подгруженным проектом.
Re[3]: Visual Studio 2019 - дико тормозит в debug режиме в idle состоянииЗдравствуйте, Yuri Abele, Вы писали:
B_R>>Может из-за "Enable Diagnostic Tool while debugging".
YA>Попробую
B_R>>Но дебаг в любом случае медленнее релиза.
YA>Это если о самом приложении речь вести, а тут Visual Studio
YA>Оно (Visual Studio) вообще отгребает это 20% CPU, даже, если не в отладке находится.
YA>Причем именно, что сам DevEnv.exe, а не его дочерние процессы.
YA>И Resource Monitor показывает, что сеть и диск не напрягаются, а вот CPU прям сильно сильно
YA>Если открыть VS без проекта, то тихо всё, такое только с подгруженным проектом.
Ты что думаешь все эти рюшечки, подсветка синтаксиса, рефакторинг это забесплатно?
Здравствуйте, Yuri Abele, Вы писали:
YA>Привет!
YA>Что за /censored/.
YA>Вэб приложение, в режиме отладки, даже, когда ничего не происходит,
YA>отгребает процесс DevEnv.exe порядка 20% CPU.
YA>Вот чем он занят.
YA>Я получил новый NoteBook, поставил на нем всё с нуля — та же "нехорошесть", что и на старом
Здравствуйте, Danchik, Вы писали:
D>Ты что думаешь все эти рюшечки, подсветка синтаксиса, рефакторинг это забесплатно?
1)Речь о дебаге, причем здесь рефакторинг?
2)Неужели рюшечки требует постоянно 20% цпу, даже когда программист код не пишет?
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, Danchik, Вы писали:
D>>Ты что думаешь все эти рюшечки, подсветка синтаксиса, рефакторинг это забесплатно?
S>1)Речь о дебаге, причем здесь рефакторинг?
S>2)Неужели рюшечки требует постоянно 20% цпу, даже когда программист код не пишет?
Какого-то милого да, и без дебага. Бывает зациклится и херячит, бывает долго индексирует.
Re[6]: Visual Studio 2019 - дико тормозит в debug режиме в idle состоянииЗдравствуйте, Danchik, Вы писали:
S>>1)Речь о дебаге, причем здесь рефакторинг?
S>>2)Неужели рюшечки требует постоянно 20% цпу, даже когда программист код не пишет?
D>Какого-то милого да, и без дебага. Бывает зациклится и херячит, бывает долго индексирует.
Какого размера должны быть проекты на современных мощностях?
Re[7]: Visual Studio 2019 - дико тормозит в debug режиме в idle состоянииЗдравствуйте, Sharov, Вы писали:
D>>Какого-то милого да, и без дебага. Бывает зациклится и херячит, бывает долго индексирует.
S>Какого размера должны быть проекты на современных мощностях?
Скорее всего топик стартер не сказал о своих любимых перманентно глючащих расширениях (решарпер? я х.з.). Студия конечно не сахар, особенно когда надо дебажить нэйтив с суммарным размером отладочной информации за несколько гигов. Но эти песни что оно просто так жрёт — это или от её субпроцессов (которые бывают выбрыкиваются), или всё же от своих любимых недорасширений которые работать правильно так и не научились (тут уж не знаю какие). Стандартная студия работает отлично в любых условиях.
Re[8]: Visual Studio 2019 - дико тормозит в debug режиме в idle состоянииЗдравствуйте, Mystic Artifact, Вы писали:
MA>Скорее всего топик стартер не сказал о своих любимых перманентно глючащих расширениях (решарпер? я х.з.). Стандартная студия работает отлично в любых условиях.
Вот долго не мог пересесть со студии на райдер, все время что-то не хватало в ней, но тормоза и постоянные фризы студии заставили таки пересесть. И текущий райдер уже в принципе радует, есть мелочи, но все же. А вот студия на нашем проекте продолжает фризится даже без решарпера, что печально, так как студия мне в целом нравится. У нас тоже студия время от времени в простое на 15-25 процентов грузила проц, но по сути, грузились 1-2 ядра на 100%.
Re[8]: Visual Studio 2019 - дико тормозит в debug режиме в idle состоянииЗдравствуйте, Mystic Artifact, Вы писали:
MA>Здравствуйте, Sharov, Вы писали:
D>>>Какого-то милого да, и без дебага. Бывает зациклится и херячит, бывает долго индексирует.
S>>Какого размера должны быть проекты на современных мощностях?
MA> Стандартная студия работает отлично в любых условиях.
Вот чушь сказал неподумав. Нет идеального софта, есть идеальные условия.
У меня студия время от времени недюжие цирки в анализаторе выкидывает. И CPU жрет без останову. Выключаешь Решарпер, ничего не меняется.
Конечно же зависит от проекта. Чуть посложнее дженерики, деревья выражений — печаль.
Скачал VS2019. Пробный период истек сегодня, появляется диалоговое окно входа:
Нажимаю "Войти", появляется пустое окно с окном ошибки выполнения скрипта. Нажимал"Да" и "Нет" на результат в итоге не влияет.
Окно с ошибкой скрипта появляется еще 2 раза:
Окно логина. Захожу по номеру телефона.
Ошибка: Браузер устарел. Пользуюсь последней версией Chrome, специально установил Edge для решения проблемы и перезагрузил компьютер, ошибка осталась.
Вас перекинет в параметры, где будет учетная запись, там будет написано "Встроенный веб-браузер"
Нажимаем на нижнюю стрелку.
Меняем "Встроенный веб-браузер" на "Системный веб-браузер"
После этого нажимаете "ОК", а дальше нажимаете войти и вас перекинет в браузер и вы можете спокойно авторизоваться.
Читайте также: