asp.net mvc - vs2017 - Visual Studioのデバッグ/読み込みが非常に遅い




vs2017 デバッグ 遅い (20)

私は知恵の終わりです。 Visual Studioは、通常 、ASP.NET MVCサイトをデバッグするのに苦労したり、単純に読み込んだり(「デバッグなしで起動する」)、非常に時間がかかります。 必ずしもそうではありません。最初は、プロジェクトは素早く素早くロードされますが、ロードが遅くなると遅くロードされます。 私は1〜2分以上待つことができた。

私のセットアップ:

現在Visual Studio 2012 Expressを使用していますが、Visual Studio 2010 Expressでも同様の問題が発生しています。 私のソリューションはネットワークドライブに保存されています。 特に重要なのは、ネットワークドライブにリダイレクトされるマイドキュメントです。 (この設定では、サイトが非常に高速に読み込まれることがあります。)

私は通常Internet Explorer 9で読み込みますが、Firefoxでも同じ問題が発生します。

これは、私が取り組んでいるどのASP.NET MVCプロジェクトでも起こり得ます。私のすべてのASP.NET MVCプロジェクトが行うDisplayTemplatesを中心に展開されているようです。 それが重要なのなら、それはすべてC#とRazorです。

症状:

システムは何百回もシンボルをロードします。 基本的には、次のような行がありますが、少なくとも300個の行があり、それぞれに同じCSHTMLのDLLファイルが少しずつ異なります。

'iisexpress.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\b63f8236\6775085d\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\b63f8236\6775085d\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\b63f8236\6775085d\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\b63f8236\6775085d\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\b63f8236\6775085d\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\b63f8236\6775085d\App_Web_location.cshtml.22013bb9.b4n59gom.dll', Symbols loaded.

上の例では、「Contact」、「Location」、「StatusCode」の3つのDisplayTemplatesがあります。 displaytemplateが呼び出されるたびに、IISがシンボルを2回読み込んでいるようです。 したがって、これらのdisplaytemplatesの3つをすべて呼び出す100エントリのテーブルを表示すると、600個の別々のシンボルがロードされます。

これは高速な操作でもありません。 IISが生成するログファイルを見ると、各シンボルが読み込まれるまでに約200ミリ秒かかります。 従って超長遅延。

私が試したこと:

  • デバッグまたはリリースのバージョン、それは問題ではありません。
  • 私のプロジェクトをWebサーバー上の完全なIIS実装に置くと、問題なく高速に実行されます。
  • Cassini、IIS Express 7.5、およびIIS Express 8.0にはすべて問題があります。
  • すべてのブレークポイントの削除は何もしません。
  • Clean Solution 、または.suoを削除することも何もしません。
  • IIS Expressを修復したり、 My Docs\IISExpressフォルダを削除したり、Visual Studioを修復/再インストールした場合、問題はすぐに消えてしまうことがあります。

どんなアドバイスも感謝しています。

もっと多くの質問に答えるために、私のマシンは確かに馬力を持っています。 怒っているのは、IIS Expressを修復してMy Docs\IISExpressフォルダを削除した後で、何も変更されていない同じプロジェクトが非常に迅速にロードされることがあるということです。 最終的に「何か」が起こり、2分後に再度ロードされます。 私が取り組んでいることは、複雑なプロジェクトではありません。 外部のライブラリや依存関係はなく、私のVS.NETにはアドオンが何もありません。

注目すべきは、このマシンにはSymantec Endpoint Protectionがあり、これには大混乱の歴史があります。 しかし、それを完全に無効にする(それは管理者であることが良い)ことは問題を解決しませんでした。

私はこの時点で理論を持っています。 私はネットワーク共有からリダイレクトされたフォルダを取り除いているので、これがすべてだと思っています。 デバッガが何百行もの「読み込まれたシンボル」行を通過している間、私はそれが何をしているのかを確認するために一時停止しました。 私のコードで、私が持っていた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\b63f8236\6775085d\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\b63f8236\6775085d\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'

