多くの再帰を使用してコードを記述しましたが、完了までにかなり時間がかかります。実行を「一時停止」して、何が起こっているのかを確認するたびに、次のようになります。
現在のメソッドのコードが最適化されているため、式を評価できません。
私はそれが何を意味するのか理解できたと思います。しかし、私が困惑しているのは、ステップを押した後、コードがもう「最適化」されておらず、変数を見ることができるということです。これはどのように起こりますか?最適化されたコードと最適化されていないコードの間でコードをどのように切り替えることができますか?
デバッガーはFuncEvalを使用して、変数を「見る」ことができます。 FuncEvalでは、マネージコードでGarbageCollectorの安全なポイントでスレッドを停止する必要があります。 IDEで実行を手動で「一時停止」すると、すべてのスレッドができるだけ早く停止します。非常に再帰的なコードは安全でないポイントで停止する傾向があります。したがって、デバッガは式を評価できません。
F10を押すと、次のFunceval Safeポイントに移動し、機能評価を有効にします。
詳細については、 FuncEvalのルール を確認してください。
Debug.Break()行がコールスタックの上にある間、式を評価することはできません。その行が最適化されているためです。 F10キーを押して次の行(有効なコード行)に移動すると、時計が機能します。
おそらくデバッグモードではなくリリースモードでアプリをデバッグしようとしているか、コンパイル設定で最適化がオンになっています。
コードを最適化してコンパイルすると、特定の変数が関数で使用されなくなると破棄されます。そのため、そのメッセージが表示されます。最適化が無効になっているデバッグモードでは、そのエラーは発生しません。
これは私を夢中にさせました。マネージドコードとネイティブコードでアタッチしようとしました-いいえ。
これは私のために働いたと私は最終的にすべての式を評価することができました:
@Vinに感謝します。
VS 2015を使用していたときにこの問題が発生しました。私の解決策:構成(デバッグ)が選択されています。プロジェクトプロパティの下のOptimize Code
プロパティのチェックを外すことでこれを解決しました。
プロジェクト(右クリック)=>プロパティ=>ビルド(タブ)=>最適化コードのチェックを外します
あなたはそのようなものを持っていないことを確認してください
[Assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
あなたのAssemblyInfo
で
多くのパラメータを持つ関数呼び出しを探し、デバッグが戻るまで数を減らしてみてください。
同じ問題を抱えていましたが、デバッガーで例外トラップをオフにすることで解決できました。 [デバッグ] [例外]をクリックして、例外を「ユーザー未処理」に設定します。
通常、これはオフになっていますが、ときどき便利です。終わったら忘れずにオフにする必要があります。
VS 2010を使用していたときにこの問題が発生しました。ソリューション構成で(デバッグ)が選択されています。これを解決するには、プロジェクトプロパティの[コードの最適化]プロパティをオフにします。プロジェクト(右クリック)=>プロパティ=>ビルド(タブ)=>最適化コードのチェックを外します
私の場合、ソリューションに2つのプロジェクトがあり、スタートアッププロジェクトではないプロジェクトを実行していました。スタートアッププロジェクトに変更すると、デバッグが再び機能し始めました。
それが誰かを助けることを願っています。
評価:
.NETでは、「関数評価(funceval)」は、デバッグ対象がどこかで停止している間にCLRが任意の呼び出しを挿入する機能です。 Funcevalは、要求されたメソッドを実行するためにデバッガの選択されたスレッドを担当します。 funcevalが終了すると、デバッグイベントが発生します。技術的には、CLRはデバッガーがfuncevalを発行する方法を定義しています。
CLRは、GCセーフポイント(つまり、スレッドがGCをブロックしないとき)とFunceval Safe(FESafe)ポイント(つまり、CLRが実際にFuncevalのハイジャックを実行できる場所)にあるスレッドでのみfuncevalを開始できます。したがって、CLRの考えられるシナリオでは、スレッドは次のとおりである必要があります。
マネージコードで(およびGCセーフポイントで)停止:これは、ネイティブコードでfuncevalを実行できないことを意味します。ネイティブコードはCLRの制御外であるため、funcevalをセットアップできません。
最初の機会または未処理の管理された例外(およびGCの安全なポイント)で停止しました。つまり、例外が発生した理由を判断するために可能な限り検査します。 (例:デバッガーは、発生した例外のMessageプロパティを評価および表示しようとする場合があります。)
全般的に、マネージコードで停止する一般的な方法には、ブレークポイント、ステップ、Debugger.Break呼び出し、例外のインターセプト、またはスレッドの開始での停止が含まれます。これは、メソッドと式の評価に役立ちます。
考えられる解決策:評価に基づき、スレッドがFESafeおよびGCSafeポイントにない場合、CLRはスレッドをハイジャックしてfuncevalを開始できません。一般的に、次のようにすると、期待どおりにfuncevalが開始されるようになります。
ステップ1:
「リリース」ビルドをデバッグしようとしていないことを確認してください。リリースは完全に最適化されているため、議論の誤りにつながります。標準ツールバーまたは構成マネージャーを使用して、デバッグとリリースを切り替えることができます。
ステップ2:
それでもエラーが発生する場合は、最適化のためにデバッグオプションが設定されている可能性があります。プロジェクトの「プロパティ」の下にある「コードの最適化」プロパティを確認およびチェック解除します。
[プロジェクト]選択オプション[プロパティ]を右クリックし、[ビルド]タブに移動します。[コードの最適化]チェックボックスをオフにします。
ステップ#3:
それでもエラーが発生する場合は、デバッグ情報モードが正しくない可能性があります。 「ビルドの詳細設定」で確認して「フル」に設定します。
プロジェクト選択オプション「プロパティ」を右クリック「ビルド」タブに移動「詳細」ボタンをクリック「デバッグ情報」を「フル」に設定
ステップ#4:
それでも問題が解決しない場合は、次を試してください。
ソリューションファイルの「クリーン」と「リビルド」を行いますデバッグ中:モジュールウィンドウに移動(VSメニュー->デバッグ->ウィンドウ->モジュール)ロードされたモジュールのリストでアセンブリを見つけます。ロードされたアセンブリに対してリストされたパスが期待どおりであることを確認しますファイルの変更されたタイムスタンプをチェックして、アセンブリが実際に再構築されたことを確認しますロードされたモジュールが最適化されているかどうかを確認します
結論:
エラーではなく、特定の設定に基づいた情報であり、.NETランタイムの動作に基づいて設計された情報です。
同様の問題があり、デバッグモードでソリューションをビルドし、実行パスのpdbファイルを置き換えたときに解決しました。
私の場合、リリースモードのもので、デバッグするように変更しました