Почему так долго загружается мое решение в Visual Studio?

У нас действительно большое решение с более чем 200 проектами и тысячами файлов. Несмотря на это, решение использовалось довольно быстро для загрузки в Visual Studio 2010, а также в 2012 году. Однако после копирования всего хранилища SVN в другое место загрузка и закрытие решения неожиданно заняло слишком много времени. (Я говорю о 30-60 минутах здесь!)

14 ответов

Решение

Я сам нашел решение и хотел поделиться им здесь, надеясь, что оно может сэкономить кому-то немало часов на исследования, и уставиться на диалог "Подготовка решения...".

При проверке процесса devenv.exe с помощью Process Monitor я обнаружил, что он довольно занят доступом к .svn каталог. Вот что я сделал (и это как-то решило проблему):

  1. Убить Visual Studio
  2. Откройте Visual Studio без загрузки решения
  3. Отключите AnkhSvn как плагин управления источником (Инструменты-> Параметры-> Контроль источника-> Выбор плагина-> Нет)
  4. Отключите "Document Well 2010 Plus" (VS2010) или "Custom Document Well" (VS2012) в разделе "Инструменты для повышения производительности" ("Инструменты" -> "Параметры" -> "Инструменты для повышения производительности") - где-то я это читал, и это также могло бы помочь...
  5. Закрыть Visual Studio
  6. Удалить решение *.suo файл. Он находится в той же папке, что и само решение. ПРИМЕЧАНИЕ. Вы потеряете несколько настроек своего решения, таких как открытые в данный момент файлы, точки останова, закладки, текущая конфигурация решения и платформа (например, Debug x86) и т. Д.
  7. Перезапустите Visual Studio
  8. Загрузите решение - теперь это было намного быстрее!
  9. Закрыть Visual Studio
  10. Откройте Visual Studio без загрузки решения
  11. Повторно включите AnkhSvn и "Document Well"
  12. Перезапустите Visual Studio
  13. Откройте решение - оно было загружено за считанные секунды!

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

Ничто из этого не помогло мне, чем я занимался... Я смотрел с ProcMon sysinternals, фильтруя по devenv, и я видел много записей в fussionlog. Несколько недель назад я включил fussionlog для целей отладки и не думал отключать его. Мне просто пришлось отключить fussionlog, и решение открылось быстрее.

Вы можете открыть Visual Studio в безопасном режиме, а затем проверить настройки своего плагина и контроля версий после открытия проекта. Безопасный режим означает "Запускает Visual Studio, загружая только среду и службы по умолчанию".

Как:

devenv /SafeMode 

Или по твоему пути

"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" /SafeMode

источник: https://msdn.microsoft.com/en-us/library/ms241278.aspx

В моем случае следующее работало без каких-либо предложенных промежуточных шагов:

  1. Убей Visual Studio.
  2. Запустите Visual Studio напрямую (т.е. не из файла.sln).
  3. Затем из Visual Studio откройте решение.

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

Ни один из других ответов не работал для меня. Время компиляции CI прошло хорошо, но загрузка моего решения в Visual Studio заняла почти две минуты. VS будет работать нормально, пока я не закрою и не открою решение в следующий раз. Различные версии VS показали одинаковую проблему, и безопасный режим, и удаление suo не помогли.

Я закончил тем, что следовал совету в http://geekswithblogs.net/akraus1/archive/2014/04/30/156156.aspx чтобы использовать Windows Performance Recorder для инструмента VS и найти проблему. Посмотрев анализатор производительности Windows в разделе "Загрузка ЦП (Sampled)" и добавив столбец "Stack (Frame Tags)", я смог разобраться в использовании devenv.exe,

Оказывается, горячий путь по количеству Microsoft.VisualStudio.Platform.WindowManagement.ni.dll 23 звонка вниз и ниже этого в итоге Microsoft.VisualStudio.ServerExplorer.dll а также Microsoft.VisualStudio.Data.Package.dll, Это указывало на то, что я посмотрел в Server Explorer в пользовательском интерфейсе и открыл вкладку Data Connections. Там я нашел сотни ошибочно добавленных соединений, которые пришли из отладки web.configраздел ConnectionString. Удаление тех из web.config уменьшена загрузка этого отдельного проекта с 90+ секунд до почти мгновенного.