Visual Studioでは、呼び出されるたびにdisplaytemplateを再コンパイルするように見えますが、何百回も繰り返します。 私の理論は、Visual Studioがファイルをコンパイルし、それをネットワーク共有に保存し、ネットワーク共有が何らかの形で新しい時刻をスタンプすると、Visual Studioはファイルが変更されたと考え、Visual Studioが再度それを再コンパイルすると考えます。 しかし、理論だけです。 私は本当に手掛かりがありません。

1つは、明らかに私はオフラインファイルを持っている(これはオフィス内のデスクトップコンピュータで、私はそれほど気にすることはできない)。 明日は無効にし、再起動して再試行します。

さらに、自分のプロジェクトを現地のCに移すと、それが修正されます。 非常に迅速にロードされます。 しかし、これは職場環境では理想的ではありません。 私は以前のバージョンを失います。手動でコピーしない限り、私のコードはまったくバックアップされません。

もしそれが来たら、Cからネットワーク共有にそれを前後にコピーすることができます。 ページを読み込むたびに2分待つのはずっと面倒です。


FusionLogを有効にしましたか?

私のVisualStudioは、デバッグを開始すると、開始が非常に遅く、ソリューションを開いてシンボルを読み込みました。 私のマシンでは遅かったが、他のマシンでは遅かった。

FusionLogは、大量のログをディスクに書き込みます。 私の場合、RegEditでそれを無効にするだけですべてが解決されました。

これはレジストリのFusionLogキーです:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion

ForceLog値(1が有効、0が無効)を確認します。


Visual Studio 2012で「遅いシンボルの読み込み」問題を解決する方法は次のとおりです。

  • ツール - >オプション - >デバッグ - >一般

  • 「自分のコードを有効にする」の横にあるチェックマークをオンにします。

  • ツール - >オプション - >デバッグ - >シンボル

  • "..."ボタンをクリックし、ローカルコンピュータのどこかに新しいフォルダを作成/選択して、キャッシュされた記号を保存します。 私は私の名前を "Symbol caching"と命名し、Documents - > Visual Studio 2012に入れました。

  • 「すべてのシンボルをロード」をクリックして、Microsoftのサーバーからシンボルがダウンロードされるまで待ってください。 [すべてのシンボルをロード]ボタンは、デバッグ中のみ使用できます。

  • 「Microsoft Symbol Servers」の横にあるチェックマークを解除すると、Visual StudioがMicrosoftサーバーをリモートから照会できなくなります。

  • [OK]をクリックします。

これから、シンボルの読み込みははるかに高速になるはずです。

Microsoftアセンブリに変更/ダウンロードを行う場合は、シンボルダイアログボックスに戻って「すべてのシンボルを読み込む」必要があります。


Windowsエクスプローラでソリューションフォルダを開き、ビジュアルスタジオを閉じ、Windowsエクスプローラから.suoファイルを削除します。

今すぐビジュアルスタジオでプロジェクトを開いて、うまくいけばデバッガが簡単にアタッチ/デタッチされます。


intelliTraceをオフにすると、これは私のために修正されました。

Visual Studioでは、ツール - >オプション - > IntelliTrace

次に、[IntelliTraceを有効にする]チェックボックスをオフにします。


これのどれも私のために働いたのではなく、削除されたシンボルにブレークポイントが見つかりました。 2010年はそれに掛かっていたようだ。 これがあなたの問題かどうかを確認するには、debug-> windows-> breakpointsを実行してください。

Saundersは、彼がそれをチェックしたと述べましたが、この問題の解決策では言及されていませんでした。 たぶん私たちのすべてではなく、一部の人には常識です。


シンボルキャッシュを空にすると私にとってはうまくいった。

参照:メニューバー/ツール/オプション/デバッグ/シンボル/空シンボルキャッシュ


一度、停電後、ブレークポイントに達するか例外がスローされるたびに、同じ遅さの問題に直面しなければなりませんでした。

私は、 "suo"ファイル( "sln"ソリューションファイルと同じディレクトリ内)が壊れてすべてが遅くなることを覚えていました。

