Blazor WebAssembly アプリをブラウザの開発者ツールでデバッグする方法のおさらい (そして Logpoint は使えなかった件)

## ブラウザの開発者ツールで C# ソースコードをデバッグ

Blazor WebAssembly アプリは、実は、Web ブラウザの開発者ツールでデバッグ、すなわち、**.cs や .razor といったソースコード上**に**ブレークポイントを設置**してそこで実行を一時停止させたり、そこから**ステップ実行**したり、**変数の値を確認**したりすることができます。**ブラウザの開発者ツールのデバッガで、C# コードをデバッグする様子**はちょっとシュールかもしれませんね。

なお、Blazor WebAssembly アプリのブラウザでのデバッグは、今日現在、Safari ではできないようです。また、Mozilla Firefox は対応しているとのことですが、Microsoft Edge や Google Chrome、Chromium と開始手順が違うようで自分はまだ試せていません。

ということで、上記 Chromium 系のブラウザを対象に、実際にやってみましょう。

## 実際にやってみる

### なにはともあれ、デバッグ対象の Blazor WebAssembly アプリを起動

まずはデバッグ対象の Blazor WebAssembly アプリケーションプロジェクトがあるフォルダで、`dotnet run` コマンドを実行し、デバッグビルドされた状態で開発時サーバーを起動します。

```shell:ターミナルで実行した様子
$ dotnet run
Using launch settings from /home/jsakamoto/projects/MyBlazorApp/Properties/launchSettings.json...
Building...
info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5086
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /home/jsakamoto/projects/MyBlazorApp
```

### リモートデバッグを有効にしたブラウザを起動して開く

開発サーバーが待ち受けを開始したら、別のターミナルにて以下の要領で、各種オプションと待ち受けしている開発サーバーの URL を指定して、ブラウザを起動します。

> <ブラウザの実行コマンド> --remote-debugging-port=9222 --user-data-dir=<ユーザデータの保存先フォルダパス> <対象 Blazor WebAssembly アプリの URL>

例えば Ubuntu 上で Microsoft Edge を使って `http://localhost:5086/` を開く場合は以下のようになります。

```shell:Ubuntu上でEdgeで開く
microsoft-edge --remote-debugging-port=9222 --user-data-dir=/tmp/blazor-debug http://localhost:5086/
```

Windows 上で Google Chrome を使う場合は、[ファイル名を指定して実行] から以下を指定します。

```:Windowsのファイル名を指定して実行からChromeで開く
chrome --remote-debugging-port=9222 --user-data-dir="%temp%\blazor-debug" http://localhost:5086/
```

Ubuntu 上で Snap でインストールした Chromium を使う場合は以下になります。

```shell:Ubuntu上でChromiumで開く
/snap/chromium/current/usr/lib/chromium-browser/chrome --remote-debugging-port=9222 2 --user-data-dir=/tmp/blazor-debug http://localhost:5086/
```

ユーザーデータフォルダを指定するため、初回起動時は各ブラウザのウェルカム画面が表示されるかもしれませんが、それをスキップして進めると、対象の Blazor WebAssembly アプリのページが表示されるはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/888c9b02-9761-7e80-a6b8-c8f6b61aef5a.png)

### `Alt` + `Shift` + `D` を押す

ここで、キーボードから `Alt` + `Shift` + `D` のキーコンビネーションを押すと...

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/972b62eb-e60d-dad4-1264-47d0b13dff65.png)

もうひとつ新しいタブが開き、そこに開発者ツールが表示されます。

### ウィンドウレイアウトを調整

ここからはお好みで、となりますが、自分は以下のように開発者ツールの表示とウィンドウレイアウトを変更します。

まず、開発者ツールの [スクリーンキャスト] トグルボタンをクリックしてこれを Off にします。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/d5699bef-9562-773a-e577-97910c5b22e3.png)

その上で、開発者ツールのタブをウィンドウに切り離して、対象の Blazor WebAssembly アプリのウィンドウと、開発者ツールのウィンドウとを左右に並べています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/8f80b307-a674-e0ed-4b99-9fe239f28679.png)

### ソースコードを開き、普通のブレークポイントを設置する

