演習 - App Service Web アプリに Visual Studio デバッガーをアタッチする

完了

この時点で、アプリは Azure にデプロイされていますが、正しく機能していません。 アプリはまだローカルで動作しているため、詳細な調査を行わずに問題の原因を正確に特定することは困難です。 Visual Studio を使用すると、Azure 上の App Service プロセスにデバッガーをアタッチするという簡単な方法によって、この問題を解決しやすくなります。 この演習では、アプリをローカルで実行しているかのようにデバッグできます。

Note

デバッガーをアタッチする前に、ローカル コードの状態が Azure にデプロイされたものと一致することを必ず確認してください。 これにより、ローカルのシンボル ファイルとソース コードが、デプロイされたアプリと一致します。 実際のアプリでは、Git を使用してプロジェクトを管理している場合、デプロイされたものと同じコミットまたはリリースをチェックアウトする必要があります。

デバッグ設定を構成する

成功を確実にするために、Azure でアプリをデバッグする前に、Visual Studio で次の手順を完了していることを確認してください。

1. まず、少なくとも 1 回はプロジェクトが正常にビルドされていることを確認します。 ビルドが成功すると、ソース コードと必要なコンパイル済みファイルの準備が整います。 アプリケーションがローカルで実行されている場合は、必ずアプリを停止してください。

2. 上部の Visual Studio メニューから [デバッグ] > [オプション] に移動します。 [マイ コードのみを有効にする] がオフになっていることを確認して、[OK] を選びます。

   この設定を変更すると、Visual Studio は、ローカルの bin フォルダーから必要なシンボル ファイルを使用して、Azure にデプロイされた最適化されているコードをデバッグできます。 シンボル ファイルは、コンパイル済みで実行されるコードと Visual Studio のソース コードの間のブリッジとしてデバッガーによって使用されます。そのため、ローカル ソース コードがデプロイ アプリと一致することが重要です。

   

デバッガーを App Service にアタッチする

1. Visual Studio の上部にあるメイン メニューから、[デバッグ] > [プロセスにアタッチ] を選んで、対応するダイアログを開きます。 このウィンドウを使用すると、さまざまなターゲットに接続してアタッチできます。 ここでは、前の手順で作成した App Service インスタンスに接続します。

2. [接続の種類] ドロップダウンを選び、[Microsoft Azure App Service] オプションを選びます。

3. [接続先] フィールドの横にある [検索] ボタンを選んで、Azure サブスクリプションとアプリ サービスを参照できるダイアログを開きます。

4. 前の手順で作成した GitHubBrowser123 アプリ サービスを見つけて選び、[OK] を選びます。

5. 接続できるプロセスの一覧に w3wp.exe プロセスが表示されます。これは、デプロイされたアプリケーションをホストする Azure App Service のメイン プロセスです。 そのプロセスを選び、右下にある [アタッチ] を選んで、Visual Studio デバッガーを接続します。

   

6. Index.cshtml.cs で、OnPost メソッドの最初の行に移動し、左余白をクリックしてそのメソッドにブレークポイントを設定します (または右クリックして [ブレークポイント]>[ブレークポイントの挿入] を選びます)。

   Index.cshtml.cs 内部の OnPost メソッドは、アプリのロジックの大部分を処理します。

7. 必要に応じて、デバッグ セッションのシンボル ファイルが Visual Studio によって読み込まれたことを確認することもできます。 [デバッグ] > [Windows] > [モジュール] の順に移動し、モジュール ウィンドウを開きます。 このウィンドウは、前に行った [マイコードのみ] の構成の変更後に、GitHub ブラウザー .dll ファイルのシンボル ファイルが正常に読み込まれたことを示しているはずです。

   

バグのトラブルシューティング

シンボルが読み込まれたら、Azure でホストされているアプリを、ローカルの場合と同じようにデバッグできます。

1. Visual Studio でブレークポイントを設定した状態で、ブラウザーのアプリに切り替え、アプリの検索ボックスに「dotnet」の値を入力し、[送信] を選択します。 Visual Studio で OnPost メソッド内のブレークポイントにヒットします。 初めての同期には少し時間がかかる場合があります。このコードは、IConfiguration サービスを使用して GitHubUrl 値の取得を試みます。 既定では、構成サービスによってアプリの appsettings.json ファイルから値が読み込まれます。

2. Visual Studio デバッグ コントロールのステップ オーバー ボタンを使用して (または F10 を押して)、searchUrl を作成するコード行に移動します。 その上の githubUrl 変数の上にマウス カーソルを置くと、値が現在 null であることがわかります。 このコードはローカルで正常に機能していました。では、Azure で値が null になるのはなぜでしょうか。

3. appsettings.json ファイルを開いてさらに調査しましょう。 このファイル内には、ログに関する構成設定がいくつかありますが、GitHubUrl の値はありません。

4. appsettings.Development.json ファイルを開きます。

   サンプル プロジェクトを設定すると、appsettings.Development.json の構成設定が更新されます。 このファイルには、Azure にデプロイしたときではなく、開発中に実行されている間にだけ適用される構成が含まれています。 Azure でホストされているアプリケーションの運用バージョンの構成を設定し忘れることは、バグの一般的な原因の 1 つです。

   

5. appsettings.Development.json からキーと値のペア GitHubUrl をコピーし、2 つのファイルが一致するように最上位の appsettings.json ファイルに貼り付けます。 アプリが Azure に再びデプロイされると、それと一緒に appsettings.json ファイル内の新しい構成値が伝達されます。

   appsettings.json ファイルは次のようになります。

   

6. ローカル デバッグ セッションと同様に、Visual Studio の上部にある [停止] ボタンを押すと、デバッガーを App Service からデタッチできます。

7. 加えた変更を再デプロイするには、ソリューション エクスプローラーでプロジェクト ノードを右クリックし、[発行] をもう一度選びます。

8. 発行プロファイル画面では、まだ元のデプロイ設定のすべてが設定されているため、もう一度 [発行] を選んで Azure に再デプロイします。

9. デプロイが完了すると、Visual Studio でブラウザーが起動され、アプリがもう一度表示されます。 検索フォームにもう一度「dotnet」と入力し、Enter キーを押します。 今度はリポジトリの一覧が正しく読み込まれます。

   おめでとうございます。 Visual Studio を使用して、Azure アプリ サービスのバグを正しく解決できました。