Visual Studio发布Web对话需要花费很多时间来加载

问题描述

每当我启动针对特定项目的Visual Studio 2015发布Web对话（或Visual Studio 2013，都具有相同的问题）时，打开它需要大约20-30秒。同样，当我在发布配置文件之间进行切换时，我切换到特定的时间需要相同的时间量。当我在列表（从配置文件B）切换到配置文件A时，它需要与启动对话本身一样的时间。当我从个人资料A切换到个人资料B时，根本就不需要任何时间。

有没有人有任何想法？我单独在这个问题上每天损失20-30分钟。

我已经检查了XML（ .pubxml ），除了服务器上的站点名称以及 Web.config SQL字符串转换结果外，它们是相同的。 （他们都发布到相同的服务器端点，两者都预编译为所有页面/控件设置为一个程序集，唯一的区别是配置文件的名称以及站点的名称。 / p>

我还检查了个人资料 .user 文件，两者都是相同的再次。我很失望，这里可能是什么问题。

请注意，发布根本不需要很多时间。配置文件A需要与配置文件B一样长时间发布。

此外，即使在我的旧版Visual Studio 2015安装之前，我仍然重新安装了Windows。 （当我升级到Windows 10，我完全重新安装Windows ）。

我可以接受任何和所有想法，我可能会重新安装Visual Studio 2015 再次查看问题是否消失。

进一步说明：在加载对话框时，它会将Visual Studio锁定完全

更新：重新安装Visual Studio完全没有解决问题。

另一个更新：偶尔，打开对话框时，Visual Studio完全崩溃。

解决方案

TL; DR：解决这个问题的办法，找到从 IdentityDbContext 继承的 DbContext 类，并将基类构造函数从 base（DefaultConnection）到 base（DefaultConnection，false）和进行完全重建在你的解决方案这将禁用对Entity 1.0.0的检查，当从Publish Web运行时会导致超时。

调试结果 调试，我们发现根本原因。

1. 当您在项目中运行使用Code-First时发布Web时，将会要枚举可用的连接字符串以检测您的数据库。


2. 为此，它将调用您的 DbContext 类，定位它反映并在VisualStudio的过程中调用它。


3. 不幸的是，由于它在VisualStudio中执行， ConnectionManager 将使用 devenv.exe.config 而不是您的 web.config ，因此您的 web.config 其连接字符串被忽略。


4. 一旦您以的形式调用 IdentityDbContext<> base（DefaultConnection）， base（DefaultConnection，true），其中（根据第二个参数）您的数据库是否使用Identity 1.0.0模式。


5. 为了做到这一点，它将尝试连接到您的数据库，通过连接名称传递给 IdentityDbContext<> （通常会是DefaultConnection）


6. 由于 web.config 未加载，具有此类名称的连接字符串将不可用。



7. 对于不可用的连接字符串，Entity将调用 DefaultConnectionFactory 。再次，您不能自定义它，因为 web.config 未加载。默认情况下， DefaultConnectionFactory 将尝试连接到 .\SQLEXPRESS 与初始目录 =您的连接名称，可能导致以下连接字符串：

    数据源= .\SQLEXPRESS;初始目录= DefaultConnection;集成安全= True; MultipleActiveResultSets = True 
     




8. SQL Express已安装，这将导致SQL异常，这将重试无效的尝试连接，直到超时到期。

所以罪魁祸首是Publish Web，它错误地通过反射运行程序集而不加载相应的 web.config 。

---

---

我们开始调试配方：
我们来看看里面发生了什么。

1. 在冻结期间进行一些转储（假设每2-3秒转一次）。为了进行转储，我认为最简单的方法是：下载&运行，并使用上下文菜单在Visual Studio的进程|创建转储|创建Minidump ...


2. 分析转储。最简单的方法是使用


3. 检查堆栈中的堆栈（从分析结果中的 STACK_TEXT 开始）


4. 堆栈上的函数名称已经可以告诉你有什么问题。


5. 如果本指南不能帮助你，我将需要看到我自己的转储。请注意，转储将包含部分VS的内存，其中可能包含一些个人信息，例如文件路径。

更新

现在OSR的分析无法分析转储中的堆栈，似乎我们必须这么做。

一次性准备

1. 安装用于Windows的调试工具作为（清除所有其他复选框以安装不需要的内容）


2. 从已安装的软件包运行 WinDBG（X86）



3. 在文件中符号文件路径... 写

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




4. 按文件|保存工作区

分析转储

1. 在WinDBG中，按文件|打开崩溃转储... 并打开转储。


2. 在底部的编辑框中，写入！analyze -v 并按回车。


3. 检查堆栈。

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.

解决方案

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.

这篇关于Visual Studio发布Web对话需要花费很多时间来加载的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！