asp.net-mvc Visual Studio 调试/加载非常慢

Visual Studio debugging/loading very slow

提问by Ber'Zophus

I'm at wits end. Visual Studio is typicallypainfully slow to debug or just plain load ("start without debugging") my ASP.NET MVC sites. Not always: at first, the projects will load nice and fast, but once they load slow, they'll always load slow after that. I could be waiting 1-2 minutes or more.

我不知所措。Visual Studio调试或只是简单加载（“开始而不调试”）我的 ASP.NET MVC 站点通常非常缓慢。并非总是如此：一开始，项目会加载得很好而且很快，但是一旦加载缓慢，之后它们总是加载缓慢。我可能要等 1-2 分钟或更长时间。

My setup:

我的设置：

I'm using Visual Studio 2012 Express, currently, but I've had the same problem in Visual Studio 2010 Express as well. My solution is stored on a network drive; specifically, it's My Documents redirected to a network drive, if it matters. (It shouldn't. There are times where my site loads very fast under this setup.)

我目前使用的是Visual Studio 2012 Express，但我在 Visual Studio 2010 Express 中也遇到了同样的问题。我的解决方案存储在网络驱动器上；具体来说，它是重定向到网络驱动器的“我的文档”（如果重要的话）。（它不应该。在这种设置下，有时我的网站加载速度非常快。）

I load in Internet Explorer 9 usually, but the same problem happens in Firefox.

我通常在 Internet Explorer 9 中加载，但在 Firefox 中也会发生同样的问题。

This can happen in any ASP.NET MVC project I work on, and it seems to revolve around having DisplayTemplates, which all my ASP.NET MVC projects do. And it's all C# and Razor, if that mattered.

这可能发生在我从事的任何 ASP.NET MVC 项目中，而且它似乎与我所有的 ASP.NET MVC 项目都有 DisplayTemplates 相关。如果这很重要，那就全是 C# 和 Razor。

Symptoms:

症状：

The system will load my symbols hundredsof times. Basically, the following, but there are at least 300 such rows, each with ever-so-slightly different DLL files for the same CSHTMLs:

系统将加载我的符号数百次。基本上如下，但至少有 300 行这样的行，对于相同的 CSHTML，每行都有略微不同的 DLL 文件：

'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f823675085d\App_Web_contact.cshtml.22013bb9.xighmhow.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f823675085d\App_Web_contact.cshtml.22013bb9.cv5hktkf.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f823675085d\App_Web_statuscode.cshtml.22013bb9.1o77hs8i.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f823675085d\App_Web_statuscode.cshtml.22013bb9.jja-77mw.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f823675085d\App_Web_location.cshtml.22013bb9.l_e9ev_s.dll', Symbols loaded.
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f823675085d\App_Web_location.cshtml.22013bb9.b4n59gom.dll', Symbols loaded.

In the above, I've got three DisplayTemplates: "Contact", "Location", and "StatusCode". It appears that IIS is loading symbols twice for each time the displaytemplate gets called. Thus, if I'm displaying a table of 100 entries that calls all three of these displaytemplates, it's 600 separate symbols loaded.

在上面，我有三个 DisplayTemplates：“Contact”、“Location”和“StatusCode”。每次调用 displaytemplate 时，IIS 似乎都会加载两次符号。因此，如果我显示一个包含 100 个条目的表格，调用所有这三个显示模板，则加载了 600 个单独的符号。

This isn't a fast operation either. Looking in the log files that IIS generates, it takes about 200 ms for each symbol to load. Thus, super-long delays.

这也不是一个快速的操作。查看 IIS 生成的日志文件，加载每个符号大约需要 200 毫秒。因此，超长延迟。

What I've Tried:

我试过的：

• Debug or Release version, it doesn't matter.
• Putting my project on a full IIS implementation on a web server runs it super fast with no problems.
• Cassini, IIS Express 7.5, and IIS Express 8.0 all have the problem.
• Delete All Breakpoints does nothing.
• Clean Solution, or deleting the .suo also do nothing.
• If I repair IIS Express, or delete the My Docs\IISExpressfolder, or repair/reinstall Visual Studio → the issue MAY go away, but only for a while, before it comes right back.

