Visual Studio 17.14.9 と .NET 9 へアップグレード後、.NET MAUI の Windows デバッグで「デバッグ前に Deploy が必要です」と出るのに、Configuration Manager の Deploy チェックが灰色で押せない——。この矛盾にハマる開発者は少なくありません。本記事では原因から仕組み、再現しやすい落とし穴、実運用での回避策までを、プロジェクト設定とファイルの中身レベルで丁寧に解説します。
.NET MAUI で Deploy が無効化されデバッグできない症状
以下の条件で発生報告が多い現象です。
- Visual Studio を 17.14.9 に更新した。
- .NET MAUI プロジェクトを .NET 7 / .NET 8 から .NET 9 に更新した。
- Windows ターゲットでデバッグ実行すると「デバッグ前に Deploy が必要です。Configuration Manager で Deploy を有効にしてください」と表示される。
- しかし Configuration Manager の Deploy 列が灰色（不可）でチェックを付けられない。
- 場合によっては 「open.exe が見つからない」という起動エラーになる。
結論（最短の対処方針）
この現象は不具合というより、.NET 9 時代の Windows 向け MAUI で 「unpackaged（非パッケージ）」実行が既定になっていることが本質的な原因です。unpackaged ではアプリを OS に「インストール」しないため、MSIX の Deploy 工程そのものが不要で、Deploy チェックは意図的に無効化されます。したがって、MSIX でデバッグしたい場合のみプロパティで「Create packaged app（パッケージを作成）」を有効化し、以降の Deploy を許可します。矛盾メッセージが残る場合は、ビルドキャッシュや設定ファイル（csproj / launchSettings.json）の整合性を取れば解消します。
背景知識：unpackaged と packaged（MSIX）の違い
Windows 向け .NET MAUI には次の 2 モードがあります。
| モード | 概要 | Deploy 列 | 用途 | メリット / デメリット |
|---|---|---|---|---|
| unpackaged（非パッケージ） | ビルド成果物を直接起動。OS へのインストールはしない。 | 無効（灰色） | 開発中の高速反復、簡易なローカル実行 | インストール不要で速い / パッケージ固有の API 挙動の検証には不向き |
| packaged（MSIX） | MSIX を作成して OS に展開（Deploy）してから起動。 | 有効（チェック可） | 配布やストア公開、パッケージ API の検証 | Deploy が入るぶん反復が遅い / 証明書や署名の準備が必要 |
.NET 9 + Visual Studio 17.14.9 で新規作成した MAUI プロジェクトは、Windows ではこの unpackaged が既定になっています。既定モードに合わせて UI 上の Deploy チェックが無効となるため、「必要です」と言われても押せない、という食い違いが生じます。
正しくデバッグするための手順（要点）
- Windows を unpackaged でデバッグするだけなら設定変更は不要です。そのまま ▶（デバッグ実行） で起動します。
- MSIX でデバッグしたい場合のみ、プロジェクトの プロパティ → Application → Windows Targets で 「Create packaged app」 をオンにします。これにより Configuration Manager に Deploy チェックボックスが現れ、チェック可能になります。
- 警告ダイアログやビルド矛盾が残る場合は、以下の「矛盾メッセージ対処」「open.exe 対処」を順に実施します。
矛盾メッセージ「Deploy を有効にしてください」の対処
unpackaged 既定のプロジェクトでも、環境や移行の過程で VS が古い情報を握ったままになると、メッセージが出続けることがあります。次の順で整合性を回復します。
- クリーン & リビルド
- ソリューションを右クリック → クリーン → その後 リビルド。
- bin/obj の削除
- 各プロジェクトの
bin/objフォルダーを手動で削除し、再ビルド。
- 各プロジェクトの
.csprojを確認- 下記のように明示しておくとブレが減ります。
<PropertyGroup> <DeployOnBuild>False</DeployOnBuild> <IsPublishable>True</IsPublishable> </PropertyGroup>- 古い移行痕跡の
<WindowsPackageType>が残っていたら 削除します（Visual Studio の UI に任せるのが安全）。
「open.exe が見つからない」起動エラーへの対処
MAUI の Windows 実行では launchSettings.json の commandName により実行方法が切り替わります。移行後にプロファイルが混在すると、unpackaged で起動すべきところを MsixPackage 側へ向けてしまい、open.exe が参照されるなどの不整合が起きがちです。次の要領で揃えます。
Properties\launchSettings.jsonを開く- すべてのプロファイルで
"commandName": "Project"に統一します。
{
"profiles": {
"Windows (Unpackaged)": {
"commandName": "Project"
},
"Windows (Package: legacy)": {
"commandName": "Project" // 以前 MsixPackage なら Project に変更
}
}
}
変更後、PC を再起動してから Visual Studio を立ち上げ直すと安定します。なお、MSIX で起動したいときは上記の通りプロパティ側で「Create packaged app」をオンにし、対応するプロファイルを必要に応じて用意してください。
MSIX でデバッグしたいときの正しい手順
- ソリューション エクスプローラーで MAUI プロジェクトを右クリック → プロパティ。
- Application → Windows Targets → Create packaged app をオン。
- Configuration Manager を開くと、Windows ターゲットの Deploy 列がチェック可能になります。
- 証明書設定やインストール許可など、MSIX に必要な前提が満たされているか確認してください。
これで「Deploy が有効にできない」問題は解消し、MSIX 経由での起動・デバッグが行えます。
ダウングレードは基本不要
Visual Studio 17.14.9 は .NET 9 を前提に使えます。ダウングレードせず、現行の .NET 9 + MAUI ワークロードを正しく整えるのが推奨です。過去 SDK が残っていなくても問題ありません（複数 SDK の共存は可能ですが、トラブル切り分けの観点では 1 バージョンに寄せるほうが無難です）。
環境別の挙動早見表
| Visual Studio / .NET | Windows ターゲット | 既定の実行モード | Deploy チェック | 推奨デバッグ方法 |
|---|---|---|---|---|
| 17.14.9 / .NET 9 | Windows | unpackaged | 無効（灰色） | そのまま実行（Project プロファイル） |
| 17.14.9 / .NET 9 | Windows（MSIX） | packaged（明示） | 有効（Create packaged app で可） | Deploy 有効化 → デバッグ |
| 17.14.9 / .NET 9 | Android / iOS | 端末/エミュレータ | 対象外 | 従来通り（Deploy 相当はツール側） |
移行時に起こりがちな不整合と対策
- 古い csproj の痕跡：
<WindowsPackageType>、<WindowsAppSDKSelfContained>などが残ると VS の UI とズレます。まず UI で切り替え、手書きプロパティは最小限に。 - プロファイルの混在：
MsixPackageとProjectが混ざると起動先が揺れます。開発中はProjectに統一。 - ビルドキャッシュ：
bin/objのクリーニングで解決するケース多数。 - VS キャッシュ：まれに VS 側キャッシュが悪さをします。
%LOCALAPPDATA%\Microsoft\VisualStudio\**\ComponentModelCacheの削除が有効。 - ワークロードずれ：.NET 9 時代の MAUI ワークロードに揃えるため、後述のコマンドで更新。
確実に直すための完全手順（保存版）
- ソリューションを閉じる（VS も一度終了）。
- ワークロードを更新（管理者コンソール）：
dotnet workload update dotnet workload restore - キャッシュを整理：
- 各プロジェクトの
bin/objを削除。 - 必要なら VS の
ComponentModelCacheも削除。
- 各プロジェクトの
- プロジェクト設定を見直す：
- プロパティ → Application → Windows Targets
- unpackaged で良ければ「Create packaged app」は オフ。MSIX で検証したいときは オン。
.csprojの最小化：<PropertyGroup> <TargetFrameworks>net9.0-windows10.0.19041.0;net9.0-android;net9.0-ios</TargetFrameworks> <UseMaui>true</UseMaui> <DeployOnBuild>False</DeployOnBuild> <IsPublishable>True</IsPublishable> </PropertyGroup>不要な<WindowsPackageType>を書いている場合は削除（UI が書き込む値に任せる）。launchSettings.jsonを統一："commandName": "Project"複数プロファイルがある場合もすべてProjectに揃える。- ソリューションを開き直し → クリーン → リビルド → デバッグ実行。
「新規テンプレート作成 → 既存コード移植」が効く理由
移行歴が長いプロジェクトほど、知らぬ間に積み上がったプロパティや設定ファイルの差が大きくなりがちです。とくに Windows ターゲットは WinUI/Windows App SDK の進化に追随しており、テンプレートの既定値が一番「いまの正解」を反映しています。新規に .NET 9 の MAUI テンプレートでプロジェクト（またはソリューション）を作り、以下の観点で移植すると、奇妙なビルド・起動エラーが一掃されます。
- NuGet パッケージのバージョンは移植先に合わせる（旧来の固定バージョンを持ち込まない）。
csprojの差分は「追加する必要がある要素だけ」を持ち込む。既定値は基本そのまま。- 画像/フォント/RawAssets は
Resources配下に整理し、ビルド アクションをテンプレートに合わせる。 - Windows 固有の
appxmanifest系やPackage.appxmanifestの直編集は避け、まずは UI から。
CI/CD（msbuild）での建付け
ローカルで問題が解消したら、パイプラインも unpackaged / packaged を明示しておくと安全です。
- unpackaged のビルド（デバッグ用）：
msbuild YourApp.csproj -t:Build -p:Configuration=Debug -p:TargetFramework=net9.0-windows10.0.19041.0この場合 Deploy は不要です。 - MSIX（packaged）のビルド：
msbuild YourApp.csproj -t:Publish -p:Configuration=Debug -p:TargetFramework=net9.0-windows10.0.19041.0証明書や署名のパラメータは環境に合わせて付与します。
チェックリスト（実行前の最終確認）
- ターゲットは Windows になっているか（Android/iOS のままではないか）。
- 開発中は unpackaged が既定。MSIX が必要なときだけプロパティで有効化。
launchSettings.jsonは全プロファイル"commandName": "Project"に統一。DeployOnBuild=False、IsPublishable=Trueをcsprojで明示（任意）。<WindowsPackageType>の手書きはしない（残っていれば削除）。bin/objを削除してからクリーン＆リビルド。- MAUI ワークロードは
dotnet workload update/restore済み。 - VS 修復や更新後は設定の巻き戻りを再確認。
- 再発時は VS の
ComponentModelCacheを削除。
よくある質問（FAQ）
Q. Deploy が無効なままでもデバッグできますか？
A. はい。unpackaged（既定）なら Deploy は不要で、ボタンが無効なのは仕様です。デバッグ実行（Project プロファイル）で問題ありません。
Q. 常に MSIX で検証したいのですが？
A. プロパティの「Create packaged app」をオンにし、Configuration Manager で Deploy を有効化してください。MSIX の署名や証明書要件を満たす必要があります。反復速度は落ちるため、通常の UI 変更やロジック検証は unpackaged、配布手順や API 検証のみ MSIX、という併用がおすすめです。
Q. Visual Studio や .NET をダウングレードすべき？
A. 不要です。17.14.9 + .NET 9 組み合わせで正常に開発できます。トラブルは設定不整合とキャッシュの影響が大半です。
Q. 「open.exe が見つからない」を根絶したい
A. launchSettings.json の commandName を すべて Project に統一する、これが最重要です。さらに PC 再起動 → クリーン＆リビルドで安定します。
Q. 移行で壊れたかもしれません。新規テンプレートで作り直す価値は？
A. 大いにあります。テンプレートは最新の既定値を持っているため、プロジェクト構造・プロパティ・NuGet の「正解」を丸ごと再入手できます。既存コードは安全に移植できます。
トラブル別の原因と対処一覧
| 症状 | 主な原因 | 対処 |
|---|---|---|
| Deploy が灰色 | unpackaged 既定（仕様） | そのまま実行。MSIX が必要なら「Create packaged app」をオン。 |
| Deploy を有効にしろと言われる | キャッシュ/設定不整合 | クリーン＆リビルド、bin/obj 削除、csproj 整理。 |
| open.exe が見つからない | MsixPackage プロファイルで起動 | launchSettings.json を Project に統一、再起動。 |
| ビルドは通るが起動しない | VS/Windows キャッシュ、証明書設定 | キャッシュ削除、証明書の見直し（MSIX のみ）。 |
| プロパティが勝手に戻る | VS 修復/更新の影響 | 修復後はプロジェクト設定を再確認、差分をリポジトリに保存。 |
設定が書き込まれるファイルの対応表
| ファイル | 何のためのファイルか | 今回の要点 |
|---|---|---|
.csproj | プロジェクトのビルド定義 | DeployOnBuild=False、IsPublishable=True。<WindowsPackageType> は書かない。 |
Properties\launchSettings.json | 実行プロファイル・起動方法 | "commandName": "Project" に統一。MSIX 起動は例外的に使用。 |
Resources 配下 | 画像/フォント/Raw アセット | テンプレート基準で整理。ビルドアクションの齟齬に注意。 |
| VS の ComponentModelCache | 拡張機能・コンポーネントのキャッシュ | 不整合時に削除すると復旧することがある。 |
「戻せば直る」を避け、前向きに直す
Deploy が無効＝壊れている、という直感から「.NET 8 に戻す」「Visual Studio を戻す」発想に陥りがちですが、今回の現象は unpackaged 既定化という仕様差が引き起こす認知ギャップに近いものです。モードを理解して正しく切り替える、設定ファイルを最小に保つ、キャッシュを整える。この三点を押さえれば、17.14.9 + .NET 9 でも快適に MAUI 開発を回せます。
補足：作業順に実施するスクリプト断片
// 1) ワークロード最新化
dotnet workload update
dotnet workload restore
// 2) 既存生成物の掃除（PowerShell の例）
Get-ChildItem -Recurse -Force -Directory -Include bin,obj | Remove-Item -Recurse -Force
// 3) ビルド
msbuild YourApp.csproj -t:Build -p:Configuration=Debug -p:TargetFramework=net9.0-windows10.0.19041.0 ケーススタディ：移行で詰まりやすいポイント
- 複数プロジェクト構成：スタートアップ プロジェクトの選択ミスで「Deploy が必要」ダイアログが出ることがあります。Windows を含む .NET MAUI プロジェクトがスタートアップになっているか再確認。
- Any CPU と x64 の混乱：Windows の MAUI は実質 x64 前提で扱うのが安定。Debug|x64 を選んだうえで挙動を確認してください。
- 証明書の期限切れ（MSIX 時）：「Deploy できない」根本原因が証明書だった例も。新しいテスト証明書に切り替えると解決します。
- 拡張機能の副作用：テンプレート以外の「ウィザード生成」による隠し設定が影響することがあります。純正テンプレート → コード移植で切り分けましょう。
まとめ
Visual Studio 17.14.9 + .NET 9 の .NET MAUI では、Windows デバッグの既定が unpackaged であり、Deploy チェックは不要かつ無効です。MSIX での検証が必要なときだけ Create packaged app をオンにして Deploy を使います。移行に伴う矛盾メッセージや open.exe エラーは、クリーン＆リビルド、bin/obj 削除、csproj 最小化、launchSettings.json の統一 で収束します。ダウングレードは不要。ワークロード更新とテンプレート準拠で、.NET 9 の開発体験を最大化しましょう。
付録：短時間で自己診断するためのフローチャート（文章版）
デバッグ実行ができない → 「Deploy を有効に」と出る？ → はい：unpackaged のはず → Configuration Manager で Deploy が灰色？ → はい：そのまま実行して動くか？ → 動く：仕様。動かない：bin/obj を削除→csproj を最小化→launchSettings.json を Project に統一→再起動 → それでもダメなら新規テンプレートへコード移植。
→ いいえ（Deploy にチェックできる）：MSIX モード。証明書や署名、プロファイルの整合を確認。
付録：運用のベストプラクティス
- 日常は unpackaged、節目で packaged：速度と正確さの両立。
- 設定は UI 優先、csproj は最小限：手書きのプロパティは差分のみに。
- キャッシュ運用：異変を感じたら
bin/objと VS キャッシュを掃除。 - テンプレートで基準を保つ：メジャー更新ごとに一度は新規テンプレートで構成確認。
補足コマンド（再掲）
dotnet workload update
dotnet workload restore
IDE の修復後は設定が巻き戻ることがあるため、修復後にプロジェクト設定を再確認してください。複数の Launch プロファイルを持つ場合は、すべての commandName を統一します。再発時は VS のキャッシュ削除（%LOCALAPPDATA%\Microsoft\VisualStudio\**\ComponentModelCache など）も有効です。
コメント