547

私は機知に富んでいます。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 があります。表示テンプレートが呼び出されるたびに、IIS がシンボルを 2 回ロードしているようです。したがって、これら 3 つの表示テンプレートすべてを呼び出す 100 エントリのテーブルを表示すると、600 個の個別のシンボルが読み込まれます。

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

私が試したこと：

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

どんなアドバイスでも大歓迎です。

さらに質問に答えると、はい、私のマシンには間違いなく馬力があります。My Docs\IISExpress腹立たしいことは、通常、IIS Express を修復してフォルダーを削除した後、何も変更されていない同じプロジェクトが非常に速く読み込まれることがあることです。最終的に、「何か」が発生し、再度ロードするのに 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 は、呼び出されるたびに表示テンプレートを再コンパイルしているように見えますが、これも何百回も行われています。私の理論では、Visual Studio がファイルをコンパイルしてネットワーク共有に保存し、何らかの方法で新しい時刻をスタンプすると、Visual Studio はファイルが変更されたと認識します。したがって、Visual Studio はそれをもう一度再コンパイルします。ただし、理論にすぎません。私は本当に手がかりがありません。

1 つには、どうやら私はオフライン ファイルを持っているようです (これはオフィスのデスクトップ コンピューターです。あまり気にしませんでした)。明日、無効にして再起動し、再試行します。

さらに、プロジェクトをそのままローカル C: に移動すると、問題が修正されます。それは非常に速く読み込まれます。しかし、これは職場環境では理想的ではありません。以前のバージョンを失いました。手動でコピーしない限り、コードはまったくバックアップされず、誰とも共有されなくなりました。

必要に応じて、C からネットワーク共有にコピーするだけで十分です。ページが読み込まれるたびに 2 分間待つのは、さらに面倒です。

4

52 に答える 52

714

Visual Studio 2012 で「シンボルの読み込みが遅い」問題を解決した方法を次に示します。

  • [ツール] -> [オプション] -> [デバッグ] -> [一般] に移動します

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

  • [ツール] -> [オプション] -> [デバッグ] -> [シンボル] に移動します。

  • [...] ボタンをクリックし、ローカル コンピューターのどこかに新しいフォルダーを作成/選択して、キャッシュされたシンボルを保存します。私は「シンボルキャッシング」と名付け、ドキュメント - > Visual Studio 2012に入れました。

  • [すべてのシンボルを読み込む] をクリックし、Microsoft のサーバーからシンボルがダウンロードされるまで待ちます。これには時間がかかる場合があります。[すべてのシンボルを読み込む] ボタンは、デバッグ中にのみ使用できることに注意してください。

  • 「Microsoft シンボル サーバー」の横にあるチェックマークをオフにして、Visual Studio がリモートで Microsoft サーバーにクエリを実行しないようにします。

  • 「OK」をクリックします。

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

Microsoft アセンブリに変更またはダウンロードを行った場合は、[シンボル] ダイアログ ボックスに戻って、[すべてのシンボルを読み込む] を再度実行する必要がある場合があることに注意してください。

于 2013-01-02T00:50:28.657 に答える
79

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

サンダースは、それを確認したと述べましたが、この問題の解決策には言及されていませんでした。一部の人にとっては常識かもしれませんが、私たち全員ではありません。

于 2013-03-28T19:34:51.053 に答える
43

"Temporary ASP.NET Files" フォルダーを削除したところ、localhost ページの読み込みが劇的に改善されました。パスは次のとおりです... %temp%\Temporary ASP.NET Files\

于 2013-09-04T15:01:08.330 に答える
25

理由はわかりませんが、ようやく原因がわかったのではないかと思います。問題が再び発生し始めたとき、大量の「conhost.exe」プロセスが孤立していることに気付きました。Visual Studio を閉じても、それらは開いたままです。それぞれのタスクを終了すると、最終的に問題が確実に解決されました。[うまくいけば]

(conhost.exe は Visual Studio プロセスではありませんが、Visual Studio で使用されていることに注意してください。したがって、他のユーザーが conhost.exe を実行する他のアプリケーションを持っている可能性があります。 YMMV を除くすべてのタスクを安全に終了します。)

