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

完了

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

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

デバッグ設定を構成する

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

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

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

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

    Visual Studio のデバッグ設定のスクリーンショット。

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

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

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

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

  4. 前の手順で作成した GitHubBrowser123 App Service を見つけて選択し、[ OK] を選択します

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

    プロセス機能へのアタッチのスクリーンショット。

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

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

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

    シンボル ファイル ウィンドウのスクリーンショット。

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

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

  1. Visual Studio でブレークポイントを設定したら、ブラウザーでアプリに切り替え、アプリ検索ボックスに dotnet の値を入力して、[ 送信] をクリックします。 Visual Studio で OnPost メソッド内のブレークポイントにヒットします。 初めての同期には少し時間がかかる場合があります。このコードは、GitHubUrl サービスを使用して IConfiguration 値の取得を試みます。 既定では、構成サービスによってアプリの 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. GitHubUrl からキーと値のペア appsettings.Development.json をコピーし、2 つのファイルが一致するように最上位の appsettings.json ファイルに貼り付けます。 アプリが Azure に再びデプロイされると、それと一緒に appsettings.json ファイル内の新しい構成値が伝達されます。

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

    アプリケーション設定のスクリーンショット。

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

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

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

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

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