.NET開発者デバッグツール

翻訳者から：デバッグ中に文字の読み込みを制御する情報を探していたときに、偶然この記事を見つけました。 そして、この問題に関する情報はあまりありませんでしたが、私は喜んで記事全体を読みました。 そのほとんどはその前に私に知られていましたが、すべてではありませんでした。 私は、多くの人が自分にとって有益なものを見つけると確信しています。 この記事は1年半前に書かれたものですが、全員が登場してすぐに新しいバージョンのスタジオと関連ツールに切り替えるわけではないため、記事の関連性は失われていません。



バグは、コードライフサイクルの2つの段階で発生します。開発中と実稼働中です。 多くの場合、コードを記述した瞬間から10〜15分以内に発生するエラーはバグとは見なされません。これらは、コードを記述するプロセスの一部にすぎません。 また、本番環境や数日前に記述されたコードをテストするときに発生する問題と呼ばれるバグもよくあります。 おそらくそれらをキャッチするのが難しいためです（コードはすでに忘れられています）。 いずれにせよ、コードが意図したとおりに動作しない場合、それはバグであり、キャッチして修正する必要があります。

効率的なデバッグの4つの柱

• 適切なツール。 これが記事の目的です。 しかし、他の3つがなければツールは役に立ちません。
• 疎結合オブジェクトを優先するアーキテクチャとコード構築プラクティスの使用と、私が本当に明らかにコードと呼んでいるものの作成-ROCロック！ これらのプラクティスは、バグを見つけるのに役立ち、新しいバグを追加するだけの変更を行わないようにします。 そして、 ブライアンW.カーニハンとPJプラウガーの「プログラミングスタイルの要素」（Computing Mcgraw-Hill、1978）を読み直すのに遅すぎることはありません。
• TDD（テストによる開発）を使用します。 高度に接続されたユーザーインターフェイス以外の何かを開発していて、TDDを使用していない場合、あなたは片手で背中を縛られた開発者です。 生産性が自分よりも低くなり、コードの信頼性が本来よりも低くなります。
• デバッグ手法。 多くの開発者はすぐに「ソリューション開発」の手順に進みます。その結果、バグ修正につながることはほとんどありませんが、多くの場合、新しい修正が作成されます。

ブレークポイントを使用する

多くの開発者は、デバッグが「そのように機能する」ため、Visual Studioのすべてのデバッグ機能を知りません。 たとえば、すべてのVS開発者はブレークポイントに精通していますが、多くの人は[ブレークポイント]ウィンドウで何ができるかを知りません。