なぜこれが起こるのですか？一度に複数のプロジェクトを開くと発生するようです。これは、常にそのうちの 1 つだけをビルドしてデバッグする場合でも、頻繁に行う傾向があります。

編集 #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 キーを押しながらタブを押すことしかできません)。しかし、Windows Explorer をもう一度開くと、ほとんどの場合、超スローモーションに戻ります。

したがって、リダイレクトされたネットワーク共有がある場合は、試してみてください。それは確かにローカルで作業するよりも優れています。

于 2012-09-25T13:47:14.043 に答える
22

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

Debug -> Delete All Breakpoints
于 2013-09-06T15:30:01.413 に答える
19

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

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

何をしbatch="false"ますか？

変更され再コンパイルが必要なページのみをコンパイルすることで、プリコンパイルをより選択的にします。

正確には何をしているのoptimizeCompilationsですか？ソース

ASP.NET は、binフォルダApp_Codeや global.asax. ASP.NET アプリ ドメインが開始されるたびに、このハッシュ コードが以前に計算されたものから変更されているかどうかが確認されます。存在する場合は、codegenフォルダー全体 (コンパイルおよびシャドウ コピーされたアセンブリが存在する場所) が消去されます。

この最適化が (経由で) オンになると、ハッシュはとoptimizeCompilations="true"を考慮しなくなり binます。その結果、それらが変更されても、フォルダーは消去されません。App_Codeglobal.asaxcodegen

参考：MSDNのコンパイル要素

于 2015-09-10T21:56:59.633 に答える
19

私にとっては IE 9.08.8112.16241 でした。Firefox または Chrome を使用するとすぐに、F10 または F11 でのデバッグの遅延はなくなりました。IE の何が問題なのかはわかりませんが、現在、IE をテストに使用することは公式に軽蔑しています。

更新: すべての IE プログラム アドオンをオフにしたら、フル スピードに戻りました。一度に 1 つずつオンにすると、LastPass (私の場合) が原因であることが明らかになりました。結局のところ、MS を責めることはできないと思います。

数年後...
Brave を使用している場合は、拡張機能に簡単にアクセスして、デバッグ中に 1 つずつ (または複数) オフにすることができます。

brave://extensions

トグルスライダーをクリックするだけです。DuckDuckGo Privacy Essentials 以外はすべてオンになっていることに注意してください。それらは削除されず、一時的に無効になっているだけです。

ここに画像の説明を入力

于 2013-08-06T17:39:13.330 に答える
13

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

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

于 2013-06-04T08:06:24.520 に答える
12

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

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

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

それが役に立てば幸い。

類似の質問: 1 , 2

于 2012-11-21T12:52:49.460 に答える
12

私の場合、それは 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 を再起動することを忘れないでください。

于 2013-12-16T19:12:15.780 に答える
10

私もこの問題に直面していました。以下は私が実行する手順であり、常に機能します。

  • ソリューションの .suo ファイルを削除します。
  • 一時 ASP.NET ファイルの削除( %WINDOW%\Microsoft.NET\Framework\\Temporary ASP.NET Files で見つけられます)
  • アプリケーション内のすべてのブレークポイントを削除します。
于 2016-04-29T05:00:52.517 に答える
10

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

「suo」ファイル (「sln」ソリューション ファイルと同じディレクトリにある) が破損し、すべてが遅くなる可能性があることを漠然と覚えていました。

ここに画像の説明を入力

「suo」ファイルを削除しましたが、すべて問題ありませんでした。.suo ファイルの削除は無害であり、Windows レイアウトの再作成に加えて、開始プロジェクトとその他のいくつかの重要でないカスタマイズを意味するだけです。

于 2013-12-06T18:21:34.330 に答える
9

まだこの問題が発生しているかどうかはわかりませんが、VSに任せるのではなく、プロセス自体にデバッガーをアタッチすることでVisual Studioのサイトをデバッグし、時間を大幅に改善できることがわかりました。AttachToと呼ばれるVSの拡張機能を使用していますが、ここでそれをどのように使用するかについての小さな記事があります。

これがお役に立てば幸いです。

于 2013-02-19T11:19:03.873 に答える
6

