ASP.NET Core .NET 6→.NET 8移行後にVisual Studioでプロジェクトプロパティが開けない・ブラウザが自動起動しない不具合の完全解決ガイド

ASP.NET Core を .NET 6 から .NET 8 に上げた直後、Visual Studio 2022 で「プロジェクトのプロパティが開けない」「F5 で Kestrel は上がるがブラウザが自動で開かない」という相談が急増しています。この記事は、実際に再現したケースをベースに、最短で直す手順と、二度と詰まらないための設計・運用のコツを、コピペで使える設定例と切り分け表つきで解説します。

症状の整理と前提

Visual Studio 2022（例：17.14.7）に更新後、ASP.NET Core MVC プロジェクト（.NET 6 → .NET 8 に更新）を右クリックすると、エラーダイアログが出てプロパティページ（プロジェクトのプロパティ）が開かない。
F5 では Kestrel がコンソールで起動し、URL も割り当てられるが、既定ブラウザが自動起動しない（URL を手動コピーする必要がある）。
同一ソリューション内のクラスライブラリでは発生しない。

一目で分かる「原因候補 × 対処」早見表

現象	主な原因候補	即効の対処	恒久対策
プロパティページが開けない	拡張機能の競合／破損、VS キャッシュ破損	拡張機能を全無効 → セーフモード起動 → 問題再現を確認	犯人拡張を特定し無効化・更新、VS 修復、キャッシュクリア
F5 でブラウザが開かない	launchSettings.json の設定漏れ（`launchBrowser` / `applicationUrl`）、プロファイル選択ミス	プロファイルを `Kestrel`（または `IIS Express`）に合わせて修正	標準テンプレートに倣って JSON を整備、チーム規約化
ランダムに直ったり壊れたり	`.vs`、`bin`、`obj` の破損・取り違え	該当フォルダー削除 → クリーン	CI で完全ビルド、ローカルもクリーンスクリプト常備
新規 .NET 8 プロジェクトは正常	旧プロジェクトの `csproj` / `launchSettings.json` の差異	差分を精査して統一	テンプレート化・スキャフォールド導入
ソリューション全体で不安定	VS 本体の破損／SDK と VS の不整合	VS インストーラーで「修復」、SDK/VS の整合を確認	更新ウィンドウのメンテナンス運用

最短で直す実効手順（これだけやれば OK）

以下は「できるだけ少ない手数で確実に直す」ことを目的にした実行順です。上から順に進めれば、ほとんどの環境で原因が特定できます。

拡張機能を一括で無効化（実際の解決策）

Visual Studio を終了します。
通常起動し、拡張機能 > 拡張機能の管理 から Installed を開き、すべての拡張機能を「無効化」にします（再起動を求められたら再起動）。
問題が消えた場合、拡張機能が原因です。以降は 1 つずつ再有効化して再現タイミングで「犯人」を特定します。
特定した拡張機能はアンインストール、またはアップデートを確認し、開発元へ Report a Problem で報告します。

ポイント：拡張機能はプロジェクトシステム（Property Pages）やデバッグエンジンにフックするため、壊れると「プロパティが開けない」「ブラウザが起動しない」などの症状に直結します。まずはサードパーティ要因を排除しましょう。

セーフモードでの切り分け

拡張機能の影響を一発で除去して確認したい場合はセーフモードが便利です。

devenv /SafeMode

これで症状が消えるなら、「VS 本体 <= OK / 拡張機能 <= NG」という判定ができます。セーフモードで 新規の .NET 8 プロジェクト を作って挙動を見ると切り分け精度が上がります。

launchSettings.json を点検（ブラウザ自動起動）

ブラウザが自動起動しない場合、デバッグプロファイルの設定が崩れている可能性が高いです。Properties/launchSettings.json を開き、以下を確認します。

profiles に Kestrel（または IIS Express）が存在する
commandName が Project または IISExpress
launchBrowser が true
applicationUrl が http/https の 2 本立て