私は私の "suo"ファイルを削除し、すべてがOKだった。 .suoファイルの削除は無害で、私のウィンドウレイアウトと開始プロジェクトといくつかの重要ではない重要なカスタマイズを再作成することを意味します。


一日中、亀のスピードと同じくらい遅くロードするシンボルを待って、 マイコード、キャッシングシンボルIntellitrace 、Just-In-Time、 killプロセスなどのすべての組み合わせをミキシングして切り替えます

私の解決策は実際にはウイルス対策無効にすることでした。 ええ、Windows Defenderはプロジェクトの立ち上げを遅らせていました。 それはVisual Studioがそれらを要求し、全体のシンボル読み込みプロセスを遅くするので、すべてのdllをチェックします。

私たちのマシンには本当に速いソリューションをコンパイルするための優れた仕様があるので、それは決して問題ではないと言わなければなりません。 VS 2013 Ultimateでコードを作成します。


上記はすべて良い解決策であり、私はそれらのすべてを試しましたが、 hereで解決策を得ました。

Debug -> Delete All Breakpoints

同じような問題が、私の一日の半分を無駄にしました!

私の問題の解決策はここで述べたものとは異なっていたので、私はそれを投稿して他の人を助けるかもしれない。

私のことはブレークポイントだった。 私は"Break at function"ブレークポイントを持っていました(つまり、コードラインでF9キーを押すのではなく、ブレークポイントウィンドウを使ってそれらを作成します)。これはプロジェクト外のライブラリ関数で停止するはずです。

私は"Intellisenseを使用して関数名を確認する"を確認しました 。 ( here情報。)

これは地獄のようなものと比べて遅くなりました(プロジェクトの立ち上げは2秒から5分まで)。

ブレークポイントを削除すると、それが解決されました。


私にとってはIE 9.08.8112.16241でした。 FirefoxやChromeを使用するとすぐにF10やF11でデバッグが遅くなることはありませんでした。 私はIEの問題は何か分かりませんが、私は正式にテストのためにそれを使用して軽蔑します。

アップデート:私はIEのすべてのプログラムのアドオンを無効にして、それは完全な速度に戻っています。 一度に1つずつオンにすると、LastPass(私の場合は)が犯人であることが明らかになりました。 私は結局MSを非難することはないと思う。


私にとっては、web.configのコンパイルタグに次の2つの属性を追加することで、基本的にパフォーマンスが大幅に向上したこのヒントを実装しました

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

batch = "false"は何をするのですか?

変更されたページのみをコンパイルすることにより、事前コンパイルをより選択的に行います。

optimizeCompilationsは何をしていますか? Source

ASP.NETは、アプリケーションごとのハッシュコードを使用します。これには、binおよびApp_Codeフォルダ、global.asaxなど、さまざまな状態の状態が含まれます。 ASP.NETアプリケーションドメインが起動するたびに、このハッシュコードが以前計算されたものから変更されているかどうかがチェックされます。 存在する場合は、codegenフォルダ全体(コンパイル済みおよびシャドウコピーされたアセンブリが存在する場所)が消去されます。

最適化を有効にすると(optimizeCompilations = "true")、ハッシュはもはやbin、App_Codeおよびglobal.asaxを考慮しません。 その結果、それらが変更された場合、codegenフォルダは一掃されません。

リファレンス: msdnのコンパイル要素


私の場合は

Tools/Options/Debugging/General/Enable JavaScript debugging for ASP.NET (Chrome and IE)

このチェックを外すと、デバッグの開始は45〜60秒から0〜5秒になりました。


私の場合はVS 2012の.NET Reflector Visual Studio Extension(バージョン8.3.0.93)でした。 ステップオーバー (F10)ごとにデバッグに10秒かかっていました。

Visual StudioでTools / Extensions and Updates ...に移動し、 .NET Reflector Visual Studio Extensionを無効にします 。 Visual Studioを再起動することを忘れないでください。


私は "Temporary ASP.NET Files"フォルダを削除し、localhostページの負荷が大幅に改善されました。 ここにパスがあります...%temp%\ Temporary ASP.NET Files \