タートルの速度と同じくらい遅いシンボルが読み込まれるのを一日中待った後、すべての可能な組み合わせを混合および切り替えます: Just My Code、Caching symbols、Intellitrace、Just-In-Time、killing processesなど。

私の解決策は、実際にはウイルス対策を無効にすることでした。はい、Windows Defender がプロジェクトの起動を遅らせていました。Visual Studio が要求したとおりにすべての dll をチェックし、シンボルのロード プロセス全体を遅くしていました。

私たちのマシンは、ソリューションを非常に高速にコンパイルするための優れた仕様を備えていると言わざるを得ないので、それは決して問題ではありませんでした. VS 2013 Ultimate でコーディングします。

于 2015-11-17T17:57:50.150 に答える
6

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

于 2013-05-03T17:21:41.797 に答える
5

シンボルキャッシュを空にするとうまくいきました。

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

于 2013-10-29T15:40:35.147 に答える
4

不明な VS 拡張機能がデフォルトのジャスト イン タイム デバッガーを置き換えたため、Asp.net コアのデバッグは非常に遅くなりました。

OPTIONS\DEBUGGING\Just-In-Time 構成タブで、このようなメッセージを見つけました (警告テキストとして)。 別のデバッガーが Just-In-Time デバッガーとして登録されています。修復するには、ジャストインタイム デバッグを有効にするか、Visual Studio の修復を実行します。

説明: https://msdn.microsoft.com/en-us/library/ssc8234s.aspx?f=255&MSPPError=-2147217396

デフォルトのJITデバッガー（チェックされていないManagedオプションをチェックしただけ）に戻すと、すべての問題が解決します。

于 2016-11-29T23:16:29.687 に答える
3

環境変数に移動し、キー _NT_SYMBOL_PATH を探します。

消して。

出来上がり、魅力のように働きました。

于 2015-05-21T11:04:08.057 に答える
3

私の場合、インターネット接続を無効にすると ctrl-f5 と同じくらい高速に実行されることに気付いたので、debug->options->symbols に移動し、すべての .pdb の場所のチェックを外しました。

デバッグ セッションが開始されるたびに、VS がこれらのサーバーに接続しようとしていたようです。

Debug->Options->Debugging->General "Enable source support" または "Require source files to正確に元のバージョンと一致させる"を無効にしても違いはないことに注意してください。

于 2013-01-01T15:59:31.080 に答える
3

私にとっての問題は、同じプロジェクトに対して複数のタブを開いているときに非常に重い「ブラウザリンク」機能でした!

プロジェクトを起動するたびに、ブラウザー リンク通信を含む新しいタブが開くためです。

プロジェクトに関連付けられているすべてのタブを閉じて、1 つだけ開いたままにしてください。

この無料で瞬時にビジュアルスタジオ！魔法です ！;-)

「Browser Link は、Visual Studio 2013 以降の機能であり、開発環境と 1 つ以上の Web ブラウザーとの間の通信チャネルを作成します。Browser Link を使用すると、一度に複数のブラウザーで Web アプリケーションを更新できます。これは、クロスブラウザー テストに役立ちます。」</p>

于 2016-01-24T18:26:02.950 に答える
3

私にとっては、条件付きブレークポイントでした。それらは本当に物事を遅くしているようです。

于 2015-05-13T09:43:27.297 に答える
3

同様の問題が私の一日の半分を無駄にしました!

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

私のはブレークポイントでした。プロジェクト外のライブラリ関数で停止するはずの「関数でブレーク」ブレークポイントがありました(つまり、コード行で F9 を押す代わりに、ブレークポイント ウィンドウを使用してブレークポイントを作成します)。

そして、「Intellisenseを使用して関数名を確認する」チェックを入れました。（情報はこちら。）

これは地獄のように遅くなりました (プロジェクトの起動が 2 秒から 5 分に短縮されました)。

ブレークポイントを削除すると、完全に解決しました。

于 2013-07-10T09:09:53.513 に答える
3

デフォルトの VS 設定からあまり逸脱していない人のための迅速かつ簡単なソリューションです。

[ツール] --> [設定のインポートとエクスポート] --> [はい、現在の設定を保存します] --> Visual C#