[ブレークポイント]ウィンドウを開くには、[デバッグ] | [ Windows | ブレークポイント ウィンドウには、設定したすべてのブレークポイントのリストが表示されます。 どのポイントがどのコード行に対応するかわからない場合は、それをダブルクリックするだけで、関連するコードがエディターで開きます。



目的のポイントを決定したら、動作時に何が起こるかを制御できます。 同じ変数を繰り返しチェックし、ループにブレークポイントを設定する開発者を見ました。 ブレークポイントを右クリックして[ヒット時（トリガー条件）]を選択すると、トリガーされるたびに中間ウィンドウに表示されるメッセージを指定できます。 メッセージにいくつかの定数を含めることができます。たとえば、$ Callerを使用すると、ブレークポイントを含むコードを呼び出したメソッドの名前を表示できます。 また、変数を中括弧で囲むことにより、変数を含めることができます。たとえば、メッセージ内の{Me.NameTextBox.Text}は、Textフィールドの値を表示します。



When Hitダイアログの別のオプションでは、プログラムをブレークポイントで停止するかどうかを指定できます。 停止を選択すると、作成時に各メッセージが表示されます。 そうしないと、プログラムの実行後にすべてのメッセージを表示できます。



特定の条件下でのみ実行を停止する場合は、[条件]または[ヒットカウント]オプションを選択できます。 [条件]オプションを使用すると、停止が発生する論理条件を設定できます（たとえば、Position> 30）。 最後の停止以降に変数の1つが変更された場合も停止できます。 Hit Countオプションは、ブレークポイントがn回（またはn回ごと）トリガーされる場合にのみ実行を中断します。 これは、サイクルの終わりにどこかで停止する必要がある場合に特に便利です。



ちなみに、私の経験では、アプリケーションの一部で問題が発生した場合、引き続き問題が発生します。 経験から同じことが言えれば、Visual Studio 2010の追加機能が気に入っています。ブレークポイントに名前を付けて、それぞれの目的を記憶し、XMLファイルにエクスポートできます。 次回それらが必要になったら、それらをインポートしてデバッグを開始できます。 インポート/エクスポートは、ブレークポイントウィンドウの上部にあるツールバーを使用して実行できます。

コードを表示してスキップ

コード生成が好きです（.NETでそれを行う方法に関する本を書きました）。 しかし、原則として、スタジオとフレームワークによって生成されたコードを歩き回っても、何の役に立つものも得られません。 そして、これは問題を見つけるのに役立たないため、デバッグプロセスの生産性が低下し、回避する方が良いことを意味します。



Visual Studioのどのバージョンでも、[デバッグ] | [ 一般的な設定ダイアログでは、[マイコードのみ]オプションを選択して、記述していないコードの表示を停止できます。 後でこれを無効にする必要がある場合（たとえば、生成されたコードのどこかで例外が発生した場合）、[デバッグ]メニューの[オプションと設定]を選択してこれを行うことができます（ この項目はVS2010-約翻訳のみにあります ）。



コードの一部を歩き回るのにうんざりしている場合は、2つの属性のいずれかを使用できます。 メソッドにDebuggerHidden



属性を設定すると、このメソッドに入ることはありません。 DebuggerNonUserCode



属性を設定した場合、[ジャストマイコード]オプションが有効になっていてオフになっている場合、この属性にDebuggerNonUserCode



することはできません。 2番目の方法を使用することをお勧めします。



一方、Microsoft .NET Frameworkコードのどこかでエラーが発生した場合、生成されたコードだけでなく、フレームワーククラスのコードも調べる必要があります。 そして、あなたはそれをすることができます！ まず、Just My Codeオプションが無効になっていることを確認します。 次に、[シンボル]セクションの[オプションと設定]ダイアログで、[Microsoft Symbol Server（VS 2010）]を選択するか、シンボルパスを次のように設定します。 referencesource.microsoft.com/symbols



referencesource.microsoft.com/symbols



）。 これにより、.NETクラスコードウォーキングをサポートする文字をロードできます。 ただし、それらをダウンロードする必要があります。 VS2010では、[すべてのシンボルを読み込む]ボタンをクリックできますが、ダウンロード中は我慢する必要があります。



特定のアセンブリを選択するには（またはVS2008を使用している場合）、デバッグプロセスを停止するモードで、（モジュール）ウィンドウを開き、アプリケーションによって読み込まれたDLLの一覧で、必要なDLLを右クリックし、（モジュールを読み込む）を選択してこのDLLの文字を読み込みます。 もちろん、まだ待つ必要がありますが、それほど長くはありません。



私はプロパティに有用なコードを書き、それらを段階的にデバッグできるようにしたい人の一人です。 VS2008SP1以降、オプション（プロパティと演算子のステップオーバー）が登場しました。このオプションは、プロパティと演算子の段階的なデバッグをオフにします。 また、VS2010ではデフォルトでオンになっているため、オフにする必要があります。

データの可視化

奇妙なことに、多くの開発者はVisual Studioのデータビジュアライザーに慣れていません。 停止モードで変数にカーソルを合わせると、ツールチップにその変数の値がポップアップ表示されます。 虫眼鏡のアイコンも表示される場合があります。クリックすると、デフォルトのビジュアライザーで変数の値が開きます。 アイコンの横にドロップダウン矢印が表示されている場合、矢印をクリックすると、このデータタイプの他のビジュアライザーが表示されます。 たとえば、文字列変数の場合、テキスト、XML、およびHTMLビジュアライザーが表示されます。 HTMLを文字列に保存する場合、HTMLレンダラーはブラウザーでHTMLがどのように表示されるかを理解するのに役立ちます。



[ウォッチ]、[自動]、および[ローカル]ウィンドウでビジュアライザーを使用することもできますが、変数を頻繁に見る場合は、ツールチップの最後にある押しピンをクリックしてその場所に「釘付け」できます。 次に、コードのこの部分を次に見ると、ツールチップが自動的にポップアップ表示されます。



ヒントといえば、変数の値を変更するためにそれらを使用できます。 VS2010では、さらに多くのヒントがあります。ウィンドウにハングアップし、デバッグセッション中は常に存在し、終了後も最後のセッションの変数の値を表示するヒントを作成できます。 ただし、最もクールなツール（デバッガーキャンバスとIntelliTrace）は、VS2010 Ultimate Editionでのみ使用できます。

外部ツール

Visual Studioが唯一のデバッグツールではなく、貯金箱に追加できる数の外部ツールとサードパーティツールがあります。 無料のものにのみ焦点を当てます。



すべての外部ツールがサードパーティ製ではありません。 Windowsサービスを記述する場合、それらのデバッグは簡単な作業ではないことがわかります。 デバッグのためにそれらに接続できますが、この時点でOnStartコードと初期化はすでに完了しています。 バグがサービスの開始を妨げている場合、問題を説明する情報を収集するのではなく、何が問題なのかを推測することしかできません。



同様の状況で、Just-in-Time（JIT）デバッグと自動実行を構成できます。サービスの開始時またはエラーの発生時にデバッグセッションが開始されます。 しかし、これを行うには、外部ツールを使用する必要があります。



JITデバッグの構成はこの記事の範囲を超えているため、 MSDNの対応する記事を参照できます。 この記事では、Global Flags Editor（gflags.exe）の使用を推奨しています。 見つからない場合は、レジストリを修正してJITデバッグを有効にする方法について説明します。 ただし、WinDbgの使用方法を学習する必要があります。

サードパーティのビジュアライザー

Visual Studioのビジュアライザーについては既に説明しましたが、他にもたくさんあります。 DotNetDanのDataSet Visualizerは、データセットの内容を知る必要がある場合は非常に素晴らしいです（ ブログで説明しました ）。







それ以来、私はすでにRightHand DataSet Visualizerを発見し、それを使い始めました。 これは、各データセットテーブルのウィンドウを開くことができるMDIアプリケーションです。 さらに、[リレーション]ウィンドウには、現在表示されているテーブルが表示されます。



テーブルを表示するグリッドは単純ではありません。ウィンドウの上部にある長方形に列をドラッグして、この列でテーブルをグループ化できます。 また、データセット内のデータを変更し、RowStateフィルターを変更して、特定のRowStateを持つ行のみが表示されるようにすることもできます（たとえば、削除された行のみ）。 データセットの一部のプロパティを引き続き監視（および変更）できます。 また、データセットをXMLファイルにアップロードしたり、以前に保存したデータからテストデータをロードしたりすることもできます。



DotNetDanのDataSet Visualizerはデータをより高速にロードするため、RightHandのフルパワーが必要ない場合に備えて、データを残したことに注意してください。



ASP.NETアプリケーション用のWeb Visualizerもあります。 このビジュアライザーは、ASP.NETページオブジェクトのツールチップで利用可能です（ASP.NETコードのMeおよびこれを含む）



Webビジュアライザーを使用すると、サーバーオブジェクトのサーバー変数コレクションとリクエストオブジェクトのフォームコレクションの任意のデータを見ることができます。 ブラウザのクエリ文字列と、SessionおよびApplicationオブジェクトの内容も確認できます。 ただし、スカラーデータ以外のオブジェクトのセッションおよびアプリケーションの場合は、オブジェクトのタイプの名前のみが表示されます。



Entity Framework（EF）へのキャッシュおよびLINQクエリを監視できるほか、EFへのSQL出力LINQクエリを表示できるビジュアライザーもあります。 唯一の悲しいことは、ビジュアライザーのカタログが1つもないことです。



すべてではありませんが、多くはVisual Studio Extension Managerで見つけることができます。 ASP.NET MVC Routing Visualizerを含む。 ASP.NET MVCまたは単純なASP.NETでルーティングを使用する場合、このツールが役立ちます。 ルーティングルール間の相互作用は、予期しない結果（「このページを取得する理由」）を生成する可能性があります。また、これらのルールのデバッグは難しい場合があります。 ビジュアライザーを使用すると、URLを入力し、ルーターがURLをデコードする方法（各URLに使用されているルールに関する情報など）を確認できます。 停止モードで使用するには、global.asaxファイルに切り替えて、RouteTableにカーソルを合わせます。 ツールチップが表示されたら、ルートコレクションまでスクロールし、虫眼鏡アイコンをクリックします。

トレース

定義上、トレースは魅力的ではありません。 ただし、本番環境では、再現が困難な（また、それ自体で表示および非表示になる）とらえどころのないバグの1つに遭遇すると、トレースが必要な情報を取得する唯一の方法です。 これを行うには、まず、ログ内のメッセージの記録を整理する必要があります。これにより、バグをキャッチするための情報が得られます。 ただし、この情報を有効にするには、ログの内容を分析するツールが必要です。



.NETの世界にはトレース用のパッケージが多数ありますが、私はlog4netを使用します。 他の機能の中でも、log4netを使用すると、デバッグメッセージをコードに埋め込み、アプリケーションを再構築することなく、作業中にデバッグメッセージを有効または無効にできます。 注：log4netは非常に柔軟なツールであり、おそらく必要以上のものです。



結果のログの読み取りに関しては、Lizard LabsのLog Parser Lizardを使用します。 無料版では、いくつかの機能が制限されています（価格は支払われています-約25ドル）が、私はそれらを必要としませんでした。 Log Parser LizardはSQLに似た構文を使用してログリクエスト（CSVおよびXMLファイルを含む）を作成し、すぐにIISログ形式、Windowsイベント、およびlog4netを理解します。 結果はテーブルに表示されるため、サーバーエクスプローラーのように見えます。

おわりに

これらのツールはすべて便利ですが、最も重要なのは正しいデバッグ手法であることを忘れないでください。 ツールはバグを見つけて修正するのに役立ちますが、ソリューションの開発と適用を可能にするのはデバッグ手法です。