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

Question

每当我启动Visual Studio 2015发布Web对话框（或Visual Studio 2013，两者都存在同样的问题）用于特定项目时，它需要大约20-30秒才能打开。同样的，在我切换发布配置文件时，当我切换到特定配置文件时也需要相同数量的时间。当我在列表中从配置文件B切换到配置文件A时，它需要和启动对话框本身一样的时间。但是，当我从配置文件A切换到配置文件B时，不需要任何时间。

有人有什么想法吗？这个问题每天会让我因此浪费20-30分钟的开发时间。

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

我还检查了.profile.user文件，两者再次完全相同。我无法确定问题出在哪里。

请注意，发布并没有花费很多时间。与Profile B相比，Profile A的发布时间同样短。

另外，甚至在我完全重新安装Windows之前，这个问题就一直存在于我的旧的Visual Studio 2015安装中。（当我升级到Windows 10时，我确实完全重新安装了Windows。）

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

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

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

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

- Der Kommissar

Answer 1

为解决此问题，找到继承自IdentityDbContext<>的DbContext类，并将其基类构造函数从base("DefaultConnection")改为base("DefaultConnection", false)，然后在解决方案中进行完全重建。这将禁用针对实体1.0.0的检查，该检查在从发布Web运行时会导致超时。

调试结果：经过大量调试，我们找到了根本原因。当您在项目中使用 Code-First 运行 Publish Web 时，它会希望枚举可用的连接字符串以便检测您的数据库。为此，它将使用反射查找并调用您的DbContext类，将其在 VisualStudio 的进程内调用。

不幸的是，由于它是在 VisualStudio 内部执行的，所以 ConnectionManager 将使用 devenv.exe.config 而不是您的 web.config，因此会忽略您的带有连接字符串的 web.config。

一旦您调用 IdentityDbContext<>，例如 base("DefaultConnection")，它将调用 base("DefaultConnection", true)，根据第二个参数尝试检测您的数据库是否使用 Identity 1.0.0 模式。

为此，它会尝试连接由传递给IdentityDbContext<>的连接名称标识的数据库（通常是“DefaultConnection”）。由于未加载web.config文件，因此具有该名称的连接字符串将不可用。

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

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

如果您没有安装SQL Express，那么会导致SQL异常，它将重试无效的连接尝试，直到超时过期。

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

我们开始的调试步骤：让我们弄清楚内部发生了什么。

1. 在冻结期间进行几次转储（比如每2-3秒钟一个转储）。制作转储的最简单方法我认为是：下载并运行SysInternals Process Explorer，然后使用Visual Studio进程上下文菜单|创建转储|创建迷你转储...
2. 分析转储。最简单的方法是使用OSR的即时分析
3. 检查转储中的堆栈（从分析结果中的STACK_TEXT开始）
4. 堆栈上的函数名称可以告诉您出了什么问题。
5. 如果这个指南没有帮助您，我需要看到转储。请注意，转储将包含VS的内存部分，其中可能包含一些个人信息，例如文件路径。

更新

现在OSR的分析无法分析转储中的堆栈，看来我们得以艰难的方式进行。

一次性准备工作

1. 作为Windows SDK的一部分安装Windows调试工具（清除所有其他复选框以不安装您不需要的内容）
2. 从已安装的软件包运行WinDBG（X86）

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

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

4. 按下 文件 | 保存工作区

分析转储文件

1. 在 WinDBG 中，按下 文件 | 打开转储文件... 并打开你的转储文件。
2. 在底部的编辑框中，输入 !analyze -v 然后按 Enter。
3. 检查堆栈。

- Codeguard

---

我已经完成了所有这些，现在它显示正在执行哪些方法/类等，看起来问题出在Entity Framework中。MANAGED_STACK部分的第一项是SQL和Entity Framework行。非常好奇。（第一行看起来像对Sleep的调用。） - Der Kommissar

这里有一个Gist链接（https://gist.github.com/EBrown8534/74b524cdf40eb984ee55），其中包含了`MANAGED_STACK`的信息，如果有帮助的话。我认为它正在尝试执行SQL操作时出现了一些问题。 - Der Kommissar

异常对象非常有趣，而 SQL 连接超时与您正在经历的冻结非常相关。 - Codeguard

你明白这是关于哪个SQL服务器吗？你能直接尝试访问它吗？ - Codeguard

让我们在聊天中继续这个讨论。 - Codeguard