• 调试版还是发布版，无所谓。
• 将我的项目放在 Web 服务器上的完整 IIS 实现上运行速度超快，没有任何问题。
• Cassini、IIS Express 7.5 和 IIS Express 8.0 都有问题。
• 删除所有断点什么都不做。
• Clean Solution或删除 .suo 也不做任何事情。
• 如果我修复 IIS Express，或删除My Docs\IISExpress文件夹，或修复/重新安装 Visual Studio → 问题可能会消失，但只会持续一段时间，然后才会再次出现。

Any advice at all is appreciated.

任何建议都表示赞赏。

To answer more questions, yes my machine definitely has the horsepower. The infuriating thing is that the same project, with NOTHING altered, can load very very quickly sometimes, typically after I repair IIS Express and delete the My Docs\IISExpressfolder. Eventually "something" happens and it's down to 2 minutes to load again. What I'm working on is not a complicated project. No external libraries or dependencies, and my VS.NET has no addons what-so-ever.

要回答更多问题，是的，我的机器绝对有马力。令人气愤的是，同一个项目，没有任何改变，有时可以非常快速地加载，通常是在我修复 IIS Express 并删除My Docs\IISExpress文件夹之后。最终“某事”发生了，再次加载需要 2 分钟。我正在做的不是一个复杂的项目。没有外部库或依赖项，而且我的 VS.NET 没有任何插件。

