Visual Studio 2022 で、ブラウザーリンクの機能を使わない場合は不要となる Visual Studio とブラウザ間の通信を行わないようにする方法を書きます。2023 年 12 月 10 日現在の最新版 17.8.3 の話で、更新プログラムが適用されると話が変わるかもしれませんのでご注意ください。

Visual Studio 2022 では、上の画像の赤枠で示した「ブラウザーリンクを有効にする」にはデフォルトでチェックは入っていません。しかし、チェックを入れなくてもブラウザーリンクの機能による Visual Studio とブラウザー間の通信が行われます。ブラウザーリンクは使わないのにそのための通信が行われるのは避けたい場合、通信を行わないようにするにはどうすればいいかという話です。

ブラウザーリンクというのは何かですが、Visual Studio 2013 で新たに搭載された機能で、Edge, Chrome, Forefox など複数のブラウザを同時に立ち上げて表示させたり、Visual Studio 上でのコードの修正を複数のブラウザに同時に反映させたりする機能だそうです。詳しくは以下のMicrosoft のドキュメントを見てください。

• クロスブラウザのテストに Visual Studio 2013 のブラウザー リンクをどうぞ
• Visual Studio 2013でのブラウザー リンクの使用
• ASP.NET Core の Browser Link

「ブラウザーリンクを有効にする」にチェックが入ってない状態でも ASP.NET が生成する html ソースの body 要素の最後に以下のようなブラウザーリンクのためのコードが追加されます。（その下の script タグの aspnetcore-browser-refresh.js はホットリロード機能を実現するために使うものらしいです）

<!-- Visual Studio Browser Link -->
<script type="text/javascript" 
  src="/_vs/browserLink" 
  async="async" 
  id="__browserLink_initializationData" 
  data-requestId="14aa4d281859488cbb19bdfef314a877" 
  data-requestMappingFromServer="false" 
  data-connectUrl="http://localhost:57421/8a979671883c4acf85fb8bd2fd42853e/browserLink">
</script>
<!-- End Browser Link -->
<script src="/_framework/aspnetcore-browser-refresh.js">
</script>

Visual Studio からアプリを実行すると、上のスクリプトが動いて Visual Studio とブラウザが自動的に通信を行います。アプリを実行して Fiddler で要求・応答をキャプチャすると、その中には上のスクリプトによる通信が含まれます。下の画像を見てください。

画像の #13, #16, #18 が script 要素の data-connectUrl 属性に設定された localhost:57421 との通信です。#23 の localhost:44320 は、応答が HTTP 101 Switching Protocols となっており、応答ヘッダに Upgrade: websocket が含まれているところを見ると、やはりブラウザーリンクの関係のようです (ブラウザーリンクは通信に SignalR を使います)。

Visual Studio を使っての開発中であれば、ブラウザーリンクの機能を使う使わないに関わらず、デフォルトの設定のままにしておいて不都合はないかもしれません。しかし、使わないのに Visual Studio とブラウザー間のやり取りがあるのは煩わしいという場合があると思います。

その余計なやり取りをなくすにはどうしたらいいかですが、ググって調べてみると How to disable Browser Link in ASP.NET Core (.NET 6, VS 2022) という記事が見つかりました。Visual Studio の［ツール(T)］⇒［オプション（O)...］でオプション画面を開いてホットリロード関係の設定を変更する必要があるとのことです。

設定画面を開いてみると、デフォルトでは以下のように「CSS ホットリロード」が「有効」に設定されています。

これを無効に変更すると、ASP.NET が生成する html ソースにはブラウザーリンクのため script 要素は含まれなくなり localhost:57421 との通信は行われなくなくなります。上の Fiddler の画像の #48 以降のやり取りがその結果です。

ただし、ここまででは #51 に示されるように依然として localhost:44320 との通信が行われています。また、html にはホットリロード用の script タグは残ったままになります。

localhost:44320 との通信およびホットリロード用の script タグも無くしたい場合は、「自動ビルドと更新のオプション」も「なし」に設定し、

