Visual Studio发布Web对话需要过多的时间来加载

Question

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

有没有人对此有任何想法？仅在这个问题上,我每天失去20-30分钟的开发时间.

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

我还考察了轮廓.user文件,二者相再次.我不知道这里可能出现什么问题.

请注意,发布不需要花费很多时间.配置文件A需要与配置文件B一样发布.

此外,在我完全重新安装Windows之前,即使在我的旧Visual Studio 2015安装中也存在此问题.(当我升级到Windows 10时,我完全重新安装了Windows.)

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

进一步说明:在加载对话框时,它会完全锁定Visual Studio .

更新:重新安装Visual Studio完全没有纠正问题.

另一个更新:在打开对话时,Visual Studio偶尔会崩溃.

Answer 1

TL; DR:作为此问题的解决方法,找到DbContext从中继承IdentityDbContext<>并更改基类构造函数的类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),它(根据第二个参数)将尝试检测您的数据库是否认同1.0.0架构.
5. 为了做到这一点,它将尝试连接到您的数据库,由传递给的连接名称标识IdentityDbContext<>(通常是"DefaultConnection")
6. 由于web.config未加载,因此具有此名称的连接字符串将不可用.

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

   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的即时分析
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并按Enter键.
3. 检查堆栈.