Visual Studio 2022 を 17.14.0 Preview 2 に更新した直後から、.NET MAUI（.NET 8 / net8.0-android34 など）が読み込めない・ビルドできない、NU1102 が出る――そんなトラブルに遭遇した方向けに、原因の見立てと即効性のある回避策を整理します。
起きていること：更新後に MAUI プロジェクトが開かず、復元もビルドも失敗する
今回のトラブルは、プロジェクトのコード変更というより開発環境（Visual Studio / .NET ワークロード / NuGet 復元）側の不整合が引き金になりやすいのが特徴です。特に Preview 版は、ワークロードのマニフェスト（「どのパッケージをどのバージョンで入れるか」を定義する情報）が更新されるため、ひとつの参照ズレが MAUI 全体のビルド不能に直結します。
| 症状 | よく出るメッセージ例 | 開発への影響 |
|---|---|---|
| プロジェクトが読み込めない | ソリューションは開くが MAUI プロジェクトが「読み込み失敗」になる | デザイナ/ビルド/デバッグが進められない |
| NuGet 復元で NU1102 | NU1102 Unable to find package Microsoft.Android.Ref.34 with version (= 34.0.148) | 参照が解決できず、ビルドが即停止 |
| workload の要求が増える | 「このプロジェクトをビルドするには wasm-tools-net8 ワークロードが必要」 | 不足ワークロードの指摘が出続け、環境修復のループに入る |
| workload restore 自体が失敗 | Version 35.0.50 of package microsoft.android.sdk.windows.msi.x64 is not found in NuGet feeds ... | 不足分を入れたくても入れられず、復旧できない |
エラーの読み解き：NU1102 と workload restore 失敗は「別物」ではなく同じ根っこ
一見すると「NuGet のパッケージが見つからないだけ」に見えますが、.NET MAUI の Android ビルドはNuGet パッケージと.NET Workload（ワークロード）が密接に絡みます。
.NET MAUI の Android/Windows 周りは “workload で配布されるパッケージ集合”
.NET 6 以降、Android や iOS、WebAssembly などの開発基盤は、SDK 本体に同梱されるのではなくワークロードとして配布・更新される設計になっています。Visual Studio の更新や .NET SDK の更新により、ワークロードの参照先（必要パッケージとバージョン）が変わることがあります。
このとき、マニフェスト側が「存在しないバージョン」を参照してしまうと、次のような連鎖が起こります。
- ワークロードが要求するパッケージが NuGet から取れない
dotnet workload restoreが失敗し、環境が中途半端な状態で止まる- 結果として、MAUI の復元/ビルドで NU1102 などが発生し続ける
重要:
Microsoft.Android.Ref.34は通常、開発者が直接インストールして使うための “アプリ用ライブラリ” ではありません。エラーに出てきたからといって、手動で追加したり、無理に特定バージョンを探したりすると、むしろ環境の整合性が崩れて復旧が遠回りになります。
「nuget.org にそのバージョンが存在しない」＝自分でどうにかできる問題ではない
今回のパターンでは、nuget.org 上に 34.0.147 や 34.99.0-preview.1.xxx は見えるのに、エラーが要求している 34.0.148 は見つからない、という形になりがちです。これはプロジェクトが悪いというより、環境側が “存在しない番号” を指してしまっている状態だと考えるのが自然です。
さらに microsoft.android.sdk.windows.msi.x64 のようなパッケージもワークロードから参照されます。ここで特定バージョンが取得できないと、Android 開発基盤そのものが入れ直せず、MAUI の復元・ビルドも当然止まります。
まずは切り分け：プロジェクトの問題ではなく環境の問題かを短時間で確認する
結論を急ぐなら、「いまの PC の .NET/Visual Studio が壊れているのか」を先に確認すると迷いが減ります。以下は、時間をかけずに “環境側” を疑えるチェックポイントです。
| チェック | 確認方法 | 見るべきポイント |
|---|---|---|
| 使用中の SDK | dotnet --info | .NET 8 系 SDK が使われているか / 想定外に preview SDK が選ばれていないか |
| ワークロードの状態 | dotnet workload list | maui, android 系の workload が入っているか |
| 復元の失敗箇所 | dotnet workload restore | どのパッケージの “どのバージョン” が見つからないと言っているか |
| NuGet ソース | dotnet nuget list source | nuget.org が無効化されていないか / 社内ミラーのみになっていないか |
コマンドは次のセットで十分です（結果はスクリーンショットで控えておくと、後述のフィードバック報告にも使えます）。
dotnet --info
dotnet workload list
dotnet workload restore
dotnet nuget list source
最短で復旧する回避策：Visual Studio をロールバックする
現場で一番困るのは「原因を追いかけている間に開発が止まること」です。Preview 2 特有の不整合が疑われる場合、スレッド内で実際に有効だった暫定対処はVisual Studio のロールバックです。
ロールバックの候補（どれを選ぶべきか）
| 戻す先 | 向いている状況 | ポイント |
|---|---|---|
| 安定版 17.13.x（例：17.13.3 / 17.13.2） | 日常開発・本番案件・納期優先 | まず開発を再開したいなら最優先。MAUI の更新も安定しやすい |
| プレビュー版 17.14.0 Preview 1 | プレビュー機能検証を続けたい | Preview 2 に固有の問題を避けつつ、検証を継続しやすい |
Visual Studio Installer でのロールバック手順
- Visual Studio をすべて終了します（VS 本体だけでなく、関連する MSBuild や dotnet の処理が残っていない状態にします）。
- Windows の「Visual Studio Installer」を起動します。
- 対象の Visual Studio インスタンス（Preview など）を見つけ、「詳細」または「その他」メニューから「ロールバック」を選びます（表示されない場合は、更新履歴やインストールの状態により、いったん Preview 側をアンインストールしてから別バージョンを入れる流れになります）。
- ロールバック完了後、PC を再起動してから Visual Studio を起動します。
運用のコツ: Visual Studio の安定版とプレビュー版は共存インストールが可能です。プレビューは検証用、安定版は日常開発用と分けると、今回のような “突然ビルド不能” の影響を最小化できます。
ロールバック後にやっておくと安定する「環境の整え直し」
ロールバックだけでビルドが通るケースも多い一方、更新の途中でワークロードやキャッシュが中途半端に残っていると、復元が不安定になったり、同じエラーが再発したりします。次の順番で “整え直し” をすると安全です。
手順
- NuGet キャッシュをクリア（壊れたダウンロードや古いメタデータを一掃）
- workload の修復/再同期（ロールバックした VS / SDK と整合する状態に寄せる）
- プロジェクトの復元とビルド（最小手順で成功を確認）
dotnet nuget locals all --clear
dotnet workload repair
dotnet workload restore
dotnet restore
dotnet build
もし dotnet workload repair が重い、あるいは再び “見つからないバージョン” を取りに行って失敗する場合は、いったん Visual Studio Installer の「変更（Modify）」で MAUI 関連コンポーネントが揃っているかを確認し、必要なら Android/MAUI 関連を入れ直す方が早いこともあります。
それでも NU1102 が消えない場合に見るべきポイント
ロールバックしたのに NU1102 が残る場合、原因は大きく分けて「プロジェクトが特定のバージョンを固定している」か「NuGet ソース/ロックが復元を阻害している」かのどちらかです。見落としやすい箇所をまとめます。
プロジェクト側で “存在しないバージョン” を固定していないか
- 明示的な PackageReference：
Microsoft.Android.Ref.34をプロジェクトや共通 props に直接書いていないか（書いている場合は削除・見直し） - Directory.Build.props / Directory.Build.targets：ソリューション全体で参照を固定していないか
- packages.lock.json：ロックモードが有効で、古い/不整合なバージョンを強制していないか
global.json による SDK 固定で “意図せず preview SDK” を使っていないか
リポジトリ直下に global.json があると、マシンに入っている SDK の中から特定のバージョンが選ばれます。Preview 版の SDK を指していると、Visual Studio をロールバックしても dotnet restore の挙動が変わらず、復旧が進まないことがあります。
次のコマンドで、実際に使われている SDK を確認できます。
dotnet --version
dotnet --info
NuGet ソースの構成（社内ミラー/プロキシ/フィルタリング）
nuget.org が無効化されていたり、社内ミラーに限定されていたりすると、プレビュー系・特定のワークロード関連パッケージが取得できないことがあります。特にエラー文に “in NuGet feeds” と複数のフィードが列挙されている場合は、どのフィードを見に行っているかを一度確認してください。
dotnet nuget list source
ただし今回のケースでは「nuget.org にそもそも該当バージョンが存在しない」形になりやすいため、ユーザー側でフィードをいじっても根本解決にならないことが多い点は押さえておきましょう。
「wasm-tools-net8 が必要」と言われる理由と、焦らない対処
MAUI の開発中に、突然「wasm-tools-net8 ワークロードが必要」と表示されると驚きますが、これは “あなたのアプリが必ず WebAssembly を使っている” という意味とは限りません。Visual Studio や SDK が、現在のソリューション構成・インストール済み workload 情報から必要そうなワークロードを推定して促しているだけの場合があります。
ただし、ワークロードの復元自体が壊れていると、この促しに従ってもインストールに失敗し続けます。今回のように microsoft.android.sdk.windows 系の取得エラーが出ているなら、先にAndroid/MAUI ワークロードの整合性を回復させる（ロールバック含む）方が近道です。
Developer Community への報告と、修正版リリースに備える
Preview 版の組み合わせで起きる不整合は、ユーザー側の努力だけでは回避しきれないことがあります。同様の現象が出ている場合は、次の 2 つをやっておくと “修正が早まる確率” を上げられます。
既存チケットのウォッチと追記
同種のエラー（microsoft.android.sdk.windows の特定バージョンが取得できない、など）は、Developer Community で報告・調査中として扱われていることがあります。すでに似たチケットがある場合は、自分の環境情報（VS バージョン、SDK バージョン、失敗したパッケージ名とバージョン、ログ）を追記するのが効果的です。
「送信フィードバック」でログを添付
Visual Studio の「送信フィードバック」から、ワークロード復元のログやインストーラのログを添付しておくと、再現性の確認が進みやすくなります。特に次の情報は、状況説明の “芯” になります。
- Visual Studio の正確なバージョン（例：17.14.0 Preview 2）
- .NET SDK バージョン（
dotnet --infoの結果） - 発生したエラー全文（NU1102 の対象パッケージ名と要求バージョン）
dotnet workload restoreの失敗ログ
プレビュー版で MAUI を触るときに、開発を止めないための実践的な運用
プレビュー版は新機能の検証に便利な一方で、今回のように “突然ビルド不能” になるリスクがゼロではありません。MAUI はワークロード依存が大きいぶん、影響が出ると復旧コストも上がります。そこで、現場目線で効く運用をいくつか紹介します。
安定版を主軸にし、プレビューは検証用に隔離する
- 普段の開発・リリース作業は安定版で行う
- プレビューは別インスタンス/別 PC/別ユーザーで検証する
- ソリューションを開く VS を意識的に選ぶ（誤って Preview で開いて更新される事故を防ぐ）
更新前に “戻れる状態” を作っておく
- 更新前に、現在の VS バージョンと workload の状態（
dotnet workload list）を控える - スプリント/締切前はプレビュー更新を避け、更新タイミングを決めて行う
- CI（ビルドサーバー）は安定版 SDK / 安定版 VS に固定し、ローカルの更新に引きずられないようにする
「Android 34 / net8.0-android34」周りは特に慎重に
Android のターゲット API レベルや参照パックは、SDK/ワークロード更新の影響を受けやすい領域です。エラーに Microsoft.Android.Ref.34 のような参照パックが出てきたら、「アプリの依存関係」ではなく「ワークロードの内部参照」が壊れている可能性を疑い、まず環境を疑うのがセオリーです。
よくある質問
NU1102 が出たので、nuget.org にある近いバージョン（34.0.147 など）に手で合わせれば直りますか？
プロジェクトが直接そのパッケージを参照している場合は話が別ですが、今回のようにワークロード由来で要求されているなら、手作業で “近い番号” に合わせても根本解決になりません。ワークロード全体の整合性（マニフェストと取得できるパッケージの組み合わせ）を回復させる方が安全です。
「手動で Microsoft.Android.Ref.34 を入れてはいけない」とは？
参照パックは、通常はワークロードが自動で管理する領域です。開発者が個別にバージョンをピン留めしてしまうと、次の更新でワークロードが期待するバージョンと衝突し、復元やビルドの問題を増幅させることがあります。まずは “環境側の正常化” を優先してください。
ロールバック以外に、いまの Preview 2 のまま直す方法はありますか？
プロジェクト側の設定やフィードの問題であれば修正できる余地がありますが、「存在しないバージョンを参照している」タイプはユーザー側での完全な回避が難しいことがあります。開発を止めない目的なら、いったんロールバックして作業を継続し、修正版（後続 Preview / 正式版）で再チャレンジするのが現実的です。
まとめ：迷ったら “ロールバックで復旧” → “チケットを追う” が現実解
- Visual Studio 2022 17.14.0 Preview 2 更新後、.NET MAUI が読み込めない/ビルドできない場合は、環境側（workload/参照パック）の不整合を疑う
Microsoft.Android.Ref.34のような内部参照が要求する “存在しないバージョン” が原因のとき、手動でパッケージを追加して直そうとしない- 最短で開発を再開するなら、Visual Studio を 17.13.x などの安定版、または 17.14.0 Preview 1 にロールバックする
- 再発を避けるには、安定版とプレビュー版を共存させ、更新タイミングを管理する
- 同様の症状は Developer Community に集約されやすいので、ログ付きで追記し、修正版の情報を追う
コメント