Между прочим, я понимаю, что это поздняя запись, но я обнаружил, что простое удаление (удаление) моего большого количества точек останова решило чрезмерное время загрузки и время компиляции. Это действие уменьшило размер файла.suo с 214 МБ до 977 КБ. Пусть VS обрабатывает сам файл.suo. Компиляция и загрузка теперь занимают < 1 минуту вместо 5-10 минут для решения с 35 проектами. Visual Studio 2012 Pro, обновление 4.

У меня другая причина медленной загрузки проектов.

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

Решение. Запустите Visual Studio от имени администратора.

Причина: что-то с корпоративным ноутбуком не обеспечивает необходимый доступ к инструменту Git (он не распознает, что используется репозиторий git).

Я не видел никаких проблем с Git или моим личным доступом к каким-либо файлам проекта или объектам Git.

В VS2022 я снял флажок «Обновление обозревателя решений обновляет состояние системы управления версиями» перед открытием решения. Я проверил это еще раз, потому что это происходит не для всех решений.

В моем случае были записи <import ...> в файлах проекта, которые указывали на пути, которые больше не доступны, из-за чего загрузка решения зависала на неопределенный срок без какой-либо информации (позор Microsoft!).

В моем случае это было связано с проблемой TFS. Он считает, что ожидающих изменений более 5000.

Исправление - заставить TFS перепроверить. Перейдите в Team Explorer -> Source Control Explorer и сделайте «Получить последнюю версию» для проектов, в которых есть ожидающие изменения. Для вещей, которые уже соответствуют TFS, Visual Studio фактически ничего не загружает на ваш компьютер. Что касается вещей, которые отличаются от TFS, Visual Studio сообщит вам об этом и попросит согласовать разницу.

Это VS 2019 Professional.

Не стесняйтесь перечислять свой случай и решение в этой вики-сообществе.

Дело 1

Используя эту установку для VS22, работая в проекте .NET MAUI, я смог снова заставить ее работать после:

  1. Отбрасывая некоторые изменения, которые я внес в некоторые*.xamlи*.xaml.csфайлы и
  2. После удаления*.csproj.user

Но я предполагаю, что, несмотря на то, что ранее я реализовал несколько возможных решений, это то, что шаг 2 внес исправление. Сравнение старых и новых файлов привело меня к выводу, что недостающее дополнениеios-arm64вызвало проблему (см. файлы здесь). После этого изменения IDE работает как обычно.

Используя Visual Studio 2015, я в итоге создал новое решение, добавив существующие проекты.

Удаление *.suo из ответа gehho помогло в прошлом, но не помогло мне в этом случае. Еще один файл.suo находится в скрытой папке.vs в корне решения.

Есть другие ответы здесь для Visual Studio 2015 Visual Studio 2015 очень медленно

Я попробовал выше, но это не решило мою проблему.

Вот как я справился с этой проблемой, надеюсь, она подойдет и некоторым из вас:

  1. Откройте Visual Studio 2013 без решения.
  2. Создайте новое консольное приложение C# и сохраните его.
  3. Закройте Visual Studio.
  4. Снова откройте консольное решение, созданное на шаге 2.
  5. Закройте Visual Studio.
  6. Снова откройте решение, которое ранее висело в диалоговом окне "Подготовка решения". Шахта открылась сразу, больше не висела.

Я столкнулся с этой проблемой совсем недавно (март 2021 г.), используя VS 2019. Загрузка файла (каждого) занимает буквально 30+ секунд. Это влияет только на файлы макета. Я считаю, что это могло быть связано со ссылками в файлах. У меня не было времени исследовать их. Однако я пишу это, чтобы предположить, что независимо от причины проблемы, простое решение - щелкнуть файл правой кнопкой мыши и открыть его с помощью Блокнота, чтобы выполнить свою работу.