Visual Studio Publish Web Dialogue takes excessive time to load

Question

Whenever I launch the Visual Studio 2015 Publish Web Dialogue (or Visual Studio 2013, both have the same issue) for a specific project, it takes ~20-30 seconds for it t

Answer 1

TL;DR: As a workaround for this problem, find your DbContext class which inherit from IdentityDbContext<> and change base class constructor from base("DefaultConnection") to base("DefaultConnection", false) and do a full rebuild on your solution. That will disable checking against Entity 1.0.0 which causes timeouts when run from Publish Web.

The results of debugging: After much debugging, we found the root cause.

1. When you run Publish Web with Code-First used in your project, it will want to enumerate available connection strings in order to detect your Databases.
2. To do that, it will call your DbContext class, locating it with reflection and calling it inside VisualStudio's process.
3. Unfortunately, since it's executed within VisualStudio, ConnectionManager will use devenv.exe.config instead of your web.config, hence your web.config with its connection strings is ignored.
4. As soon as you call IdentityDbContext<> in the form of base("DefaultConnection"), it will call base("DefaultConnection", true), which (according to the second parameter) will try to detect whether your database uses Identity 1.0.0 schema.
5. In order to do that, it will try to connect to your database, identified by the name of connection passed to IdentityDbContext<> (usually it will be "DefaultConnection")
6. Since the web.config is not loaded, the connection string with such name would be unavailable.

7. For unavailable connection string, Entity would call DefaultConnectionFactory. Again, you can't customize it, as web.config is not loaded. By default, DefaultConnectionFactory will try to connect to .\SQLEXPRESS with Initial Catalog = your connection name, likely resulting in the following connection string:

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

8. If you do not have SQL Express installed, that will result in SQL exception, which will retry futile attempts to connect until timeout expires.

So, the culprit is Publish Web, which incorrectly runs assembly through reflection without loading the corresponding web.config.

---

---

Debugging recipe we have started with: Let's figure what's happening inside.

1. Make a few dumps during the freeze (let's say a dump every 2-3 seconds). To make a dump, I think the simplest way is this: download & run SysInternals Process Explorer, and use Context Menu on Visual Studio's process | Create Dump | Create Minidump...
2. Analyze dumps. The simplest way would be to use OSR's instant analyze
3. Inspect stacks in the dumps (starting from STACK_TEXT in analysis results)
4. The names of functions on stack can already tell you what's wrong.
5. If this guide does not help you, I will need to see the dumps myyself. Please be aware that dumps will contain portions of VS's memory, which could contain some personal information, such as file paths.

Update

Now that OSR's analyze failed to analyze the stacks in dumps, it seems we'll have to do it the hard way.

One-time preparation

1. Install Debugging Tools For Windows as part of Windows SDK (clear all other checkboxes to not install what you don't need)
2. Run WinDBG (X86) from installed package

3. In File | Symbol File Path... write

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

4. Press File | Save workspace

Analyzing a dump

1. In WinDBG, press File | Open crash dump... and open your dump.
2. In the edit box at the bottom, write !analyze -v and press Enter.
3. Inspect the stack.