そのまま使えるサンプル（.NET 8 / Kestrel）

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true
  },
  "profiles": {
    "Kestrel": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://localhost:7243;http://localhost:5243",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true
    }
  }
}

プロファイル名は Visual Studio のデバッグターゲット（緑の再生ボタン横）と一致させます。applicationUrl が欠落すると、Kestrel は起動してもブラウザを開けません。

プロジェクトのプロパティが開けないときのワークアラウンド

プロパティページを使わず、launchSettings.json を直接編集してデバッグ構成を整える。
デバッグターゲットのドロップダウンで、明示的に「Kestrel」「IIS Express」を切り替え、起動プロファイルを確認。
セーフモード（または拡張機能全無効）で一時的にプロパティページが開けるか検証。

キャッシュ／中間生成物のクリーン

破損したキャッシュが原因のこともあります。以下を削除してからビルドし直します。

ソリューション直下の .vs フォルダー
各プロジェクト配下の bin、obj

Windows（PowerShell）

Get-ChildItem -Path . -Include bin,obj -Recurse -Directory | Remove-Item -Recurse -Force
Remove-Item -Recurse -Force .\.vs

macOS/Linux（bash）

find . -type d -name bin -o -name obj | xargs rm -rf
rm -rf .vs

Visual Studio の修復

拡張機能が無関係でも直らない場合は、VS インストーラーから「修復」を実行します。破損したコンポーネントやプロジェクトシステムの不整合が解消されるケースがあります。

.NET SDK と VS の整合性チェック

.NET 8 が正しく使われているか、CLI で確認します。

dotnet --info
dotnet --list-sdks

ソリューションの直下に global.json があり古い SDK を固定していると、プロジェクトが net8.0 でもビルド/実行が 6.x で行われ、VS の動作が不安定になることがあります。

{
  "sdk": {
    "version": "8.0.401",
    "rollForward": "latestMinor"
  }
}

固定が不要なら global.json を削除するか、上記のように 8.x へ更新します。

新規プロジェクトでの再現確認（切り分けの要）

既存と新規で差が出るかを確認すると、原因の層が一発で見えます。

空のディレクトリで実行： dotnet new mvc -f net8.0 -n Mvc80Clean cd Mvc80Clean dotnet dev-certs https --check --trust
Visual Studio で開き、F5。ブラウザが開けば VS/SDK は概ね正常。
ここで問題が出るなら VS 本体か、システム側の問題（プロファイルや証明書）を疑います。新規は正常・既存のみ異常なら、csproj と launchSettings.json、Properties 配下の差分を比較します。

launchSettings.json の深掘り：崩れやすいポイントを総点検

キー	例	意味	ありがちな落とし穴
`commandName`	`Project` / `IISExpress`	起動方法の指定	`Executable` のまま残っていて想定外の exe を起動してしまう
`launchBrowser`	`true`	F5 時にブラウザを開くか	`false` になっていても気づきにくい
`applicationUrl`	`https://localhost:7243;http://localhost:5243`	Kestrel のバインド URL	https のみ／http のみ、またはキー自体が欠落
`environmentVariables`	`"ASPNETCORE_ENVIRONMENT":"Development"`	環境変数	本番用の値が混入して動作が変わる
`dotnetRunMessages`	`true`	起動ログ（URL 等）の表示	`false` だと URL が分かりにくい

Program.cs の確認：URL 固定やブラウザ連携の補助

基本的に .NET 8 の最小ホスティングモデルで問題ありませんが、チームでポートを固定したい／複数サイトの衝突を避けたい場合は UseUrls を使っておくと事故が減ります。

var builder = WebApplication.CreateBuilder(args);

// 省略: services.AddControllersWithViews();

var app = builder.Build();

// 省略: ミドルウェア