さらに、デバッグ > .NET/C++ ホットリロードの設定画面で以下の赤枠の 2 項目のチェックを外します。

詳しいことは分かりませんが、ブラウザーリンクとホットリロードとは関係があるようで、上のようなホットリロードの設定がブラウザーリンクに影響しているようです。

自分の環境の Visual Studio 2022 では下の画像のように SQL Server オブジェクトエクスプローラーが表示されていますが、その中の各項目が何かを調べたので備忘録として書いておきます。

まず、SQL Server オブジェクト エクスプローラーとは何かですが、CodeZin の記事 使わなきゃ損！ SQL Serverの新たな開発ツール「SQL Server Data Tools」によると SQL Server Data Tools (SSDT) の機能で、"開発者がSQL Server Management Studioで実施していたテーブルの作成や変更などのデータベース関連タスクを、Visual Studioで完結することを目的としています" というものだそうです。

Visual Studio 2022 に SSDT をインストールするには、Microsoft のドキュメント SQL Server Data Tools (SSDT) for Visual Studio のダウンロードに書いてあるように、ワークロードの「データの保存と処理」を追加し、そのオプションの「SQL Server Data Tools」にチェックを入れます。

そして、Visual Studio 2022 のメニューバーから［表示(V)］⇒［SQL Server オブジェクト エクスプローラー(S)］をクリックすれば SQL Server オブジェクトエクスプローラーが表示されます。

前置きが長くなりましたが、上の SQL Server オブジェクトエクスプローラーの画像に表示されている各項目が何かを説明します。

(1) (local)\sqlexpress (SQL Server 11.0.2100 ...)

ローカルにインストールした SQL Server 2012 Express の名前付きインスタンスです。

SQL Server の Express 版をインストールすると、デフォルトでは「名前つきインスタンス」となり、インスタンス名は SQLEXPRESS になります。

（記憶にないですが、たぶん、自分で SQL Server オブジェクト エクスプローラーを操作して追加したものだと思います）

(2) (localdb)\MSSQLLocalDB (SQL Server 13.0.4001 ...)

SQL Server 2016 LocalDB の自動インスタンスです。13.0.4001 から SQL Server 2016 ベースであることが分かります。

他に名前付きインスタンスというのもあります。詳しくは Microsoft のドキュメント SQL Server Express LocalDB を見てください。

自動インスタンスとは SQL Server の既定のインスタンスに該当するもののようで、開発時にはそれに接続して使うようにします。

Microsoft のドキュメントに書いてある通り、自動インスタンスの名前は MSSQLLocalDB になります。（SQL Server 2014 で変更されたそうです。その前は、文字 v の後に LocalDB とバージョン番号を付けたものでした）

Visual Studio 2019 では SQL Server 2016 LocalDB が、Visual Studio 2022 では SQL Server 2019 LocalDB が一緒にインストールされます。

自分の PC には Visual Studio 2019 / 2022 両方をインストールしており、一緒にインストールされた LocalDB は以下のようになっています。（一番上の SQL Server 2014 Express LocalDB は Visual Studio 2015 と一緒にインストールされたもの）　

それなのに、なぜ Visual Studio 2022 の SQL Server オブジェクトエクスプローラーに表示されている自動インスタンスが SQL Server 2019 LocalDB のものではないのでしょう？　それはたぶん以下のような話ではないかと思います。

上に紹介した Microsoft のドキュメントに以下のように書いてあります。

"ユーザーのコンピューターにインストールされているどのバージョンの LocalDB についても、LocalDB の自動インスタンスが 1 つ存在します"（PC 内に複数の自動インスタンスは存在しないということ）

"あるコンピューター上でユーザーが初めて LocalDB への接続を試みるときは、自動インスタンスを作成し、なおかつ開始する必要があります"

ということで、先に Visual Studio 2019 で作業したとき SQL Server 2016 LocalDB で自動インスタンスが作成され、Visual Studio 2022 でも先に作成された自動インスタンスがそのまま使われているということだと思います。

