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

Ответ 1

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

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

• Убить Visual Studio
• Откройте Visual Studio без загрузки решения
• Отключить AnkhSvn как плагин управления версиями (Tools- > Options- > Source Control- > Plug-in Selection- > None)
• Отключите "Document Well 2010 Plus" (VS2010) или "Custom Document Well" (VS2012) в инструментах для повышения производительности (Tools- > Options- > Performance Power Tools). Я читал это где-то, и это могло бы помочь...
• Закрыть Visual Studio
• Удалить файл решения *.suo. Это расположено в той же папке, что и само решение. ПРИМЕЧАНИЕ.. Вы потеряете несколько параметров для своего решения, например, открытые файлы, точки останова, закладки, текущую конфигурацию решения и платформу (например, Debug x86) и т.д.
• Перезапустить Visual Studio
• Загрузите решение - теперь было намного быстрее!
• Закрыть Visual Studio
• Откройте Visual Studio без загрузки решения
• Восстановить AnkhSvn и "Документ хорошо"
• Перезапустить Visual Studio
• Откройте решение - оно было загружено за считанные секунды!

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

Ответ 2

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

Ответ 3

Вы можете открыть 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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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