// launchSettings.json の applicationUrl と合わせておくと混乱しない
app.Urls.Add("[http://localhost:5243](http://localhost:5243)");
app.Urls.Add("[https://localhost:7243](https://localhost:7243)");

app.Run();

なお、Visual Studio のブラウザ自動起動は launchBrowser とプロファイル選択に依存します。コード側でブラウザを開くロジックを書かないのがベストプラクティスです。

「プロパティページが開けない」根本原因の典型

拡張機能の競合：プロジェクトシステムやデバッグにフックする拡張が、.NET 8 テンプレートや VS の更新に追随できず例外を投げる。
キャッシュ破損：.vs フォルダーや一時設計時データの破損。
csproj の異常プロパティ：古い SDK ターゲットや不可視の Import を残したまま移行して例外化。

csproj の健全性チェック（最小構成の例）

&lt;Project Sdk="Microsoft.NET.Sdk.Web"&gt;
  &lt;PropertyGroup&gt;
    &lt;TargetFramework&gt;net8.0&lt;/TargetFramework&gt;
    &lt;Nullable&gt;enable&lt;/Nullable&gt;
    &lt;ImplicitUsings&gt;enable&lt;/ImplicitUsings&gt;
  &lt;/PropertyGroup&gt;
  &lt;ItemGroup&gt;
    &lt;PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation" Version="8.*" /&gt;
  &lt;/ItemGroup&gt;
&lt;/Project&gt;

不明な Import、古い Microsoft.NET.Sdk.Razor 個別参照、プロジェクト GUID のレガシー化等があれば削除／刷新を検討します。

開発用 HTTPS 証明書の確認

HTTPS での自動起動に失敗する場合、開発用証明書の未信頼・期限切れが引き金のこともあります。

dotnet dev-certs https --check
dotnet dev-certs https --trust

これで https://localhost:xxxx をブラウザが素直に開けるようになります。

デバッグが不安定なときの VS オプション確認

ツール > オプション > プロジェクトおよびソリューション > Web プロジェクト の設定を初期状態に。特に「IIS Express を使用する」「既定のブラウザーを開く」系。
デバッグターゲットのドロップダウン右の歯車アイコン（または「デバッグプロパティ」）から、プロファイルと URL を再確認。

切り分けマトリクス：どこが悪いかを 5 分で特定

観点	確認方法	Yes の場合	No の場合
新規 .NET 8 MVC は正常？	`dotnet new mvc -f net8.0` → F5	既存プロジェクトの差分（csproj/launchSettings.json）	VS or SDK 側（修復／再インストール）
セーフモードで正常？	`devenv /SafeMode` で起動	拡張機能が原因	VS 本体・キャッシュ・SDK 整合
ブラウザ手動で URL を開ける？	コンソール出力の URL をコピー	launchSettings の `launchBrowser` 周り	証明書、ファイアウォール、URL 予約
コンソールに URL が出る？	`dotnetRunMessages` を `true`	プロファイルは動いている	アプリ起動前の例外／Kestrel バインド失敗

ブラウザが起動しないときのチェックリスト（実務向け）

launchSettings.json の launchBrowser: true、applicationUrl（http/https）の 2 本があるか。
デバッグターゲットで正しいプロファイル（Kestrel / IIS Express）を選択しているか。
開発用 HTTPS 証明書が信頼済みか。
既定ブラウザの設定が OS/VS ともに健全か（既定ブラウザの再設定を試す）。
拡張機能の影響を除外（全無効／セーフモード）。
.vs、bin、obj を削除して再ビルド。
新規 .NET 8 MVC で再現するかを確認。

プロジェクトのプロパティが壊れるのを防ぐ運用 Tips