その自動インスタンスを、コマンド ライン管理ツール: SqlLocalDB.exe を使って SQL Server 2019 LocalDB にアップグレードすることはできるようです。

ググって調べると、Upgrade Visual Studio 2019’s LocalDB to SQL 2019 とか Upgrading SQL Server LocalDb などの方法を書いた記事がヒットします。

その方法というのは、(a) 既存の自動インスタンスを削除、(b) 新たに SQL Server 2019 LocalDB の自動インスタンスを作成、(c) 既存のデーターベースを新たに作成した自動インスタンスにアタッチする・・・ということになるようです。

上の (c) にリスクがありそうです。SQL Server 2019 LocalDB の自動インスタンスが必須というわけではない現状では、アップグレードには手を出さない方が良さそうな感じです。

(3) (localdb)\ProjectModels (SQL Server 15.0.4153 ...)

これは自分で作った記憶がなくて、Visual Studio 2022 で SSDT 関係の操作をしたとき自動的に作られたもののようです。

Microsoft の Developer Community の記事 (localdb)\ProjectsV13 not setup when installing Visual Studio 2022 に説明がありました。

自分の環境では、Visual Studio 2019 で、一緒にインストールされた SQL Server 2016 LocalDB をベースに、(localdb)\ProjectsV13 という名前のインスタンスが作られて、それがそのまま残っている。その後 Visual Studio 2022 を使うようになって、一緒にインストールされた SQL Server 2019 LocalDB をベースに (localdb)\ProjectModels という名前のインスタンスが作られたということのようです。

Visual Studio にインストールした SSDT が使うもので、開発者がアプリで使うものではないようです。

(4) (localdb)\ProjectsV13 (SQL Server 13.0.4001 ...)

上にも書きましたが、Visual Studio 2019 で一緒にインストールされた SQL Server 2016 LocalDB をベースに (localdb)\ProjectsV13 という名前のインスタンスが作られたようです。

一体それは何かですが、Stsckoverflow の記事 Purpose of ProjectsV13 LocalDB instance に以下のように書いてありました。

"The primary reason is to avoid conflicts with any "production" databases on MSSQLLocalDB. SSDT creates a new database for every database project you open. If your project is called Adventureworks, this might conflict with an Adventureworks database created by web projects or that are used by local ASP.NET applications you are running / debugging. Since SSDT does this automatically, in the background, it was felt that there was too high a risk of conflict. Hence, a separate instance is used."

上の (3) の (localdb)\ProjectModels も同じだと思います。

Wi-Fi でネットワークに接続した Android スマホの HTTP 通信を、同じ LAN 内の PC にインストールした Fiddler Classic (Windows 専用の無償版) でキャプチャする方法を備忘録として書いておきます。

注: HTTP のみです。HTTPS は証明書の問題で警告が出ます。詳細は後述します。

上の画像がその結果で、自分の Android スマホの Chrome で自分の HP に接続し、要求・応答をキャプチャした結果を表示したものです。

Fiddler はプロキシとして HTTP 通信をキャプチャするという仕組みになっています。なので、Android スマホの HTTP 通信がプロキシ (Fiddler) を通るように設定すれば、上の画像のように要求・応答が表示されるはずです。

その設定方法を以下に書きます。この記事を書いた時点での Windows OS, Fiddler, スマートフォンのバージョン等は以下の通りです。

• Windows 10 Pro 64-bit 21H2
• Fiddler Classic v5.0.20211.51073
• スマートフォン Sony SO-04H, Android 8.0.0
• Chrome 103.0.5060.70

最初に書きましたが、Android は Wi-Fi で LAN に接続、Fiddler は同じ LAN 内の PC にインストールしたものを使うということと、HTTP のみで HTTPS はダメという制約がありますので注意してください。

(1) Fiddler の設定

Windows PC の Fiddler に Android スマートフォンが接続できるように設定します。

Fiddler を立ち上げてメニューバーの［Tools］⇒［Options...］をクリックし下の Options ダイアログを表示します。

Options ダイアログの［Connections］タブを開いて［Allow remote computers to connect］にチェックを入れます。

