コール・スタックの外部コードは、自分のコードが正常であるという証拠ですか？

Question

コンテキスト：

MEFを使用するホストアプリケーションで実行されているWPFアプリケーションがあります。このホストアプリケーションは、私が働いている別の部門によって開発されており、私たちが提供するものは、私たちが使用するいくつかのアセンブリとC＃インタフェースです。私のWPFアプリケーションには、ホストアプリケーションにエクスポートされるブートストラップがあります。

問題：

私がいる定期的な問題は、私はいくつかのボタンのClickイベントに私のイベントハンドラのいずれかを実行したときにWPFアプリケーションのUI要素のすべてが消えていることです。だから当然、私はハンドラの1行目の最初の行にブレークポイントを置き、デバッグします。しかし、呼び出しスタックに表示されるのは私の行（ブレークポイントを置いた場所）です。残りの呼び出しスタックは外部コードを持っています。だから私はこれがホストアプリケーションの問題か、私が導入したものかどうかを調べようとしています。コールスタックは、PresentationCore、WindowsBase、mscorlib、およびホストアセンブリに対して、Native-to-Managed行とManaged-to-Native行を1つだけ呼び出します。

質問：私は、問題がホストにあることを言うのコールスタックはトップのみでの私の1つのブレークポイントラインを持っており、残りはホストアセンブリまたはWindowsアセンブリされていることを見て

は、この十分ですアセンブリ？それはWindowsアセンブリのいずれも仮定していません。私のブレークポイントがヒットする前にUI要素が消えます。

Answer 1

コールスタックに表示されるのは私の行（ブレークポイントを配置した場所）です。コールスタックの残りの部分には外部コードがあります。

これはまさにコールバックで起こるはずのものです。あなたのコードはコードの上にあり、フレームワークコードはコードのすぐ下にあります。

問題はホストアセンブリにあると言えるでしょうか？

いいえ、二つの理由：

• あなたのコードは、外部のフレームワークで使用するために自分自身をブートストラップする責任があります。適切に処理できない場合は、外部コードの問題が表示されることがあります。理想的には、外部コードがこれらをキャッチし、セットアップに問題があったことを通知する必要がありますが、フレームワークが正常に機能しなくても例外をスローしたとしても、コードに問題が残っています。
• コードは、矛盾した状態になる。もう一度、理想的には外部フレームワークでこれを検出する必要がありますが、究極の修正はあなたのコード内にあります。

UI要素が私のブレークポイントにヒットし前消えます。

UI要素には、自分自身を再描画するために実行中のプログラムが必要です。そのため、ブレークポイントを持つUIのデバッグに問題が生じる可能性があります。デバッグトレースをコードに追加し、ブレークポイントなしで実行すると、より良い結果を得ることができます。