visual-studiovisual-studio-2013dialogvisual-studio-2015web-publishing

Visual Studio Publish Web Dialogue takes excessive time to load

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 to open. Just as well, when I switch between publish profiles it takes the same amount of time when I switch to a specific one. When I switch to Profile A in the list (from Profile B) it takes the same amount of time as it does when it launches the dialogue itself. When I switch from Profile A to the Profile B it doesn't take any time at all.

Does anyone have any ideas on this? I lose 20-30 minutes a day of development on this issue alone.

I have inspected the XML (.pubxml) on both profiles, and they are identical except for the name of the site on the server, and the Web.config SQL string transformation result. (They both publish to the same server endpoint, both are precompiled with all pages/controls set to one assembly, the only difference is the name of the profile and what the name of the site is.)

I also inspected the profile .user file, and both are identical once again. I am at a loss as to what could be the issue here.

Do note that publishing does not take a lot of time at all. It takes just as long for Profile A to publish as Profile B does.

Also, this issue was present even on my old Visual Studio 2015 installation before I reinstalled Windows completely. (And I did reinstall Windows entirely when I upgraded to Windows 10.)

I am open to any and all ideas, I might reinstall Visual Studio 2015 again to see if the issue goes away.

Further notes: while it is loading the dialogue, it locks Visual Studio up entirely.

Update: reinstalling Visual Studio entirely did not rectify the issue.

Another update: Occasionally Visual Studio crashes completely when opening the dialogue.

Solution

  • 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.