Visual Studio Publish Web Dialogue занимает слишком много времени для загрузки

Всякий раз, когда я запускаю Visual Studio 2015 Publish Web Dialogue (или Visual Studio 2013, обе имеют ту же проблему) для конкретного проекта, для его открытия требуется ~ 20-30 секунд. Точно также, когда я переключаюсь между публикациями профилей, он принимает такое же количество времени, когда я переключаюсь на конкретный. Когда я переключаюсь на профиль A в списке (из профиля B), он занимает столько же времени, сколько и при запуске самого диалога. Когда я переключаюсь с профиля A на профиль B, он не занимает какое-то время.

Есть ли у кого-нибудь идеи по этому поводу? Я теряю 20-30 минут в день развития только по этой проблеме.

Я проверил XML (.pubxml) в обоих профилях, и они идентичны, за исключением имени сайта на сервере, и результата преобразования строки Web.config SQL. (Оба они публикуются в одной конечной точке сервера, оба предварительно скомпилированы со всеми страницами/элементами управления, установленными на одну сборку, единственное различие - это имя профиля и имя сайта.)

Я также просмотрел файл профиля .user, и оба они снова идентичны. Я затрудняюсь с тем, что может быть проблемой здесь.

Заметьте, что публикация не занимает много времени. Это займет столько же времени, когда профиль A будет опубликован в виде профиля B.

Кроме того, эта проблема присутствовала даже на моей старой установке Visual Studio 2015, прежде чем полностью переустановить Windows. (И я полностью переустанавливал Windows, когда обновлялся до Windows 10.)

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

Дальнейшие примечания: во время загрузки диалога он полностью блокирует Visual Studio.

Обновление: переустановка Visual Studio полностью не исправила проблему.

Другое обновление: иногда Visual Studio полностью отключается при открытии диалога.

Ответы

Ответ 1

TL; DR:. В качестве обходного пути для этой проблемы найдите свой класс DbContext, который наследует от IdentityDbContext<> и изменит конструктор базового класса от base("DefaultConnection") до base("DefaultConnection", false) и сделайте полную перестройку в своем решении. Это отключит проверку на Entity 1.0.0, которая вызывает тайм-ауты при запуске из Publish Web.

Результаты отладки: После большой отладки мы обнаружили основную причину.

  • Когда вы запускаете Publish Web с использованием кода-первого, используемого в вашем проекте, он захочет перечислить доступные строки подключения, чтобы обнаружить ваши базы данных.
  • Чтобы сделать это, он назовет ваш класс DbContext, найдя его с отражением и вызовет его внутри процесса VisualStudio.
  • К сожалению, поскольку он выполняется в VisualStudio, ConnectionManager будет использовать devenv.exe.config вместо вашего web.config, поэтому ваш web.config с его строками подключения игнорируется.
  • Как только вы назовете IdentityDbContext<> в форме base("DefaultConnection"), он вызволит base("DefaultConnection", true), который (согласно второй параметр) попытается определить, использует ли ваша база данных схему Identity 1.0.0.
  • Чтобы сделать это, он попытается подключиться к вашей базе данных, идентифицированной именем соединения, переданного в IdentityDbContext<> (обычно это будет "DefaultConnection")
  • Так как web.config не загружен, строка подключения с таким именем будет недоступна.

  • Для недоступной строки подключения Entity вызовет DefaultConnectionFactory. Опять же, вы не можете настроить его, так как web.config не загружается. По умолчанию DefaultConnectionFactory попытается подключиться к .\SQLEXPRESS с помощью Initial Catalog= вашего имени соединения, что приведет к следующей строке подключения:

    Data Source=.\SQLEXPRESS;Initial Catalog=DefaultConnection;Integrated Security=True;MultipleActiveResultSets=True

  • Если у вас не установлен SQL Express, это приведет к исключению SQL, которое будет пытаться попытаться подключиться до истечения времени ожидания.

Таким образом, виновником является публикация Web, которая неправильно запускает сборку через отражение без загрузки соответствующего web.config.

Рецепт отладки, с которым мы начали: Дайте понять, что происходит внутри.

  • Сделайте несколько дампов во время замораживания (скажем, дамп каждые 2-3 секунды). Чтобы сделать дамп, я думаю, что самый простой способ: загрузить и запустить SysInternals Process Explorer и использовать Context Menu on Visual Studio process | Create Dump | Create Minidump...
  • Анализ дампов. Самый простой способ - использовать мгновенный анализ OSR
  • Осмотрите стеки в дампах (начиная с STACK_TEXT в результатах анализа)
  • Имена функций в стеке уже могут сказать вам, что не так.
  • Если это руководство вам не поможет, мне нужно будет увидеть свалки. Имейте в виду, что дампы будут содержать части памяти VS, которые могут содержать некоторую личную информацию, такую ​​как пути к файлам.

Обновление

Теперь, когда анализ OSR не смог проанализировать стеки в дампах, кажется, нам придется сделать это с трудом.

Одноразовая подготовка

  • Установите Debugging Tools For Windows как часть Windows SDK (очистите все остальные флажки, чтобы не устанавливать то, что вам не нужно)
  • Запустите WinDBG (X86) из установленного пакета

  • В File | Symbol File Path... напишите

    srv*C:\Symbols*http://msdl.microsoft.com/download/symbols

  • Нажмите File | Save workspace

Анализ дампа

  • В WinDBG нажмите File | Open crash dump... и откройте дамп.
  • В поле редактирования внизу напишите !analyze -v и нажмите Enter.
  • Осмотрите стек.