Internet ExplorerとVisual Studio .NET 2005によるデバッグ
デバッグセッションを開始する方法は何とおりもあります。最も簡単な方法の1つは、Internet Explorerの組み込みスクリプトデバッグ機能を使用することです。ASP.NET AJAXページのデバッグセッションを開始するには、デバッグしたいページに移動し、Internet Explorerのメニューから［表示］→［スクリプトデバッガ］を選択します（図2を参照）。この方法を使用する場合は、前のセクションの説明に従って、Internet Explorerでデバッグを有効にしておく必要があります。
図2からわかるように、［開く］と［次のステートメントで中断］という2つのオプションがあります。［開く］を選択した場合は、デバッガとしてVisual Studio .NETの使用を開始するか確認を求められます（図3を参照）。Visual Studio .NETをすでに開いている場合は、デバッグを開始することもできますし、デバッグ用にVisual Studio .NETの新しいインスタンスを開始することもできます。［次のステートメントで中断］を選択した場合は、そのページ内のスクリプト（またはそのページで参照されてるスクリプト）を実行するアクションが行われるまで何も起こりません。Internet Explorerでスクリプトコードが実行されると、Visual Studio .NET Just-In-Timeデバッガを使用するか確認を求められます。
Visual Studio .NETを開いてデバッグできる状態になっても、ページ内にスクリプトが埋め込まれていると、ブレークポイントを設定することはできません。ブレークポイントを設定しようとすると、Visual Studio .NETのステータスバーの下部に「This is not a valid location for a breakpoint」というメッセージが表示されます。この問題を解決する方法は何通りかあります。まず、デバッグセッションを開始したいコードにJavaScript "debugger" ステートメントを直接追加するという方法が使えます。これは実行時にコード内のその場所でブレークポイントを強制的に発生させるものです。ただし、この目的のためにASP.NET AJAXのSys.Debugクラスがあるので、こちらのほうがAJAXアプリケーションのデバッグに適した選択肢といえます。Sys.Debugクラスのfail関数を呼び出すことにより、コードの特定の行に達したときにデバッガをトリガすることができます。
Sys.Debug.fail関数のパラメータは1つだけで、このパラメータは障害の理由を表します。リスト1は、Sys.Debug.fail関数を使用して、Albumオブジェクトに歌が追加される直前にデバッグセッションに割り込む例を示しています。
var album = new Wrox.ASPAJAX.Samples.Album(); album.set_title("Sam's Town"); album.set_artist("The Killers"); //Force the debugger to appear Sys.Debug.fail("Debug song additions"); album.addSong(new Wrox.ASPAJAX.Samples.Song(3,"When you were young")); album.addSong(new Wrox.ASPAJAX.Samples.Song(7,"Uncle Johnny")); $get("lblTitle").innerHTML = album.get_title(); $get("lblArtist").innerHTML = album.get_artist();
JavaScriptのコード行の実行時にSys.Debug.failを呼び出してデバッグセッションをトリガするというのは便利な機能ですが、アプリケーションを実働環境に移す前にこれらの呼び出しを削除するのを忘れてはなりません。そうしないと、Internet Explorerでデバッグが有効になっている場合には常にデバッガがトリガされてしまいます。スクリプトのバージョンを2種類用意し（Microsoftではデバッグスクリプトとリリーススクリプトでこれを行っています）、ScriptManagerで適切なScriptModeを設定して、実行時にロードするスクリプトを決定するとよいでしょう（『Professional ASP.NET 2.0 AJAX』（Wrox, 2007, ISBN: 978-0-470-10962-5）の第9章「Testing and Debugging ASP.NET AJAX Applications」を参照）。こうするとコードを重複して持つことになりますが、リリーススクリプトでは空白文字をすべて除去してサイズを最小化し、デバッグスクリプトではデバッグ、トレース、アサーションなどの操作のために必要なSys.Debugクラスの呼び出しを含んだ読みやすいスクリプトを維持する、といった使い分けができます。
ページ内にスクリプトが埋め込まれている場合にデバッガをトリガするもう1つのオプションは、ページ内のJavaScriptコード全体を（.aspxページに直接含めるのではなく）専用のスクリプトファイルに移すというものです。この場合は、.jsという拡張子を持つスクリプトファイルをページから参照します（スクリプトファイルはHTMLマークアップと一緒にブラウザに送られるのではなく、実行時に別にロードされます）。こうしておけば、その外部スクリプトファイルにブレークポイントを設定することができます。たとえば図4の「Listing9-12.js」ファイルのJavaScriptコードでは、ブレークポイントが設定されています（このファイルは『Professional ASP.NET AJAX』（Wrox, 2007, ISBN: 978-0-470-10962-5）のダウンロードページから入手できます）。
F11キー（ステップイン）またはF10キー（ステップオーバー）を押してコードを1ステップずつ実行していくと、ASP.NET AJAXで必要な動的ロードスクリプトファイルの場所を選択するように求められることもあれば、「There is no source code available for the current location」というエラーに遭遇することもあります。これが起こるのは、「ScriptResource.axd」および「WebResource.axd」HTTPハンドラを使ってロードされた動的生成スクリプトコードにステップインしようとしたときです。この場合、Visual Studioがトレースできる分離された物理ファイルはありません。この問題は、初めはイライラするかもしれませんが、すでにVisual Studio .NETの一部になっている単純なツールで軽減することができます。
（Visual Studio .NET 2005 SP1はこの問題の解決に役立ちますが、やはりエラーの対処法を知ることが大切です。）