(2) Android スマートフォンの設定

注: この記事で使ったスマートフォンは 2016 年のもので、今の機種では設定方法は変わっているかもしれません。プロキシの設定はどの機種でもできるはずなので、検索などで調べれば機種固有の設定方法は分かると思います

まず［アプリ］⇒［設定］⇒［ネットワークとインターネット］⇒［Wi-Fi］とクリックしていって Wi-Fi 設定画面を表示し、接続に使っている項目 (この記事の例では Buffalo-G-E90) を長押しすると下の画像のメニューが現れるので［ネットワークを変更］をクリックします。

デフォルトでは［詳細オプション］のプロキシが［設定しない］になっているはずですが、これを［手動］にすると、下の画像のように利用するプロキシを設定できるようになります。

上の画像の［プロキシのホスト名］に Fiddler をインストールしてある PC の IP アドレスを、［プロキシポート］に 8888 を入力し、［保存」をクリックすれば Android 側の設定は完了です。

以上で HTTP 通信であればこの記事の一番上の画像のように Android のブラウザで任意のサイトにアクセスして要求・応答をキャプチャできます。

HTTPS 通信はサーバー証明書問題で警告が出ます。これは Fiddler の証明書 DO_NOT_TRUST_FiddlerRoot が Android にはインストールされてないからだと思われます。

先の記事「Firefox で Fiddler を使う方法」で書きましたが、Fiddler をインストールした PC には OS の「信頼されたルート証明機関」の中に Fiddler の証明書が含まれるようになります。

なので、Fiddler をインストールした PC では HTTPS 通信で証明書の問題は出ません。Fiddler の証明書が無い Android ではそうはいかないということのようです。

Android に Fiddler の証明書 DO_NOT_TRUST_FiddlerRoot がインストールできるのか、できたとして証明書の問題が解決され Fiddler でキャプチャできるようになるのかは調べてないので分かりません。今後の検討課題ということで・・・

【2022/7/4 追記】

上に書いた HTTPS 通信でサーバー証明書の問題で警告が出る件ですが、Telerik のサイトの記事 Configure Fiddler Classic for Android Devices に対応方法の説明がありました。

それによると "Ensure that you have installed and using BouncyCastle as a certificate generator" ということで、証明書は Bouncy Castle を使って生成したものを使わないとダメらしいです。

上のページからリンクが張ってある Understanding Fiddler Certificate Generators によると "On Windows, Fiddler includes the MakeCert and CertEnroll certificate generators by default" とのことで、Bouncy Castle を使うには別途ダウンロードしてインストールする必要があるそうです。（自分の Fiddler を調べてみたら CertEnroll となってました）

ダウンロードしてみようとそのページの Bouncy Castle Certificate Generator のリンク (http://www.fiddler2.com/r/?fiddlercertMaker) をクリックしたら「fiddlercertmaker.exe を安全にダウンロードすることはできません」と出て失敗します。

そのリンクの応答は 301 Moved Permanently となっています。応答ヘッダに指定されている Location の http://telerik-fiddler.s3.amazonaws.com/fiddler/addons/fiddlercertmaker.exe を直接ブラウザのアドレスバーに設定して要求をかけると fiddlercertmaker.exe というファイルがダウンロードできます。

fiddlercertmaker.exe が Fiddler を Update して Bouncy Castle 証明書を発行できるようにするインストーラーらしいです。

fiddlercertmaker.exe をインストールし、Fiddler Echo Service にアクセスし (Fiddler を起動してからブラウザのアドレスバーに http://<IP アドレス>:8888/ と入力して要求をかけると表示されます)、証明書をダウンロードして、Android にインストールすれば HTTPS 通信もキャプチャできるようになる・・・

・・・はずですが、まだ未検証です。今のところ Android + Fiddler で HTTPS 通信をキャプチャする必要がないので、余計なことをしてトラブるのもアレですので。（笑）

どうしても HTTPS 通信をキャプチャする必要が出てきたらやってみてその結果を追記します。