Mac（Sonoma）で .NET 9 の .NET MAUI（net9.0-maccatalyst）を VS Code から Clean / Build / Run すると、ログ上の Platform が「Any CPU」になり起動できないことがあります。CLI では動くのに VS Code だけ失敗する場合の原因と、再インストールで直った実例の切り分け手順をまとめます。
症状の全体像：VS Code から実行すると「起動できない」
今回のテーマは、空の .NET MAUI（Mac Catalyst）プロジェクトにもかかわらず、VS Code から Clean / Build / Run を行うと起動できないという現象です。ポイントは「MAUI 自体の壊れ」よりも、VS Code から実行したときだけ MSBuild のプロパティや実行経路が変わり、結果として起動に失敗するところにあります。
- VS Code のコマンド（Clean / Build / Run）で実行すると、ビルドログに
Platform="Any CPU"のような表示が出る - 生成物の場所が想定とズレたり、実行ターゲットが解決できずにアプリが起動しない
- 一方で、同じマシン・同じ SDK で CLI（ターミナル）から実行すると空プロジェクトは正常に起動できる
この組み合わせが揃うと、プロジェクトや .NET SDK よりも、VS Code 本体・拡張機能・内部キャッシュ・インストールされている関連パッケージの不整合を疑うのが近道です。
検証環境の例
| 項目 | 内容（例） | 補足 |
|---|---|---|
| macOS | Sonoma 14.7.2 | OS の更新直後はツールチェーンの不整合が出やすい |
| Xcode | 16.2 | コマンドラインツール選択やライセンス同意も影響する |
| .NET / MAUI | .NET SDK 9.0.100、.NET MAUI（net9.0-maccatalyst） | ワークロードと VS Code 側の拡張機能の相性が出やすい |
「Platform=Any CPU」が引き金になりうる理由
.NET のプロジェクトは、MSBuild のプロパティ（Configuration / Platform / TargetFramework など）の組み合わせで、出力先（bin/obj）や実行ターゲットの解決が変わります。一般的に .NET の世界では AnyCPU（IDE 表示上の「Any CPU」）は珍しくありませんが、.NET MAUI のようにネイティブツールチェーン（Xcode）と連携するケースでは、次のような「噛み合わなさ」が起きると一気に症状が表面化します。
- ビルドは通るのに、Run が参照する出力パスがズレて起動に失敗する
- VS Code のタスクが
/p:Platform="Any CPU"を付与し、出力フォルダの構造が CLI 実行と変わる - 拡張機能側が「どこに .app ができるか」を別の規則で推測し、結果として見つけられない
つまり、Platform 表記そのものが悪者というより、VS Code の実行経路で Platform が固定されたり、表記ゆれ（スペース有無）で別扱いになったりすることで、出力物の探索や起動手順が噛み合わなくなるのが典型パターンです。
ズレが起きるポイント（イメージ）
| 観点 | CLI での実行 | VS Code での実行 | 困るポイント |
|---|---|---|---|
| 起動コマンド | dotnet build -t:Run など | タスク/デバッグ実行（内部で dotnet を呼ぶ） | 引数（MSBuild プロパティ）が変わりやすい |
| Platform の扱い | 指定しない（既定） | 自動付与される／設定ファイルで固定 | 出力パスや探索規則がズレる |
| PATH / SDK 解決 | 普段のシェル設定 | VS Code 起動時点の環境変数 | 別の dotnet を掴むと症状が変わる |
最短の切り分け：まず CLI で「空プロジェクトが動く」ことを確認する
この手の問題は、いきなり VS Code の設定をいじるより、CLI 側でツールチェーンが正しいことを先に証明した方が結果的に早く解決します。CLI で動くなら、MAUI ワークロードや Xcode 側の致命的な欠損ではなく、VS Code 由来の差分に焦点を当てられるからです。
確認コマンド（例）
以下は「情報を集める」ための最低限のコマンドです。出力の値そのものよりも、VS Code と CLI で一致しているかを見ます。
dotnet --info
dotnet workload list
xcode-select -p
| 確認項目 | 見るポイント | 次のアクション例 |
|---|---|---|
| .NET SDK | 9.0.100 を使っているか（複数入っている場合はどれを掴んでいるか） | global.json で SDK を固定して再現性を上げる |
| MAUI ワークロード | maui 関連が欠けていないか | 不足/破損が疑わしい場合は更新・修復（例：dotnet workload update / dotnet workload repair） |
| Xcode パス | 意図した Xcode を指しているか | 古い Xcode を指していたら切り替え（xcode-select） |
CLI でのビルド/実行例（Mac Catalyst）
空の MAUI プロジェクトで「Mac Catalyst 向けにビルドして起動する」ことが確認できれば、土台はOKです。コマンド例は次のようになります（プロジェクト構成により差があります）。
# 例：ビルド（ターゲットフレームワークを明示）
dotnet build -c Debug -f net9.0-maccatalyst
# 例：Run ターゲットで実行（環境により利用可否が変わります）
dotnet build -t:Run -c Debug -f net9.0-maccatalyst
ここで問題なく起動できるのに、VS Code からだと失敗する場合、VS Code が呼んでいる dotnet / MSBuild 引数 / 拡張機能の介在が主な調査対象になります。
VS Code 側で確認するポイント
VS Code は「エディタ」ですが、.NET のビルドやデバッグでは拡張機能とタスク機構が深く関与します。CLI で動くのに VS Code だけ失敗する場合、次の順で確認すると無駄が少ないです。
統合ターミナルと外部ターミナルで dotnet が一致しているか
VS Code の統合ターミナルは便利ですが、起動方法（Dock から起動したか、ターミナルから code で起動したか）によって環境変数が変わることがあります。まずは どの dotnet を使っているかを揃えます。
# VS Code 統合ターミナルと、通常のターミナルの両方で実行して比較
which dotnet
dotnet --info
ここで SDK のパスやバージョンが違っていたら、VS Code 側が別の dotnet を掴んでいる可能性が高いです。CLI で動く dotnet と同じものを VS Code が使うように整えるだけで直るケースもあります。
タスク（tasks.json）やデバッグ設定（launch.json）で Platform を固定していないか
VS Code の実行は、裏側で dotnet build を呼び、そこに独自の引数（MSBuild プロパティ）を足していることがあります。代表的なのが Platform の付与です。もし設定やログに次のような指定が見えたら、一度疑ってみてください。
/p:Platform="Any CPU"
対処としては、次のどれかが現実的です。
- Platform の指定をいったん外す（既定の挙動に戻してズレを減らす）
- 表記ゆれをなくす（例：
AnyCPUに統一するなど） - 出力先が変わる前提で、Run が探すパスの規則を合わせる（高度な調整）
ただし、今回の実例では「設定を直した」というより、VS Code 環境の再インストールで正常化しています。設定ファイルが原因というよりは、拡張機能や内部状態が壊れていた可能性が高いと考えるのが自然です。
公式の Getting Started に揃える
MAUI は Android / iOS / Windows / Mac と絡むため、VS Code のセットアップは「何となく動いた構成」だと崩れやすいです。独自のタスクやデバッグ設定を作っている場合は、まず公式の Getting Started / チュートリアルで案内されている拡張機能・デバッグ手順に寄せてください。
- 推奨される C# 関連拡張機能だけに絞る（まず最小構成）
- テンプレートで生成された launch 設定をベースにする
- 起動・ビルドに関わる独自の引数（Platform など）を足すのは、動作確認後にする
拡張機能の組み合わせ・バージョン不整合を疑う
.NET の開発体験は拡張機能に依存します。特に C# 関連の拡張機能が複数入っている場合、更新のタイミングによって内部コンポーネントがズレ、結果としてタスクやデバッグ起動が崩れることがあります。
| 観点 | チェック内容 | おすすめ対応 |
|---|---|---|
| 更新状況 | VS Code 本体と拡張機能が古い/中途半端に更新されていないか | まずはアップデートを揃える |
| 重複 | 似た役割の拡張機能が複数入り、競合していないか | 一度最小構成にして再現を確認 |
| キャッシュ | 拡張機能のキャッシュ破損（更新後に起きがち） | 無効化→再起動→有効化、または再インストール |
「VS Code 側の不整合」が濃厚になるサイン
原因切り分けは、闇雲に試すよりも「この条件なら VS Code 側が怪しい」と判断できる材料を集めると早いです。次のサインが複数当てはまるなら、VS Code の更新・再インストールを優先してよいでしょう。
- 同一プロジェクトが CLI では Run できる（新規の空プロジェクトでもOK）
- VS Code の実行だけが失敗し、統合ターミナルで同じコマンドを手打ちすると成功する
- 最近 VS Code や拡張機能を更新した、あるいは macOS / Xcode / .NET SDK を更新した直後から起きている
- ビルドログの
Platformや出力先が、CLI と VS Code で明らかに違う
解決策：VS Code を再インストールして正常化する
結論として、このケースは VS Code 側の環境（本体・拡張機能・関連パッケージ）の不整合/破損が原因で、VS Code を再インストール（入れ直し）したら解消しています。再インストールにより内部コンポーネントや拡張機能の状態が整理され、結果として Mac Catalyst のビルド/実行経路が正しく戻ったという流れです。
実例としては、「VS Code を入れ直しで解決。チケットはクローズできる状態」という着地になりました。
再インストール前にやっておくと安心なこと
- 設定同期（Settings Sync）を使っている場合は、同期が有効か確認しておく
- 必要なら 拡張機能の一覧や、.vscode フォルダの設定を控えておく
- 空プロジェクトで再現する状態を作っておく（再インストール後の検証が早い）
再インストール手順（macOS の例）
「アプリを入れ直すだけ」で直ることも多いですが、拡張機能の状態が絡む場合は、必要に応じてキャッシュも整理します。キャッシュ削除は設定が初期化されるので、心配な場合は「アプリ再インストールだけ」を先に試してください。
- VS Code を完全に終了する（ウィンドウを閉じるだけでなく終了）
- VS Code アプリをアンインストール（アプリケーションから削除）
- 必要に応じて、関連フォルダ（設定/キャッシュ）を整理する
- VS Code を再インストールする
- 推奨される拡張機能だけを入れて、空の MAUI プロジェクトで Clean / Build / Run を再検証する
関連フォルダ（例）
| 場所（例） | 役割 | 削除するとどうなるか |
|---|---|---|
~/.vscode | 拡張機能やユーザーデータ | 拡張機能が入れ直しになる |
~/Library/Application Support/Code | 設定・キャッシュ・状態情報 | 設定が初期化される可能性 |
~/Library/Caches/com.microsoft.VSCode | キャッシュ | 再起動後に再生成される |
Homebrew を使っている場合は、再インストールをコマンドで済ませる方法もあります。
brew install --cask visual-studio-code
再発防止：CLI と VS Code の「差分」を最小化する
今回のように「CLI はOK、VS Code はNG」という症状は、差分が積み重なった結果として起きやすいです。再発を減らすには、次の方針が効きます。
- SDK を固定する（プロジェクト直下に
global.jsonを置き、チームでも再現性を上げる） - VS Code 本体と拡張機能をセットで更新する（片方だけ古い状態を避ける）
- 「動いた構成」をメモしておき、問題が出たら 最小構成へ戻す
- MAUI / Xcode を更新した後は、空プロジェクトでビルド/実行テストをしてから本番プロジェクトに触る
| 再発しやすい要因 | よくある現象 | 予防策 |
|---|---|---|
| SDK/Workload 更新 | VS Code からの Run だけ失敗 | 更新後に dotnet --info と空プロジェクトで確認 |
| 拡張機能の更新 | 突然 Platform や引数が変わる | 更新を揃える／問題が出たら一時的に最小構成 |
| Xcode 更新 | ビルドは通るが実行が落ちる | xcode-select -p で参照先を確認 |
実務で役立つ「ログの見方」：VS Code と CLI の差分を可視化する
原因が分かりにくいときほど、ログを「増やす」より「揃える」方が効きます。おすすめは、VS Code と CLI の両方で 同じコマンドを実行し、差分を比較するやり方です。
差分比較の手順
- CLI（通常のターミナル）で、実行に成功するコマンドを決める
- VS Code の統合ターミナルで、同じコマンドを手で打って実行する
- 成功するなら「タスク/デバッグの経路だけが怪しい」
- 失敗するなら「VS Code の環境変数や SDK 解決が怪しい」
特に which dotnet と dotnet --info は、結果が違うと調査方針が一気に定まります。VS Code の GUI 実行は便利ですが内部で何が呼ばれているかが見えづらいので、まずは同じ土俵に乗せるのがポイントです。
まとめ：最終的な落としどころ
今回のケースの結論は次の通りです。
- .NET MAUI（.NET 9 / Mac Catalyst）を VS Code でビルド・実行すると、Platform が「Any CPU」になり起動できないことがある
- 一方で CLI では空プロジェクトが動くなら、プロジェクトではなく VS Code 側の不整合が濃厚
- 対処は、まず更新を揃え、それでもダメなら VS Code の再インストールで整合性を取り直す
「なぜ Platform が変わるのか」を深追いしすぎるより、CLI で動く＝ツールチェーンはOKという事実を軸に、VS Code の差分を潰す方が最短で解決に近づきます。.NET MAUI のように複数のツールが連携する領域では、エディタ側の状態が崩れるだけで症状が大きく見えることがあるため、再インストールという“整地”が有効な場面は意外と多いです。
コメント