Of note, this machine has Symantec Endpoint Protection, which has a history of causing havoc. But disabling it outright (it's good to be an administrator) did not fix the problem.

值得注意的是，这台机器有 Symantec Endpoint Protection，它有造成严重破坏的历史。但是完全禁用它（作为管理员很好）并没有解决问题。

I have a theory at this point. I'm thinking this is all because I'm working off a redirected folder off a network share. While the debugger was going through its hundreds of "loaded symbols" lines, I paused to see what it was doing. It was in my code, loading the DisplayTemplate I had. Stepping into the template output this:

在这一点上我有一个理论。我认为这就是全部，因为我正在处理网络共享中的重定向文件夹。当调试器处理数百个“加载符号”行时，我停下来看看它在做什么。它在我的代码中，加载了我拥有的 DisplayTemplate。进入模板输出：

Step into: Stepping over non-user code 'System.Threading.WaitHandle.InternalWaitOne'
Step into: Stepping over non-user code 'System.Threading.WaitHandle.WaitOne'
Step into: Stepping over non-user code 'System.CodeDom.Compiler.Executor.ExecWaitWithCaptureUnimpersonated'
Step into: Stepping over non-user code 'System.CodeDom.Compiler.Executor.ExecWaitWithCapture'
Step into: Stepping over non-user code 'Microsoft.CSharp.CSharpCodeGenerator.FromFileBatch'
Step into: Stepping over non-user code 'Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromFileBatch'
Step into: Stepping over non-user code 'System.Web.Compilation.AssemblyBuilder.Compile'
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f823675085d\App_Web_statuscode.cshtml.22013bb9.bciuyg14.dll', Symbols loaded.
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.CompileWebFile'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVPathBuildResultInternal'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert'
Step into: Stepping over non-user code 'System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerWrapper.System.Web.Mvc.IBuildManager.FileExists'
Step into: Stepping over non-user code 'System.Web.Mvc.VirtualPathProviderViewEngine.GetPathFromGeneralName'
Step into: Stepping over non-user code 'System.Web.Mvc.VirtualPathProviderViewEngine.FindPartialView'
Step into: Stepping over non-user code 'System.Web.Mvc.ViewEngineCollection.Find'
Step into: Stepping over non-user code 'System.Web.Mvc.ViewEngineCollection.FindPartialView'
Step into: Stepping over non-user code 'System.Web.Mvc.Html.TemplateHelpers.ActionCacheViewItem.Execute'
'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f823675085d\App_Web_statuscode.cshtml.22013bb9.kwj3uqan.dll', Symbols loaded.
Step into: Stepping over non-user code 'System.RuntimeType.CreateInstanceSlow'
Step into: Stepping over non-user code 'System.Web.Mvc.DependencyResolver.DefaultDependencyResolver.GetService'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerViewEngine.DefaultViewPageActivator.Create'
Step into: Stepping over non-user code 'System.Web.Mvc.BuildManagerCompiledView.Render'

It looks like Visual Studio is recompiling my displaytemplate every timeit's called, which is again, hundreds of times. My theory is that Visual Studio compiles the file, saves it to the network share, the network share then somehow stamps a new time on it, and Visual Studio then thinks the file has changed and thus Visual Studio recompiles it yet again. Only a theory though; I really have no clue.

看起来 Visual Studio每次被调用时都在重新编译我的显示模板，这也是数百次。我的理论是 Visual Studio 编译文件，将其保存到网络共享，然后网络共享以某种方式在其上标记新时间，然后 Visual Studio 认为文件已更改，因此 Visual Studio 再次重新编译它。虽然只是一个理论；我真的没有头绪。

For one, apparently I have offline files on (this is a desktop computer in an office; I couldn't care less). I'm going to disable, reboot and retry tomorrow.

首先，显然我有离线文件（这是办公室里的台式电脑；我不在乎）。我要禁用，重新启动并明天重试。

Plus, moving my project, as is, to the local C: fixes it. It loads very quickly. But this is not ideal in a work environment. I lose Previous Versions, my code isn't backed up at all unless I manually copy it, and it's no longer shared with anyone.

另外，将我的项目按原样移动到本地 C: 修复了它。它加载非常快。但这在工作环境中并不理想。我丢失了以前的版本，我的代码根本没有备份，除非我手动复制它，并且不再与任何人共享。

I can make do with copying it back and forth from C to the network share, if it comes to it. It's much more annoying to wait two minutes for every page load.

如果涉及到它，我可以将它从 C 来回复制到网络共享。每次加载页面都要等待两分钟更烦人。

回答by Zeb Kimmel

Here is how I solved the "slow symbol loading" problem in Visual Studio 2012:

以下是我在 Visual Studio 2012 中解决“符号加载缓慢”问题的方法：

• Go to Tools -> Options -> Debugging -> General

• CHECK the checkmark next to "Enable Just My Code".

• Go to Tools -> Options -> Debugging -> Symbols

• Click on the "..." button and create/select a new folder somewhere on your local computer to store cached symbols. I named mine "Symbol caching" and put it in Documents -> Visual Studio 2012.

• Click on "Load all symbols" and wait for the symbols to be downloaded from Microsoft's servers, which may take a while. Note that Load all symbols button is only available while debugging.

• UNCHECK the checkmark next to "Microsoft Symbol Servers" to prevent Visual Studio from remotely querying the Microsoft servers.

• Click "OK".

• 转到工具 -> 选项 -> 调试 -> 常规

• 选中“仅启用我的代码”旁边的复选标记。

• 转到工具 -> 选项 -> 调试 -> 符号

• 单击“...”按钮并在本地计算机上的某处创建/选择一个新文件夹来存储缓存符号。我将我的命名为“Symbol caching”并将其放在 Documents -> Visual Studio 2012 中。

• 单击“加载所有符号”并等待符号从 Microsoft 的服务器下载，这可能需要一段时间。请注意，加载所有符号按钮仅在调试时可用。

• 取消选中“Microsoft 符号服务器”旁边的复选标记以防止 Visual Studio 远程查询 Microsoft 服务器。

• 单击“确定”。

From now on, symbol loading should be much faster.

从现在开始，符号加载应该快得多。

Note that if you make any changes/downloads to Microsoft assemblies, you may need to go back into the Symbols dialog box and "Load all symbols" again.

请注意，如果您对 Microsoft 程序集进行任何更改/下载，您可能需要返回“符号”对话框并再次“加载所有符号”。

回答by moke

Turning off intelliTrace fixed this for me.

关闭 intelliTrace 为我解决了这个问题。

In Visual Studio, Tools -> Options -> IntelliTrace

在 Visual Studio 中，工具 -> 选项 -> IntelliTrace

Then, uncheck the checkbox for "Enable IntelliTrace".

然后，取消选中“启用 IntelliTrace”复选框。

回答by user2144480

None of this worked for me but I found a Breakpoint on a symbol that was deleted. Seems 2010 was hanging on it. To see if this is your issue do debug->windows->breakpoints If any are in there just delete them.

这些都不适合我，但我在被删除的符号上发现了一个断点。似乎 2010 年就悬而未决。要查看这是否是您的问题，请执行 debug->windows->breakpoints 如果有的话，只需删除它们。

Saunders, mentioned he checked for that but it was not mentioned in the solutions for this problem. Maybe common knowledge for some, but not all of us.

Saunders 提到他检查过这个问题，但在这个问题的解决方案中没有提到。也许对某些人来说是常识，但不是我们所有人。

回答by Shaun Kennedy

I deleted the "Temporary ASP.NET Files" folder and my localhost page load improved dramatically. Here is the path... %temp%\Temporary ASP.NET Files\

我删除了“Temporary ASP.NET Files”文件夹，我的本地主机页面加载得到了显着改善。这是路径... %temp%\Temporary ASP.NET Files\

回答by rkawano

Do you have enabled FusionLog?

您是否启用了 FusionLog？

My VisualStudio was very slow to start, open solution and load symbols when start debugging. It was slow only on my machine, but not on other machines.

我的 VisualStudio 在开始调试时启动、打开解决方案和加载符号都很慢。仅在我的机器上很慢，但在其他机器上没有。

FusionLog writes tons of log stuff to disk. Just disabling it on RegEdit solved everything, on my case.

FusionLog 将大量日志内容写入磁盘。在我的情况下，只需在 RegEdit 上禁用它就解决了所有问题。

This is the FusionLog key on registry:

这是注册表中的 FusionLog 键：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

Check ForceLog value (1 enabled, 0 disabled).

检查 ForceLog 值（1 启用，0 禁用）。

回答by aricons

I experienced the same problem and tried most of the resolutions above. Simply deleting cache and temp files end up working for me.

我遇到了同样的问题并尝试了上述大部分解决方案。简单地删除缓存和临时文件最终对我有用。

Try removing the contents of these two folders:

尝试删除这两个文件夹的内容：

C:\Users\{UserName}\AppData\Local\Microsoft\WebsiteCache

and

和

C:\Users\\{UserName}\AppData\Local\Temp(in particular the iisexpress and Temporary ASP.NET Files folders).

C:\Users\\{UserName}\AppData\Local\Temp（特别是 iisexpress 和 Temporary ASP.NET Files 文件夹）。

This can be set up to happen automatically on logging on to Windows by adding a cmd file to the C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startupfolder with the following content:

这可以设置为在登录 Windows 时自动发生，方法是将 cmd 文件添加到C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup包含以下内容的文件夹中：

rmdir C:\Users\{username}\AppData\Local\Microsoft\WebsiteCache /s /q

rmdir C:\Users\{username}\AppData\Local\Temp /s /q

回答by Ber'Zophus

I think I may finally at least know the cause, though not the reason why. When the problem started occurring again, I noticed a ton of "conhost.exe" processes orphaned. I would close Visual Studio and they would remain open. Ending task on each of them has finally, reliably solved the problem. [hopefully]

我想我至少可能最终知道原因，尽管不是原因。当问题再次出现时，我注意到大量“conhost.exe”进程被孤立。我会关闭 Visual Studio，它们会保持打开状态。结束他们每个人的任务终于可靠地解决了问题。[希望]

(Just note, conhost.exe isn't a Visual Studio process though Visual Studio uses it. Thus, other users out there may have other applications out there that run conhost.exe. I know my machine doesn't which is why I can safely end task all of them but YMMV.)

（请注意，conhost.exe 不是 Visual Studio 进程，尽管 Visual Studio 使用它。因此，那里的其他用户可能有其他运行 conhost.exe 的应用程序。我知道我的机器没有，这就是为什么我可以安全地结束所有任务，但 YMMV。）

As to why this happens? It seems to occur when I open more than one project at once, which I tend to do often, even though I only build and debug one of them at any time.

至于为什么会出现这种情况？当我一次打开多个项目时似乎会发生这种情况，我经常这样做，即使我在任何时候只构建和调试其中一个。

---

---

Edit #1 - This isn't a "silver bullet" unfortunately. It doesn't always work for me. Typically, when things get slow, I just close all of my Visual Studio sessions, then go into the task manager and end any instance of it, conhost.exe, iisexpress.exe Microsoft.VisualStudio.Web.Host.exe and MSBuild.exe I can find.

编辑 #1 - 不幸的是，这不是“银弹”。它并不总是对我有用。通常，当事情变慢时，我只是关闭所有 Visual Studio 会话，然后进入任务管理器并结束它的任何实例 conhost.exe、iisexpress.exe Microsoft.VisualStudio.Web.Host.exe 和 MSBuild.exe我可以找到。

Typically, after that, when I restart my project it'll then load quickly. But not always.

通常，在那之后，当我重新启动我的项目时，它会快速加载。但不总是。

Really I think the best course of action is probably to not build & debug code off a redirected folder/network share.

我真的认为最好的做法可能是不要从重定向的文件夹/网络共享中构建和调试代码。

---

---

Edit #2 - Two years later, and this is stillan issue for me in Visual Studio Community 2013, but I did seem to at least find the culprit task: Explorer.exe. Yeah, who knew. The moment I end that task, bam, page loads in a single second.

编辑 #2 - 两年后，这对我来说仍然是 Visual Studio Community 2013 中的一个问题，但我似乎至少找到了罪魁祸首：Explorer.exe。是啊，谁知道。当我结束该任务时，砰的一声，页面加载在一秒钟内。

If I have a Windows Explorer file browser open to my redirected network drive (which is often since that's where my code is), this problem seems to occur. Closing the window isn't enough, I have to kill the whole Explorer.exe task. I could only guess what it's doing...going nuts with file handles?

如果我有一个 Windows 资源管理器文件浏览器打开到我重定向的网络驱动器（这通常是因为那是我的代码所在的位置），这个问题似乎会发生。关闭窗口是不够的，我必须杀死整个 Explorer.exe 任务。我只能猜测它在做什么......对文件句柄发疯了吗？

I can usually use the task manager to start up a new explorer.exe task (I can only take so much alt-tabbing), and Visual Studio will continue to load nice and quick. But if I so much as open Windows Explorer again, it almost always goes back to super-slow-mo.

我通常可以使用任务管理器来启动一个新的 explorer.exe 任务（我只能使用这么多的 alt-tabbing），并且 Visual Studio 将继续很好且快速地加载。但是，如果我再次打开 Windows 资源管理器，它几乎总是会回到超慢速模式。

So, if you've got a redirected network share, give it a shot. It sure beats working locally.

因此，如果您有重定向的网络共享，请试一试。它肯定胜过在本地工作。

回答by Tahir Hassan

The above are all good solutions and I tried all of them, but got the solution here, which is to

以上都是很好的解决方案，我尝试了所有这些，但在这里得到了解决方案，即

Debug -> Delete All Breakpoints

回答by DMadden51

For me it was IE 9.08.8112.16241. As soon as I used Firefox or Chrome there was no sluggish debugging with F10 or F11. I do not know what the problem with IE is but I officially despise using it for testing now.

对我来说是 IE 9.08.8112.16241。我一使用 Firefox 或 Chrome，就没有使用 F10 或 F11 进行缓慢的调试。我不知道 IE 的问题是什么，但我现在正式鄙视使用它进行测试。

Update: I have turned off all IE program add-ons and it is back to full speed. Turning them on one at a time revealed that LastPass (in my case) was the culprit. I guess I do not get to blame MS after all.

更新：我已关闭所有 IE 程序加载项，它已恢复全速。一次打开它们显示 LastPass（就我而言）是罪魁祸首。我想我毕竟不能责怪MS。

回答by Korayem

For me, I implemented this tipwhich basically drastically improved performance by adding the following two attributes to compilation tag in web.config

对我来说，我实现了这个技巧，通过将以下两个属性添加到 web.config 中的编译标记，基本上大大提高了性能

<compilation ... batch="false" optimizeCompilations="true"> ... </compilation>

What does batch="false" do?

batch="false" 有什么作用？

It makes pre-compilation more selective by compiling only pages that have changed and require re-compiling

它通过仅编译已更改并需要重新编译的页面来使预编译更具选择性

What exactly is the optimizeCompilations doing? Source

优化编译到底在做什么？来源

ASP.NET uses a per application hash code which includes the state of a number of things, including the bin and App_Code folder, and global.asax. Whenever an ASP.NET app domain starts, it checks if this hash code has changed from what it previously computed. If it has, then the entire codegen folder (where compiled and shadow copied assemblies live) is wiped out.

When this optimization is turned on (via optimizeCompilations="true"), the hash no longer takes into account bin, App_Code and global.asax. As a result, if those change we don't wipe out the codegen folder.

ASP.NET 使用每个应用程序的哈希代码，其中包括许多事物的状态，包括 bin 和 App_Code 文件夹以及 global.asax。每当 ASP.NET 应用程序域启动时，它都会检查此哈希代码是否与之前计算的内容不同。如果有，则整个 codegen 文件夹（已编译和影子复制的程序集所在的位置）将被清除。

当这个优化被打开时（通过 optimizeCompilations="true"），哈希不再考虑 bin、App_Code 和 global.asax。因此，如果这些更改，我们不会清除 codegen 文件夹。

Reference: Compilation element on msdn

参考：msdn 上的编译元素