再帰を多く含むコードを書きましたが、完了するまでにかなりの時間がかかりました。実行を「一時停止」して何が起こっているかを確認すると、次のようになります。
現在のメソッドのコードが最適化されているため、式を評価できません。
それが何を意味するのか理解できたと思います。しかし、私が困惑しているのは、ステップを押した後、コードが「最適化」されておらず、変数を確認できることです。これはどのように起こりますか？最適化されたコードと最適化されていないコードの間でコードをどのように切り替えることができますか?
Debug.Break（）行がコールスタックの一番上にある間は、式を評価できません。そのラインが最適化されているためです。F10キーを押して次の行（有効なコード行）に移動すると、時計が機能します。
デバッガーはFuncEvalを使用して、変数を「確認」できるようにします。FuncEvalでは、GarbageCollectorの安全な場所でマネージコードでスレッドを停止する必要があります。IDEで実行を手動で「一時停止」すると、すべてのスレッドができるだけ早く停止します。再帰性の高いコードは、危険な場所で停止する傾向があります。したがって、デバッガーは式を評価できません。
F10を押すと、次のFuncevalセーフポイントに移動し、機能評価が可能になります。
詳細については、FuncEvalのルールを確認してください。
デバッグ モードではなくリリース モードでアプリをデバッグしようとしているか、コンパイル設定で最適化がオンになっている可能性があります。
コードが最適化されてコンパイルされると、関数で使用されなくなった特定の変数が破棄されるため、そのメッセージが表示されます。最適化が無効になっているデバッグ モードでは、このエラーは発生しません。
以下は私にとってはうまくいきました、@Vinに感謝します。
VS 2015 を使用していたときにこの問題が発生しました。私の解決策: 構成で (デバッグ) が選択されています。Optimize Codeプロジェクトのプロパティの下にあるプロパティのチェックを外すことで、これを解決しました。
プロジェクト (右クリック) => プロパティ => ビルド (タブ) => コードの最適化のチェックを外す
これは私を夢中にさせました。マネージ コードとネイティブ コードをアタッチしようとしましたが、うまくいきませんでした。
これは私にとってはうまくいき、最終的にすべての式を評価することができました:
そのようなことはありませんのでご安心ください
[assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
あなたのAssemblyInfo
Microsoftの友人の友人がこれを送信しました：http： //blogs.msdn.com/rmbyers/archive/2008/08/16/Func_2D00_eval-can-fail-while-stopped-in-a-non_2D00_optimized-managed-method-that -pushes-more-than-256-argument-bytes-.aspx
最も可能性の高い問題は、メソッドのシグネチャが大きすぎるためにコールスタックが最適化されていることです。
同じ問題がありましたが、デバッガーで例外トラップをオフにすることで解決できました。[デバッグ][例外]をクリックし、例外を「ユーザー未処理」に設定します。
普段はオフにしていますが、たまに重宝します。終わったらオフにすることを忘れないでください。
VS 2010 を使用していたときにこの問題が発生しました。ソリューション構成で (デバッグ) が選択されています。プロジェクトのプロパティの下にあるコードの最適化プロパティのチェックを外すことで、これを解決しました。プロジェクト (右クリック) => プロパティ => ビルド (タブ) => コードの最適化のチェックを外す
評価：
.NET では、「関数評価 (funceval)」とは、デバッグ対象がどこかで停止している間に、任意の呼び出しを挿入する CLR の機能です。Funceval は、デバッガーが選択したスレッドを担当して、要求されたメソッドを実行します。funceval が完了すると、デバッグ イベントが発生します。技術的には、CLR はデバッガーが関数を発行する方法を定義しています。
CLR では、GC セーフ ポイント (つまり、スレッドが GC をブロックしないとき) と Funceval Safe (FESafe) ポイント (つまり、CLR が実際に funceval のハイジャックを実行できる場所) にあるスレッドでのみ funceval を開始できます。したがって、CLR の考えられるシナリオでは、スレッドは次のようにする必要があります。
マネージ コードで (および GC セーフ ポイントで) 停止: これは、ネイティブ コードで関数を実行できないことを意味します。ネイティブ コードは CLR の制御外にあるため、関数をセットアップできません。
最初のチャンスまたは未処理のマネージ例外 (および GC セーフ ポイント) で停止しました。つまり、例外の発生時に、可能な限り調査して、その例外が発生した理由を特定します。(例: デバッガーは、発生した例外の Message プロパティを評価して確認しようとする場合があります。)
全体として、マネージド コードで停止する一般的な方法には、ブレークポイント、ステップ、Debugger.Break 呼び出し、例外のインターセプト、またはスレッド開始での停止が含まれます。これは、メソッドと式の評価に役立ちます。
考えられる解決策: 評価に基づいて、スレッドが FESafe および GCSafe ポイントにない場合、CLR はスレッドをハイジャックして機能を開始することはできません。一般に、以下は、funceval が期待どおりに開始されることを確認するのに役立ちます。
ステップ1：
「リリース」ビルドをデバッグしようとしていないことを確認してください。リリースは完全に最適化されているため、議論のエラーにつながります。標準ツールバーまたは構成マネージャーを使用して、デバッグとリリースを切り替えることができます。
ステップ2：
それでもエラーが発生する場合は、最適化のためにデバッグ オプションが設定されている可能性があります。プロジェクトの「プロパティ」の下にある「コードの最適化」プロパティを確認してチェックを外します。
プロジェクトを右クリックし、[プロパティ] オプションを選択します。[ビルド] タブに移動し、[コードを最適化する] チェックボックスをオフにします。</p>
ステップ #3:
それでもエラーが発生する場合は、デバッグ情報モードが正しくない可能性があります。「Advanced Build Settings」の下で確認して「full」に設定します。
プロジェクトを右クリック [プロパティ] オプションを選択 [ビルド] タブに移動 [詳細設定] ボタンをクリック [デバッグ情報] を [フル] に設定</p>
ステップ #4:
それでも問題が解決しない場合は、次のことを試してください。
ソリューション ファイルの「クリーン」と「リビルド」を実行します。デバッグ中: モジュール ウィンドウに移動します (VS メニュー -> デバッグ -> ウィンドウ -> モジュール)。ロードされたモジュールのリストでアセンブリを見つけます。ロードされたアセンブリに対してリストされたパスが期待どおりであることを確認します ファイルの変更されたタイムスタンプをチェックして、アセンブリが実際に再構築されたことを確認します ロードされたモジュールが最適化されているかどうかを確認します
結論：
これはエラーではなく、特定の設定に基づく情報であり、.NET ランタイムの動作に基づいて設計されたものです。
私の場合、ソリューションに 2 つのプロジェクトがあり、スタートアップ プロジェクトではないプロジェクトを実行していました。スタートアッププロジェクトに変更すると、デバッグが再び機能し始めました。
それが誰かを助けることを願っています。
私の場合、私はリリースモードにあり、デバッグするように変更しましたが、すべて機能しました
あなたが見ているのは最適化の結果であると私は信じています-時には変数が再利用されるでしょう-特にスタック上に作成されたもの。たとえば、2つの（ローカル）整数を使用するメソッドがあるとします。最初の整数はメソッドの開始時に宣言され、ループのカウンターとしてのみ使用されます。2番目の整数は、ループが完了した後に使用され、後でファイルに書き出される計算結果を格納します。この場合、オプティマイザーは最初の整数を再利用して、2番目の整数に必要なコードを保存することを決定できます（MAY）。早い段階で2番目の整数を調べようとすると、「式を評価できません」というメッセージが表示されます。正確な事情は説明できませんが、