私は、 "ネイティブコード"デバッガが有効になっていたときにVisual Studioのデバッグに時間がかかるという問題がありました。 無効にしてみてください。

「Visual Studio 2012」で、次の場所に移動します。

  1. プロジェクトのプロパティ - >
  2. Web - >
  3. デバッガ(ページの一番下)。 - >
  4. ASP.NET以外のすべてを無効にする

それが役に立てば幸い。

同様の質問: 2


私は同じ問題を経験し、上記の解決策のほとんどを試しました。 単にキャッシュと一時ファイルを削除するだけで、私のために働くことになります。

これら2つのフォルダの内容を削除してみてください:

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

そして

C:\Users\\{UserName}\AppData\Local\Temp (特にiisexpressとTemporary ASP.NET Filesフォルダ)。

これは、 C:\Users\\{username}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startupフォルダに次の内容のcmdファイルを追加することで、Windowsへのログオン時に自動的に行われるように設定できます。

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

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

私は最終的に少なくとも原因を知るかもしれないと思うが、その理由はない。 問題が再び発生し始めたとき、私は孤立した "conhost.exe"プロセスの大部分に気づきました。 私はVisual Studioを閉じて、開いたままにします。 それぞれのタスクを終了すると、最終的に問題が確実に解決されました。 [うまくいけば]

(conhost.exeはVisual Studioのプロセスではありませんが、他のユーザーがconhost.exeを実行する他のアプリケーションを持っている可能性があります。 YMMV以外のすべてのタスクを安全に終了します。)

なぜこれが起こるのか? 一度に複数のプロジェクトを開くときに発生するようですが、私は頻繁に行う傾向がありますが、いつでもそれらのビルドとデバッグを行うことができます。

編集#1 - これは残念なことに "銀色の弾丸"ではありません。 それはいつも私のために働くとは限りません。 通常、状況が遅くなると、Visual Studioのすべてのセッションを閉じて、タスクマネージャに入り、conhost.exe、iisexpress.exe Microsoft.VisualStudio.Web.Host.exeおよびMSBuild.exeのインスタンスを終了します。私は見つけることができます。

その後、通常、プロジェクトを再開すると、すぐに読み込まれます。 しかしいつもではない。

実際には、リダイレクトされたフォルダ/ネットワーク共有からコードをビルドしてデバッグするのが最善の策だと私は思っています。

編集#2 - 2年後、これはまだ Visual Studio Community 2013で私にとっては問題ですが、少なくとも、犯人タスクExplorer.exeを見つけたようです。 うん、誰が知っていた。 私がその仕事を終える瞬間、バムは、1秒でページを読み込みます。

リダイレクトされたネットワークドライブ(これは私のコードがある場所であることが多いためです)にWindowsエクスプローラのファイルブラウザを開いていると、この問題が発生するようです。 ウィンドウを閉じるだけでは不十分です。私はExplorer.exeのタスク全体を終了させる必要があります。 私はそれが何をしているのか推測することができただけです...ファイルハンドルを持つナットですか?

私は通常、新しいexplorer.exeタスクを起動するためにタスクマネージャを使うことができます(私はあまりにも多くのalt-tabbingしか取ることができません)。Visual Studioは素早く素早く読み込まれます。 しかし、もし私がWindowsエクスプローラを開いているとすれば、それはほとんどいつもスーパースローモールに戻ります。

だから、あなたがリダイレクトされたネットワーク共有を持っているなら、それを一撃してください。 それは確かにローカルで働くことに勝つ。


私もデバッグの実行のパフォーマンスの問題がありました。私はデバッガの非常に多くのオプションを試しました。 私の場合は、このオプションを変更すると大きなパフォーマンスが達成されます:

ツール - オプション - デバッグ - 出力ウィンドウ - (一般出力設定 - すべてのデバッグ出力) - オフ


誰かがこの動作が左のフィールドから出てくることに気づいた場合は、web.configにブレークポイントが設定されていないことを確認してください。 私は迷惑なマウスクリックで1つを設定しなければならず、本当にすべてのデバッグ操作が遅くなりました。





cassini