拡張機能は最小限＋定期棚卸し：新しい VS 更新に追随できない拡張は早めに撤去。チームで「推奨拡張リスト」を管理。
プロファイルをテンプレート化：チーム標準の launchSettings.json をレポジトリで共有し、差分検出を CI でチェック。
global.json を明示管理：SDK 固定が必要なときのみ pin。不要な pin は削除。
クリーンスクリプトを常備：トラブル時は即時に .vs/bin/obj を削除できるよう、スクリプトをルートに置く。
新規テンプレートでの健全性確認を習慣化：「新規で動く」をレファレンスにして、既存との差分を素早く洗う。

トラブルが重なったときの奥の手

設定のリセット

ユーザー設定の破損が疑わしいときに。

devenv /ResetSettings

プロファイルが初期化されるため、必要な設定は再適用してください。

VS の一時キャッシュ類のクリア

ユーザープロファイル配下の Visual Studio キャッシュが原因のときは、VS 終了後にキャッシュフォルダーをクリアします（削除は自己責任で、先にバックアップを）。

実ケースから学ぶ「落ちない移行」手順

ブランチを切る：upgrade/net8 などへ隔離。
TargetFramework を段階的に更新：テストを通しながら net8.0 に上げる。
launchSettings.json を再生成 or 差分反映：新規テンプレートから流用し、既存の差分を最小化。
nuget を最新安定版へ統一：メジャー移行で破壊的変更を踏み抜かないように。
新規 MVC テンプレートと動作比較：F5 の UX（ブラウザ自動起動含む）を統一。
拡張機能の棚卸し：移行前に不要な拡張を外しておく。

よくある Q&A

Q. プロパティが開けないのに `launchSettings.json` を直接直してよい？

A. 問題ありません。プロパティページは UI であり、実体は launchSettings.json です。UI が壊れている間は直接編集が最速・安全です。

Q. Kestrel と IIS Express、どちらを使うべき？

A. .NET 8 の標準テンプレートは Kestrel 前提です。IIS と連携した機能（Windows 認証など）が必要な場合のみ IIS Express を使います。チームで統一しましょう。

Q. ブラウザが Edge で開かない／意図しないブラウザが開く

A. OS の既定ブラウザ設定に依存します。OS 側で既定を明示し、VS のデバッグターゲット横のブラウザ選択で固定してください。

チェック用スニペット集（貼って動く）

launchSettings.json（最小・Kestrel）