上記のソリューションは、他のデフォルト設定でも機能すると確信しています。私の場合、シンボルの読み込み設定に問題がありましたが、提案された解決策をかなり試しても修正できませんでした。

于 2016-09-04T23:01:09.780 に答える
3

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

Visual Studio でプロジェクトを開くと、デバッガーがすばやくアタッチ/デタッチされることを願っています。

于 2015-01-12T06:09:03.200 に答える
2

「ソース内のスレッドを表示」オプションを誤って選択してしまいました。選択を解除すると、コードのステップ実行は正常でした。

ソース内のスレッドを表示

于 2016-09-19T17:41:21.270 に答える
1

C# を既定の言語として新しいジョブで Visual Studio をセットアップしました。私は、VB でプログラミングする運命にあることにまだ気づいていませんでした。

VB が正常に動作しているように見えたので、C# のデフォルトを忘れていました。ただし、コードのステップ実行には、途方もない時間がかかりました。いくつかの修正を試みた後、必死になってデフォルト言語を VB に変更しました...ビンゴ!

ここまで落ち込んでいるなら、ぜひ試してみる価値があります。

于 2016-05-12T10:40:49.630 に答える
1

私は VS 2013 でこの問題を抱えていました。何ヶ月もの間、私のテストは正常にデバッグされていましたが、突然、恐ろしいシンボルの読み込みメッセージが表示され、それを引き起こすために何をしたかわかりませんでした。

ここや他のインターネットページで提案されたものは何も役に立ちませんでした。私はすべてを少なくとも10回試しました。.suoファイルを削除しても解決しませんでしたが、同じ場所に .testsettings 拡張子を持つ 2 つのファイルと.vsmdi拡張子を持つ 1つのファイルがありました。これらのファイルは廃止されたようで、おそらく VS 2010 の遺物です。それらを作成したチーム メンバーは、長い間行方不明でした。

これら 3 つのファイルはすべて問題なく削除できることがわかりました。シンボルの読み込みメッセージを停止するには、 .testsettingsファイルの特定の 1 つを削除するだけで十分であることがわかりました。私の悪夢は終わりました。

于 2016-02-12T00:28:26.153 に答える
1

私の問題は、デバッグを開始するたびにプロジェクトがビルドされることが原因でした。このスレッドの他のすべてのソリューションはわずかに役立ちましたが、それでもプロジェクトのビルドが完了するまで待たなければなりませんでした。

デバッグを開始するたびにビルドを回避するための私のソリューション:

  • 移動 Solution Explorer - >右クリックYour Solution File - >クリックProperties

  • Property Pages - >左側で、 - >を選択しConfiguration 、チェックを外しますBuild

  • クリックOK

  • 管理者としてビジュアルスタジオが開いていることを確認してください

  • に行くDebug - > Attach to Process

  • チェックボックスをクリックShow processes from all users - >呼び出されたプロセスを検索して選択w3wp.exe ->クリックAttach-> 警告が表示されたらクリックAttach

これで、localhost でデバッグしたいページに移動できます。ファイルにブレークポイントが設定されている場合は、プロジェクトのビルドを待たずにすぐにデバッグを開始できます!!

于 2018-08-15T16:02:08.170 に答える
1

私にとっては、マネージド互換モードでデバッグしていたということでした。[ツール] -> [オプション] -> [デバッグ] -> [全般] で、[管理された互換モードを使用する] のチェックを外します。デバッグは、1 行進むのに最大 1 分かかっていたところを瞬時に実行できるようになりました。上記のOPのスニペットで「管理対象」が意味するのはそれだと思います。

詳細はこちら: https://blogs.msdn.microsoft.com/visualstudioalm/2013/10/16/switching-to-managed-compatibility-mode-in-visual-studio-2013/

于 2017-03-31T12:50:50.217 に答える
1

開発中にローカルホストに再コンパイルするたびに、数分かかりました。ひどくイライラしました。すべてをSSDに配置するなど、多数の修正を試みた後。私は本当にうまくいったものを見つけました。RAM ディスクを作成し、プロジェクト全体をその中に入れました。ローカル ホストへの再コンパイルが 10 秒未満になりました。おそらくエレガントではありませんが、本当にうまくいきました。

于 2017-07-21T05:52:10.470 に答える