関数ツリー - .NET用のVisual Studioデバッガのヒントと秘訣




visual studio 関数ツリー (10)

私はVSのデバッガで何年も働いていましたが、今は今まで気づいたことのない機能を見つけて、「気がついて!どうして私はそれを見逃すことができましたか?

[免責事項:これらのヒントは、VS 2005でC#プロジェクトで動作し、VSまたは他の言語の古いインカネーションの保証はありません]

オブジェクトのインスタンスを追跡する

与えられたクラスの複数のインスタンスを扱う? どうやってそれらを区別することができますか? プリガベージコレクションのプログラミング時代には、参照を追跡するのは簡単でした。単にメモリアドレスを調べるだけでした。 .NETでは、これを行うことはできません。オブジェクトは動かすことができます。 幸いなことに、ウォッチビューでは、ウォッチを右クリックして[Make Object ID]を選択できます。

ウォッチビューhttp://img403.imageshack.us/img403/461/52518188cq3.jpg

これは、インスタンスの値の後に{1#}、{2#}などを追加し、事実上インスタンスに一意のラベルを与えます。 これは次のようになります。

番号のついたインスタンスhttp://img383.imageshack.us/img383/7351/11732685bl8.jpg

ラベルはそのオブジェクトの存続期間中存続します。

監視対象変数の意味のある値

デフォルトでは、監視対象変数の値はその型です。 そのフィールドを表示したい場合は、フィールドを拡張する必要があります。フィールドが多数ある場合や複雑な操作を行う場合は、時間がかかる(またはタイムアウトになることもあります)。

ただし、事前定義されたタイプによっては、より意味のある情報が表示される場合があります。

  • 文字列は実際の内容を示します
  • リストや辞書には要素数などが表示されます。

意味のある情報http://img205.imageshack.us/img205/4808/37220487md1.jpg

それは自分のタイプのために持っているといいのではないでしょうか?

うーん...

.NET Reflectorでは、カスタムタイプのDebuggerDisplay属性を使用してこれを簡単に実行できます。

[System.Diagnostics.DebuggerDisplay("Employee: '{Name}'")]
public class Employee {
    public string Name { get { ... } }
    ...
}

...再実行し、そして...

タダ! http://img60.imageshack.us/img60/926/79816018ha1.jpg

ここにはさらに詳しい情報があります: MSDN

すべての例外を解除

...コードで扱われるものさえも! 私は、私が生まれて以来、これについてこれまで知っていなかったので、私はそのようなn00bですが、ここにそれはとにかく行く - これはいつか誰かを助けるかもしれない:

例外がスローされるたびに、デバッグされたプロセスをデバッグモードに強制的に切り替えることができます。 これまでに数時間にわたってバグの捜索を行っただけで、このようなコードに遭遇しましたか?

try {
    runStrangeContraption();
} catch(Exception ex) {
    /* TODO: Will handle this error later */
}

すべての例外をキャッチすることは、これらの場合には非常に便利です。 これは、 デバッグ>例外...(Ctrl-Alt-E)で有効にすることができます。 必要な例外の種類ごとに、[Thrown]列のボックスにチェックを入れます。

それらは私のためのいくつかの額の叩きの瞬間だった。 あなたを共有したいですか?


2つのコード内のトリック:

私はSystem.Diagnostics.DebuggerStepThrough属性が本当に好きです。 クラス、メソッド、またはプロパティにアタッチして、デバッグ時にVSがデフォルトでコードを入力しないようにすることができます。 あなたが本当にデバッグする必要がある場合は、無視されたコードにブレークポイントを置くことができるので、 DebuggerHidden属性よりも優先します。

別の(時には)便利な呼び出しはSystem.Diagnostics.Debugger.Launch()です。 実行がヒットすると、「デバッガの選択」ダイアログが表示され、デバッガが起動します。 やや失礼ですが、プロセスにアタッチするのは特に面倒です。他のプロセスによって生成され、すぐにコードを実行するプロセスです。



イミディエイトウィンドウで.load sos :)


ツール - >プロセスへのアタッチ - 忘れがちですが、Webページ、別のプロセスに読み込まれたマネージコード(アドインモデルと考える)、またはアンマネージドコードでもスクリプトをデバッグできます。 興味のあるデバッグの種類を自動的に選択させるように注意してください。

トレースポイント(およびその他のブレークポイント機能...ブレークポイントを右クリックして、楽しくてください)! - http://blogs.msdn.com/saraford/archive/2008/06/13/did-you-know-you-can-use-tracepoints-to-log-printf-or-console-writeline-info-without-editing-your-code-237.aspx

即時のウィンドウは素晴らしいです。

リモートデバッグは、アプリケーションを配備する場合(および問題を再現できるマシンに到達できる場合)に非常に便利です。

より多くのトンがあります。 WinDbgとSoSを試してみてください!


プロセスに接続し、未使用のキーボードショートカットに割り当てるためのマクロを作成します。 デバッグ - >プロセスにアタッチ - >プロセスリストのプロセスを検索 - > ...


ループ内のコード、ループから呼び出されるメソッド、または複数のスレッドから呼び出されるメソッドなどの特定の条件セットでのみ失敗するコードがある場合、条件付きブレークは非常に便利です。 関心のある行にbreak文を置き、エラーの場合と一致する条件を設定します。 ( here簡単な例がhereます)


私からのいくつか

  • [ツール] - > [オプション] - > [デバッグ]の[コードを有効にする]オプションをオフにします。
  • 条件付きブレークポイント - ほとんど毎日私の人生を救う
  • 物事が醜い場合は、.NETフレームワークソースを使用する

私が学んだもう一つの素敵なトリックです:

System.Diagnostics.Debugger.Break()

プログラムによって、デバッガは次の命令でブレークします。 本当にいいところは、デバッグ情報なしで、 リリースモードでコンパイルされたプログラムでも動作します。


私は作成した新しいスレッドに常に "Name"プロパティを設定します。 そうすれば、私がデバッグしているときに、別のスレッドをより簡単に識別することができます。


try {
    // do something big
}
catch {
    // breakpoint set here:
    throw CantHappenException("something horrible happened that should never happen.");
}

最初にスローされた例外はどのように見えますか? ウォッチウィンドウで、$ exception







hidden-features