WPFのデータは、シンプルですばらしい。Visual Basic 3以来、マイクロソフトは、柔軟性と強固性、そして利用容易性を魔法の組み合わせを模索してきた。そしてWPFは、完全ではないが、以前のそれよりもはるかにすばらしい。しかし残念ながら、故障モデルは諸刃の剣である。アプリケーションクラッシュの例外を投げる代わりに、バインディングエラーは、こっそりトレースリスナに書き込む。これは、根本原因を見つけるのが信じられないほど難しくなる。
WPFのデータバインディングに関する主なドキュメントは、シンプルなタイトルのデータ バインディングの概要である。デバッグやトラブルシュートするまでは、なにも提供されないが、WPFとSilverlight開発者は、必ず読むべきである。全体のセクションは、文字通りひとつのセンテンスで構成されている。
デバッグの仕組み
バインディング関連オブジェクトのPresentationTraceSources.TraceLevel添付プロパティをセットすると、バインディングに関するステータスを取得することができます。
Karl Shifflett氏は、データバインディングのトレースの読み方を提供しているが、彼のアドバイスは、チェックするものが明確であるか、DataContextに正しいオブジェクトが含まれていないことが前提になっている。また、しばしばSilverlightは、IDEの外で実行されるため、常に使える訳ではない。
幸運なことに、これらを少し簡単にする2つのサードパーティ製品が存在している。Cory Plotts氏のSnoopは、あらゆる.NET 3.5と4.0のWPFアプリケーションにアタッチすることができる。一度読み込むと、コントロールツリー上にプロパティの値や、あらゆるデータバインディングエラーなどの詳細な情報が提供される。Snoop 2.6は、Microsoft Public License下で、CodePlex上で提供されている。
もうひとつのツールは、Karl Shifflett氏のGlimpseである。このツールは、Silverlightアプリケーションにはアタッチできず、これをコンパイルしなくてはいけない。起動すると、フローティングウィンドウを通じて、未ハンドルのアプリケーションとデータバインドの例外をユーザに通知する。Glimpse for Silverlightは、Karl氏の個人ブログからダウンロードすることができる。
しばしば引用されるテクニックは、ダミー値コンバータを追加して、その中にブレイクポイントをセットすることだ。Marlon Grech氏は さらに一歩進んだデバッグコンバーターの書き方を公開している。コードにbreakステートメントをハードコードすることによって、手動でブレイクポイントをセットする必要がない。