问题
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.
回答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.
- 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.
- To do that, it will call your
DbContext
class, locating it with reflection and calling it inside VisualStudio's process. - Unfortunately, since it's executed within VisualStudio,
ConnectionManager
will usedevenv.exe.config
instead of yourweb.config
, hence yourweb.config
with its connection strings is ignored. - As soon as you call
IdentityDbContext<>
in the form ofbase("DefaultConnection")
, it will callbase("DefaultConnection", true)
, which (according to the second parameter) will try to detect whether your database uses Identity 1.0.0 schema. - 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"
) - Since the
web.config
is not loaded, the connection string with such name would be unavailable. For unavailable connection string, Entity would call
DefaultConnectionFactory
. Again, you can't customize it, asweb.config
is not loaded. By default,DefaultConnectionFactory
will try to connect to.\SQLEXPRESS
withInitial Catalog
= your connection name, likely resulting in the following connection string:Data Source=.\SQLEXPRESS;Initial Catalog=DefaultConnection;Integrated Security=True;MultipleActiveResultSets=True
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.
- 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...
- Analyze dumps. The simplest way would be to use OSR's instant analyze
- Inspect stacks in the dumps (starting from
STACK_TEXT
in analysis results) - The names of functions on stack can already tell you what's wrong.
- 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
- Install
Debugging Tools For Windows
as part of Windows SDK (clear all other checkboxes to not install what you don't need) - Run
WinDBG (X86)
from installed package In
File | Symbol File Path...
writesrv*C:\Symbols*http://msdl.microsoft.com/download/symbols
Press
File | Save workspace
Analyzing a dump
- In WinDBG, press
File | Open crash dump...
and open your dump. - In the edit box at the bottom, write
!analyze -v
and press Enter. - Inspect the stack.
来源:https://stackoverflow.com/questions/32846284/visual-studio-publish-web-dialogue-takes-excessive-time-to-load