次の方法で共有

Content Pipeline その４ そのデバッグ

  • [アーティクル]

コンテント・パイプラインのデバッグ

前回は、実際のコードを見ながらコンテント・パイプラインのカスタマイズの方法を紹介しました。前回のように、ロジック自体が簡単な場合は良いのですが、もう少し複雑なプログラムをコーディングしている時に必要になるのが、インポーターやプロセッサのコードをデバッグすることです。

ここで問題なのは、ゲーム本体をデバッグする感覚でブレークポイントをコンテント・パイプラインのコード部分に設定してビルドしたとしても、何事も無かったかのようにビルトが終了してしまうということです。コンテント・ビルドは普通にアプリケーションを走らせるのと違い、GSEが水面下でMSBuildを実行しているので、GSE上で走らせるアプリケーション用のブレークポイントを設定しても意味がないからです。

 

コンテント・パイプライン用に書いたコードをデバッグする方法としては、JIT(Just-In-Time)デバッガをつかう方法とCLRデバッガをアタッチする二種類の方法があります。

 

JITデバッガを使う

Visual Studio 2005をインストールしているか、.Net Framework 2.0 SDK(無償)をインストールしたときに使えるようになるCLRデバッガがあるWindows XP環境なら、コード部分に

     System.Diagnostics.Debugger.Launch();

と、書くことで、ビルド実行時に以下のようなJITデバッガ選択ダイアログが開きます。

このダイアログから、CLRデバッガ、またはVisual Studio 2005をデバッガとして起動することで、コンテント・パイプライン用コードのデバッグができます。

 

CLRデバッガをアタッチして使う

残念ながら、現状では、前述のJITデバッガ機能はWindows Vista上では動作しません。そこでWindows Vista上でコンテント・パイプラインをデバッグするにはCLRデバッガ(Visual Studio 2005でも可)をVisual Studio C# Expressにアタッチしてデバッグする方法を紹介します。CLRデバッガは、.Net Framework 2.0 SDK(無償)をインストールすることで使えます。

まずは、以下のコードのように、デバッガがアタッチしている時にのみ中断するようにします。

     if (System.Diagnostics.Debugger.IsAttached)
        System.Diagnostics.Debugger.Break();

 

次にVisual Studio C# Expressを実行した状態で、CLRデバッガ(スタートメニューから、Microsoft .Net Framework SDK v2.0/Tools/Microsoft CLR Debuggerを選択)を別に実行し、CLRデバッガ上で 「Tools/プロセスにアタッチ」 を選択すると以下のようなダイアログボックスが開きます。

この選択可能なプロセスのリストの中から、VCSExpress.exeを選択してから、アタッチボタンを押します。これで、CLRデバッガがVisual Studio C# Expressをデバッグしている状態になります。

この状態で、Visual Studio C# Express上でビルドを実行すると、先に書いたコード部分で実行が中断し、後はCLRデバッガ上でVisual Stuidio C# Express上と同じようにデバッグができます。実行中断したときに逆アセンブルが表示されいる場合がありますが、逆アセンブルウィンドウ上から右クリックして 「ソースコードへ移動」 を選択することで、C#のソースコードが表示されます。

また、デバッグした後にCLRデバッガ上で続行を選択すると、ビルド作業が続行されるので、一度アタッチしてしまえば何度でも簡単にデバッグすることができます。但し、インクリメンタルビルドが働いているので、単にビルドを複数回実行すると二回目以降は実際にビルド作業が入らないのでデバッグすることができません。コンテントの量が少ない場合はリビルドし、コンテントの量が多い場合はデバッグしたいコンテントファイルを更新してからビルドするのが効率的です。

 

まとめ

今までは、私もJITデバッガを使っていたのですが、この方法だと常にデバッガを起動しようとするので、急いでいるときにコンテント・パイプラインのデバッグを終えてコードを戻すのを忘れて、他人にコードを渡してしまうなんてことも考えられます。それに対して、CLRデバッガをアタッチする手間はあるものの、逆に言えばデバッガをアタッチしない限りは、普通に動作するのでJITデバッガを使うときの問題は起きませんし、特定の例外が発生したときに中断するようにCLRデバッガ上から設定(Debug/例外メニューを使う)できるという利点があります。欠点を強いていうなら、中断するコードを大量に残したままに…なんてことがあるくらいでしょうか？

以上をまとめると、

  • Windows Vista上で開発してる場合はCLRデバッガ(Visual Studio 2005でも可)をアタッチして使う
  • Windows XP上で開発している場合は好みによって使い分ける

と、いった感じになります。

プログラムが思い通りに動かない時にデバッガを使うことで、問題点を直ぐに見つけることができることが多いので、カスタムインポーターや、カスタムプロセッサが期待通りに動かない時には、今回の方法でデバッグして効率的に問題を解決しましょう。

Comments

  • Anonymous
    December 20, 2007
    コンテントプロジェクト XNA 2.0のプロジェクジェクトをソリューションエクスプローラで見ると以下のようになっています。 参照設定の項目が二つあることに気づいたでしょうか？これは Content がWindowsGame1のサブプロジェクトになっているからです。XNA