{
  "profiles": {
    "Kestrel": {
      "commandName": "Project",
      "launchBrowser": true,
      "dotnetRunMessages": true,
      "applicationUrl": "https://localhost:7243;http://localhost:5243",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

Windows 用クリーンスクリプト（保存名: `clean.ps1`）

Get-ChildItem -Path . -Include bin,obj -Recurse -Directory | Remove-Item -Recurse -Force
if (Test-Path ".\.vs") { Remove-Item -Recurse -Force .\.vs }

SDK 側の健全性確認

dotnet --info
dotnet --list-sdks
dotnet workload list

まとめ：最短ルートは「拡張機能の全無効」＋「launchSettings.json の是正」

今回のように、.NET 6 → .NET 8 への移行直後に Visual Studio のプロパティページやブラウザ自動起動が壊れるケースは、実務では拡張機能の競合が原因であることが最も多く、次点で launchSettings.json の欠落・破損です。まずは拡張機能をすべて無効化して症状が消えるか確認し、消えるなら 1 つずつ戻して犯人を特定。並行して launchSettings.json をテンプレートどおりに整備すれば、F5 の UX はほぼ復旧します。最後に、.vs や bin/obj のクリーン、SDK/VS の整合と証明書の確認まで進めれば、同種の不具合は再発しにくくなります。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

ASP.NET Core .NET 6→.NET 8移行後にVisual Studioでプロジェクトプロパティが開けない・ブラウザが自動起動しない不具合の完全解決ガイド

症状の整理と前提

一目で分かる「原因候補 × 対処」早見表

最短で直す実効手順（これだけやれば OK）

拡張機能を一括で無効化（実際の解決策）

セーフモードでの切り分け

launchSettings.json を点検（ブラウザ自動起動）

そのまま使えるサンプル（.NET 8 / Kestrel）

プロジェクトのプロパティが開けないときのワークアラウンド

キャッシュ／中間生成物のクリーン

Windows（PowerShell）

macOS/Linux（bash）

Visual Studio の修復

.NET SDK と VS の整合性チェック

新規プロジェクトでの再現確認（切り分けの要）

launchSettings.json の深掘り：崩れやすいポイントを総点検

Program.cs の確認：URL 固定やブラウザ連携の補助

「プロパティページが開けない」根本原因の典型

csproj の健全性チェック（最小構成の例）

開発用 HTTPS 証明書の確認

デバッグが不安定なときの VS オプション確認

切り分けマトリクス：どこが悪いかを 5 分で特定

ブラウザが起動しないときのチェックリスト（実務向け）

プロジェクトのプロパティが壊れるのを防ぐ運用 Tips

トラブルが重なったときの奥の手

設定のリセット

VS の一時キャッシュ類のクリア

実ケースから学ぶ「落ちない移行」手順

よくある Q&A

Q. プロパティが開けないのに `launchSettings.json` を直接直してよい？

Q. Kestrel と IIS Express、どちらを使うべき？

Q. ブラウザが Edge で開かない／意図しないブラウザが開く

チェック用スニペット集（貼って動く）

launchSettings.json（最小・Kestrel）

Windows 用クリーンスクリプト（保存名: `clean.ps1`）

SDK 側の健全性確認

まとめ：最短ルートは「拡張機能の全無効」＋「launchSettings.json の是正」

この記事を書いた人

コメント

コメントするコメントをキャンセル

ASP.NET Core .NET 6→.NET 8移行後にVisual Studioでプロジェクトプロパティが開けない・ブラウザが自動起動しない不具合の完全解決ガイド

症状の整理と前提

一目で分かる「原因候補 × 対処」早見表

最短で直す実効手順（これだけやれば OK）

拡張機能を一括で無効化（実際の解決策）

セーフモードでの切り分け

launchSettings.json を点検（ブラウザ自動起動）

そのまま使えるサンプル（.NET 8 / Kestrel）

プロジェクトのプロパティが開けないときのワークアラウンド

キャッシュ／中間生成物のクリーン

Windows（PowerShell）

macOS/Linux（bash）

Visual Studio の修復

.NET SDK と VS の整合性チェック

新規プロジェクトでの再現確認（切り分けの要）

launchSettings.json の深掘り：崩れやすいポイントを総点検

Program.cs の確認：URL 固定やブラウザ連携の補助

「プロパティ ページが開けない」根本原因の典型

csproj の健全性チェック（最小構成の例）

開発用 HTTPS 証明書の確認

デバッグが不安定なときの VS オプション確認

切り分けマトリクス：どこが悪いかを 5 分で特定

ブラウザが起動しないときのチェックリスト（実務向け）

プロジェクトのプロパティが壊れるのを防ぐ運用 Tips

トラブルが重なったときの奥の手

設定のリセット

VS の一時キャッシュ類のクリア

実ケースから学ぶ「落ちない移行」手順

よくある Q&A

Q. プロパティが開けないのに launchSettings.json を直接直してよい？

Q. Kestrel と IIS Express、どちらを使うべき？

Q. ブラウザが Edge で開かない／意図しないブラウザが開く

チェック用スニペット集（貼って動く）

launchSettings.json（最小・Kestrel）

Windows 用クリーンスクリプト（保存名: clean.ps1）

SDK 側の健全性確認

まとめ：最短ルートは「拡張機能の全無効」＋「launchSettings.json の是正」

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

「プロパティページが開けない」根本原因の典型

Q. プロパティが開けないのに `launchSettings.json` を直接直してよい？

Windows 用クリーンスクリプト（保存名: `clean.ps1`）

コメントするコメントをキャンセル