さて、デバッグの手始めとしてブレークポイントの設置方法ですが、開発者ツールウィンドウにて、ソースタブ中、左側のツリー表示のところに、「files://」のノードがありますので、ここを開くと、.razor や .cs といった Blazor を構成するソースコードを開発者ツール内で開くことができます。目的のファイルを開いたら、ブレークポイントを指定したい対象行の行頭をマウスでクリックすると、ブレークポイントが設置され、行頭にその旨の印が表示されます (Microsoft Edge だと、赤い丸いマーカーが表示されます)。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/899b2a80-a302-819e-0857-979e8995b0b7.png)

### ブレークポイントでの停止と、変数の値を確認

この状態で、Blazor WebAssembly アプリの画面を操作して、ブレークポイントを設置した行が実行されるようにすると、ちゃんとそこで実行が一時停止します。停止した状態で、変数の上にマウスカーソルを当てると、それら変数の値・内容がツールチップ表示されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/c22a9b39-8759-d54d-7a23-3160b43883cc.png)

### ステップイン、コールスタック、変数ウォッチ

さらに、ステップインすることで、呼び出し先メソッドの中に実行を進めることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/e6daed2c-b1d0-6587-7ed7-00281c8c5a88.png)

ステップインした先を見ると、コールスタックに呼び出し履歴が表示されているのがわかります。また、先ほどは変数の値・内容を、マウスカーソルをホバーさせることでツールチップ表示していましたが、変数ウォッチ欄にもあわせて表示されていることが確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/29b100dd-964f-532b-014f-1e21b256e41c.png)

ステップ実行し、変数の値が変更されていることが確認できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/d42641a3-6e6f-d5c6-d4c3-715524a75835.png)

### 条件付きブレークポイント

条件付きブレークポイントも設置できます。設置したい対象行の行頭をマウスで右クリックし、メニューから「Add conditional breakpoint...」を選択します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/083d1f28-9916-07e3-f27c-64c9a8b06ddb.png)

条件を指定するポップアップが開くので条件を入力して Enter を押して確定させます。Microsoft Edge の場合、行頭には「=」マークが表示されて、この行に条件付きブレークポイントが設置されていることを示します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/ec025c73-3d06-1b51-f7d2-ee9798c40959.png)

この状態で、Blazor WebAssemnbly アプリケーション画面を操作していくと、先ほど指定した条件に合致したところで、プログラムの実行が一時停止します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/e06dd4c5-14cc-43b4-b27a-a1fa590f5877.png)

## うまくいかなかったこと

### ログポイントは使えなかった

さて、同じ要領でログポイント (Logpoint) の設置、つまり、設置した対象行を処理が通過したら、コンソールにメッセージや変数の値を表示する機能ですが、これを行なってみたところ、

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/d58c27eb-120e-07aa-fcfb-76cae58ec30a.png)

設置行を処理が通過したときに、下記のエラーになってしまい、ログポイントは機能しませんでした。

```
Unable to evaluate breakpoint condition '/** DEVTOOLS_LOGPOINT */ console.log('test')

//# sourceURL=debugger://logpoint': 
[ReferenceError] Failed to resolve root object for console.log('test')
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58450/fefeaf0b-d89e-7848-c71e-43f20e921f28.png)

「ルートオブジェクトの解決に失敗」とのことなのですが、自分にはさっぱりわからず、ログポイントは現在、利用できずにいます。

### ソースコードのパスに空白が含まれているとうまく動作しない

プロジェクトフォルダ名に空白を含むなど、ソースコードのパスに空白が含まれている場合、ブレークポイントを設置しても、そこで停止してくれませんでした。


## おわりに

以上、ブラウザの開発者ツールで、Blazor WebAssembly アプリをソースコードデバッグしてみた体験記になります。ログポイントが使えなかったのはちょっと惜しいですね。もちろん、Windows 上で Visual Studio を使ってデバッグする場合は、Visual Studio が備える豊富で強力なデバッガが利用できるので、そちらを使ったほうがいいでしょう。他の OS プラットフォームの場合は、自分はよくは知らないのですが、JetBrains の Rider を使えば同じようなリッチなデバッガ体験が得られるのかもしれません。また、一時的にでも、デバッグ対象のコンポーネントをBlazor Server アプリに載せて実行できれば、Visual Studio Code の C# 拡張によって、ログポイントも含めたデバッガ機能を利用できるはずです。

そのようなことから、実際上はブラウザの開発者ツールで Blazor WebAssembly アプリをデバッグする機会はないかもしれません。でも、初めて見たときは、ブラウザのデバッガで C# コードをデバッグする様子はなかなか衝撃的で興味深かったです。