Visual Studio 发布 Web 对话的加载时间过长

Question

每当我为特定项目启动 Visual Studio 2015 发布 Web 对话（或 Visual Studio 2013，两者都有相同的问题）时，它需要大约 20-30 秒才能打开。同样，当我在发布配置文件之间切换时，切换到特定配置文件所花费的时间相同。当我（从配置文件 B）切换到列表中的配置文件 A 时，它所花费的时间与它启动对话本身时所花费的时间相同。当我从配置文件 A 切换到配置文件 B 时，根本不需要任何时间。

有人对此有任何想法吗？仅在这个问题上，我每天就会浪费 20-30 分钟的开发时间。

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

我还检查了配置文件.user 文件，两者完全相同再次。我不知道这里可能是什么问题。

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

此外，在我完全重新安装 Windows 之前，即使在旧的 Visual Studio 2015 安装中也存在此问题。 （当我升级到 Windows 10 时，我确实完全重新安装了 Windows。）

我对任何想法持开放态度，我可能会再次重新安装 Visual Studio 2015 以查看问题是否消失。

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

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

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

Answer 1

TL;DR: 作为解决此问题的方法，找到继承自 IdentityDbContext<> 的 DbContext 类并将基类构造函数从 base("DefaultConnection") 更改为 base("DefaultConnection", false) 和 对您的解决方案进行全面重建。这将禁用对 Entity 1.0.0 的检查，这会在从 Publish Web 运行时导致超时。

调试结果：经过很多调试，我们找到了根本原因。

1. 当您在项目中使用 Code-First 运行 Publish Web 时，它需要枚举可用的连接字符串以检测您的数据库。
2. 为此，它将调用您的 DbContext 类，通过反射定位它并在 VisualStudio 的进程中调用它。
3. 不幸的是，由于它是在 VisualStudio 中执行的，ConnectionManager 将使用 devenv.exe.config 而不是您的 web.config，因此您的 web.config 及其连接字符串将被忽略。
4. 只要你以base("DefaultConnection")的形式调用IdentityDbContext<>，it will callbase("DefaultConnection", true)，其中（根据第二个参数）will try to detect你的数据库是否使用Identity 1.0.0架构。
5. 为此，它将尝试连接到您的数据库，由传递给IdentityDbContext<> 的连接名称标识（通常为"DefaultConnection"）
6. 由于未加载web.config，因此该名称的连接字符串将不可用。

7. 对于不可用的连接字符串，实体将调用DefaultConnectionFactory。同样，您无法自定义它，因为未加载 web.config。默认情况下，DefaultConnectionFactory 将尝试使用 Initial Catalog = 您的连接名称连接到 .\SQLEXPRESS，可能会导致以下连接字符串：

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

8. 如果您没有安装 SQL Express，则会导致 SQL 异常，这将重试无效的连接尝试，直到超时到期。

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

---

---

我们开始使用的调试方法： 让我们弄清楚里面发生了什么。

1. 在冻结期间进行几次转储（假设每 2-3 秒转储一次）。要进行转储，我认为最简单的方法是：下载并运行SysInternals Process Explorer，然后使用Context Menu on Visual Studio's process | Create Dump | Create Minidump...
2. 分析转储。最简单的方法是使用OSR's instant analyze
3. 检查转储中的堆栈（从分析结果中的STACK_TEXT 开始）
4. 堆栈上的函数名称已经可以告诉您出了什么问题。
5. 如果本指南对您没有帮助，我需要亲自查看转储。请注意，转储将包含 VS 的部分内存，其中可能包含一些个人信息，例如文件路径。

更新

现在 OSR 的分析无法分析转储中的堆栈，看来我们必须努力做到这一点。

一次性准备

1. 将Debugging Tools For Windows 安装为Windows SDK 的一部分（清除所有其他复选框以不安装您不需要的东西）
2. 从已安装的包中运行WinDBG (X86)

3. 在File | Symbol File Path...写

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

4. 按File | Save workspace

分析转储

1. 在 WinDBG 中，按 File | Open crash dump... 并打开您的转储。
2. 在底部的编辑框中，输入!analyze -v并回车。
3. 检查堆栈。