Visual StudioでVB.NETの既存ソリューションを開いた途端、昨日まで問題なかったWindows.Application周りが突然赤くなり、「'Application' is not a member of 'Windows'.（Application は Windows のメンバーではありません）」でコンパイルが止まる――。この症状は“キャッシュ不整合”と“名前空間の衝突”の2系統で説明でき、対処の順番を間違えなければ短時間で復旧できます。
突然のコンパイルエラー「Application は Windows のメンバーではありません」とは
エラー文そのものはシンプルですが、実際は「Windowsが何を指しているか」が前日と変わってしまったときに起きやすいトラブルです。特にVB.NETは、プロジェクト設定（インポート/ルート名前空間）や参照追加（WinRT系、Windows SDK系）によって名前解決の優先順位が変わり、同じコードでも突然解釈が変わることがあります。
| 症状 | よくある背景 | 最短ルートの対処 |
|---|---|---|
Windows.Applicationでコンパイルエラー | 名前空間の解釈が変わった／衝突した | 完全修飾名（System.Windows.Application）へ変更 |
| IntelliSenseもおかしい、参照が飛ぶ | Visual Studio側キャッシュ破損・不整合 | .vs削除＋bin/obj削除＋再ビルド |
| NuGet参照が絡む型でだけエラー | 復元漏れ・キャッシュ汚れ・ローカル差分 | NuGetキャッシュクリア＋Restore |
まず最初に押さえるポイント：Windows.Applicationが危うい理由
WPFのApplicationクラスは通常System.Windows.Applicationにあります。一方で、Windows/WinRT系の開発要素を参照すると、トップレベルにWindowsという巨大な名前空間（例：Windows.ApplicationModel等）が入ってきます。
この状態でWindows.Applicationと書くと、コンパイラはまず「トップレベルのWindows」を候補に取り、そこにApplicationというメンバー（型）が見つからないため、今回のようなエラーになり得ます。つまり、原因は「Applicationが消えた」ではなく、“Windowsが別物として解釈されるようになった”ことが本質です。
| あなたが呼び出したいもの | 正しい完全修飾名の例 | よくある誤記/曖昧表記 |
|---|---|---|
| WPFのApplication | System.Windows.Application | Windows.Application |
| WinFormsのApplication | System.Windows.Forms.Application | Windows.Forms.Application |
| VBのアプリケーションオブジェクト（My） | My.Application | Application（どれのApplicationか不明になりやすい） |
| WinRT/Windows SDK系 | Windows.ApplicationModel...など | WPF/WinFormsのつもりでWindowsを直書き |
最短で切り分ける：原因はA（キャッシュ）かB（衝突）か
「前日までOKで翌日突然」という状況は、以下のどちらでも起きます。そこで、遠回りしないために切り分け順を固定します。
切り分けのコツ
- 同じ型名/名前空間のエラーが一斉に増えた → キャッシュ不整合の可能性が高い
Windows.Applicationのような“省略表記だけ”が死んでいる → 名前空間衝突の可能性が高いSystem.Windows.Applicationに書き換えると即直る → ほぼ衝突確定
以降は「まずAで環境を整える → ダメならBで確実に直す」の順で説明します。実際の報告でも、Aのキャッシュ整理や修復では解決せず、Bの完全修飾名に変更したら解消したケースが多く見られます。
解決策A：キャッシュ／環境修復（まず試す基本手順）
Visual Studioは、ソリューションを開くたびに多くの情報（IntelliSense、参照解決、ビルド中間生成物など）をキャッシュします。これが不整合を起こすと、コード自体に問題がなくても「突然エラーになったように見える」状態になります。Aは“環境側のゆがみ”を正すための手順です。
.vsフォルダをリネーム/削除して再ビルド
ソリューション直下にある隠しフォルダ.vsは、Visual Studioの一時情報の塊です。破損や古い情報の残留があると、参照解決が変な状態に固定されることがあります。
- Visual Studioを完全に終了（念のためタスクマネージャーで
devenv.exeが残っていないか確認） - エクスプローラーでソリューションフォルダを開く
- 隠しフォルダ
.vsをリネーム（例：.vs_old）または削除 - ソリューションを開き直してRebuild
削除しても安全です（個人ローカルのキャッシュが再生成されるだけ）。チーム開発でも、ソース管理に入れるべきものではありません。
bin/objを削除してビルド生成物をリセット
.vsはIDE側ですが、ビルド生成物側（MSBuildの中間生成物）も不整合を起こします。各プロジェクト配下のbinとobjを削除してから再ビルドすると、参照周りの“謎の残骸”が消えます。
- ソリューション全体でエラーが連鎖している
- 参照先DLLが更新された/戻された気配がある
- ビルド構成（Debug/Release）を切り替えた
このあたりに心当たりがある場合は、.vsとセットで行うのが効果的です。
Visual Studioの修復（Repair）
拡張機能やコンポーネント更新後に、言語サービスやビルドツールチェーンが部分的に壊れることがあります。以下の流れで修復します。
- Visual Studio Installerを起動
- 対象のVisual Studio（例：2022/2019）の「その他（More）」を開く
- Repairを実行
修復は“最終手段”に見えますが、IDE側の一時不具合を一気に解消できるため、原因不明の時ほど価値があります。
NuGet関連の設定とキャッシュ整理（復元漏れを潰す）
「前日まで動いていたのに翌日突然」でも、実はローカルのNuGetキャッシュや復元状態が変わっていることがあります。特に、複数人開発・複数ブランチ・一部だけパッケージ更新…のような環境では、復元の揺れが出やすいです。
| やること | 狙い | 効果が出やすい症状 |
|---|---|---|
| NuGet「不足パッケージを自動でダウンロード」系を有効化 | 復元漏れを防ぐ | 特定の型/参照だけが突然見えない |
| NuGetキャッシュ（ストレージ）をクリア | 壊れた/古いキャッシュを捨てる | Restoreしても直らない、同じエラーが戻る |
| ソリューションでRestore | 参照解決を再構築 | ビルドだけ失敗、実行環境は残っている |
GUIで行う場合は「ソリューションを右クリック → NuGet パッケージの復元」。コマンドで行う場合は環境に応じて以下が使えます。
dotnet restoredotnet nuget locals all --clear（.NET Framework主体の古い構成ではnuget.exeを使うこともありますが、まずはVisual StudioのRestoreとキャッシュ整理で十分なことが多いです）
ここまでやっても直らない場合
Aの手順は「環境の不整合」を消します。ここで改善しない場合、次に疑うべきは“コードの意味が別物に解釈されている”、つまりBの名前空間衝突です。
解決策B：名前空間の衝突を避ける（今回の決め手）
結論から言うと、Windows.Applicationのような曖昧になりやすい参照をやめて、完全修飾名（フルネーム）で指定するのが最も堅い解決策です。
最短で直す書き換え例
WPFのApplicationを呼びたい場合は、次のように明示します。
変更前（曖昧）
Windows.Application.Current.Shutdown()変更後（確定）
System.Windows.Application.Current.Shutdown()さらにVB.NETでは、プロジェクトのルート名前空間や同名定義の影響を完全に避けたいとき、Globalを付けてグローバル名前空間から辿るのが安全です。
Global.System.Windows.Application.Current.Shutdown()この書き方にすると、プロジェクト内で偶然SystemやWindowsという名前を使っていても、意図した.NETのSystemへ確実に到達できます。
「なぜ完全修飾名で直るのか」
今回のエラーは、ざっくり言えば次の状態です。
- あなたの意図：
Windows＝System.Windows（WPF） - コンパイラの解釈：
Windows＝ 別のトップレベル名前空間（例：WinRT/SDK由来のWindows） - 結果：その
Windowsの中にApplicationが無いのでエラー
完全修飾名にすると「どのWindowsか」を迷う余地がなくなるため、名前空間衝突の影響が消えます。Aのようなキャッシュ整理で直らない場合でも、Bが“解釈のズレ”を強制的に正すため、決定打になりやすいのです。
別案：Importsを整理して短く書く（ただし慎重に）
コード全体を短く保ちたい場合、次のようにImportsで明示し、以降はApplicationだけで書く方法もあります。
Imports System.Windowsただし、WinFormsも併用しているプロジェクトではSystem.Windows.Forms.Applicationも存在し、Application単体だと別物に解決されることがあります。混在環境では、完全修飾名のままにするか、次のようにエイリアスで衝突を避けるのがおすすめです。
Imports Wpf = System.Windows
' 以降
Wpf.Application.Current.Shutdown()衝突元を特定する：原因調査の具体手順
「直ったけど、なぜ昨日まで大丈夫だったのか」を潰しておくと再発防止になります。衝突元の探し方を、Visual Studio上でできる範囲で整理します。
Windowsが何に解決されているかを確認する
- 「定義へ移動（F12）」：
Windowsにカーソルを置いてF12。どの名前空間/アセンブリに飛ぶかを見る - クイック情報：ホバーで型/名前空間のフルパスを確認
- オブジェクトブラウザー：
Windowsで検索し、存在するトップレベル名前空間を把握
ここで、意図と違う場所（WinRT/Windows SDK由来のWindows）へ解決されているなら、Bが刺さる理由がはっきりします。
ソリューション内に「Windows」という自作定義がないか検索
衝突は参照ライブラリだけでなく、プロジェクト内の命名でも起きます。以下のキーワードで「ソリューション内検索」をかけてください。
Namespace WindowsClass Windows/Module WindowsImports WindowsImports System（通常は問題ないが、Imports構成を整理する際の確認用）
もし自作のNamespace WindowsやWindowsというクラス/モジュールが見つかった場合は、可能なら名称変更（例：AppWindowsやUiWindowsなど）を検討してください。プラットフォームや標準ライブラリと同名は、将来の拡張で衝突が起きやすく、今回のように“突然壊れる”地雷になりがちです。
プロジェクトの「インポートされた名前空間」を確認（VB特有の盲点）
VB.NETはプロジェクト設定で、暗黙的に多くの名前空間がインポートされています。ここにトップレベルのWindowsが追加されると、Windows.Applicationの解決先が変わることがあります。
確認の目安（UI名は環境で多少違いますが、概ね以下）：
- プロジェクトのプロパティ
- 参照（References）関連の画面
- 「インポートされた名前空間（Imported namespaces）」一覧
不要なものが入っている場合は外すと改善することがあります。ただし、外すことで別の箇所が壊れる場合もあるため、修正範囲が小さい完全修飾名方式（B）のほうが安全に終わるケースが多いです。
参照追加やパッケージ更新の“痕跡”をチェック
「見た目上は環境変更なし」でも、次のような変化が裏で起きていることがあります。
| 変化の例 | 起きやすい影響 | 確認ポイント |
|---|---|---|
| Windows SDK/WinRT系の参照が入った | Windowsがトップレベルとして強く意識される | 参照一覧、パッケージ一覧、最近のマージ差分 |
| Visual Studio更新で言語サービスが変わった | 名前解決の優先順位が変わったように見える | VSの更新履歴、拡張機能の更新 |
ブランチ切替で.vbprojが微妙に変わった | インポート/参照が変わる | Git差分で.vbprojを確認 |
WPF/WinForms/.NETの違いで見落としがちな確認点
「WPFのSystem.Windows.Applicationを使っているつもり」でも、プロジェクトの種類やターゲットで前提が変わります。ここがズレると、別のエラーに発展することもあるため、ついでに押さえておきましょう。
.NET（Core/5/6/7/8）でWPFを使う場合の基本
WPFを.NET（.NET 5以降）で使う場合、プロジェクトファイル側でWindows向けターゲットとWPF有効化が必要です（既存プロジェクトなら入っているはずですが、ブランチ差分で抜けることがあります）。
<PropertyGroup>
<TargetFramework>net8.0-windows</TargetFramework>
<UseWPF>true</UseWPF>
</PropertyGroup>この前提が崩れていると、System.Windows.Application自体が見えなくなり、今回とは別の型未定義エラーになります。「完全修飾名にしても直らない」場合は、ここも疑ってください。
WinFormsならSystem.Windows.Forms.Application
WinFormsでアプリ全体を制御したい場合は、WPFではなくWinForms側のApplicationです。混在プロジェクトだと、Applicationという名前が複数あるため、曖昧さが増します。
- WinForms：
System.Windows.Forms.Application - WPF：
System.Windows.Application - VB（My）：
My.Application
「昨日まで動いた」が通じないのは、曖昧さがあるコードほど“解釈の揺れ”に弱いからです。今回のWindows.Applicationは、まさにそれに当たります。
再発防止：同種の「突然壊れた」を減らす実践ルール
直った後に、同じ手戻りを避けるための運用・コーディングルールをまとめます。どれも大掛かりな仕組みは不要で、日常の小さな選択で効いてきます。
曖昧な名前空間省略をやめる
Windows.Applicationのように「前提のImportsに依存する書き方」は避ける- 衝突しやすい型名（
Application,Window,Message,Dispatcherなど）は、混在環境なら特に完全修飾名を優先 - VBなら
Global.System...まで使うと、プロジェクト内命名の影響を受けにくい
プロジェクト内で「System」「Windows」などの大物名前を使わない
将来のSDK追加やフレームワーク更新で衝突する確率が上がります。自作名前空間は、組織名や製品名など固有プレフィックスを付けると安全です。
パッケージ復元を“必ず再現できる状態”にする
- チーム開発なら、パッケージの更新方針（勝手に更新しない/定期更新）を決める
- CI（ビルドサーバー）でクリーン環境ビルドを回し、「ローカルだけ通る」を減らす
- .NET SDKを固定したい場合は
global.jsonの導入も検討（プロジェクト要件次第）
“直し方”をチェックリスト化しておく
この手のトラブルは、次に起きたときに「どこから触るべきか分からない」状態になりがちです。社内WikiやREADMEに、最低限これだけ書いておくと復旧が早くなります。
| 優先度 | チェック項目 | 判断基準 |
|---|---|---|
| 高 | .vs削除、bin/obj削除、Rebuild | IDE/ビルドが怪しいときの定番 |
| 高 | Windows.ApplicationをSystem.Windows.Applicationへ | 省略表記だけ死んだときの最短手 |
| 中 | NuGetキャッシュクリア＋Restore | 参照が復元されていない気配がある |
| 中 | プロジェクトのImported namespaces確認 | Windowsの解釈が変わった疑い |
| 低 | Visual Studio Repair | 他案件でもIDEが不安定、再発が多い |
よくある質問
Windows.ApplicationとSystem.Windows.Applicationは同じものですか？
意図としては「SystemがImportsされている前提でWindowsをSystem.Windowsとして使う」ことで同じものを指したい、というケースが多いです。ただし、トップレベルに別のWindows名前空間が見えると解釈が変わるため、結果として同じになりません。確実にWPFのApplicationを指したいなら、System.Windows.Application（必要ならGlobal付き）を推奨します。
なぜ「環境変更なし」なのに翌日突然起きるのですか？
主な理由は次のどれかです。
- Visual Studioや拡張機能が自動更新され、名前解決やキャッシュの挙動が変わった
- ブランチ切替やマージで、参照/Importsが微妙に変化していた（気づきにくい）
- ローカルのキャッシュや復元状態が壊れ、表面上だけコードが悪いように見えた
だからこそ、A（環境リセット）→B（完全修飾名）の順で潰すと、混乱が少なくなります。
.vsを消すと設定が壊れませんか？
基本的に壊れません。.vsはローカルキャッシュで、削除すると再生成されます。ソース管理に入れるべきではない領域です。ただし、個人のブックマークや一部のIDE状態がリセットされることはあるため、気になる場合は「削除」ではなく「リネーム」が安心です。
完全修飾名に直すのが正解なら、最初からそう書くべきですか？
混在環境（WPF/WinForms/WinRT、複数SDK、複数参照が入りやすいプロジェクト）ほど、最初から完全修飾名を推奨します。一方、単純な単独プロジェクトであればImportsで短く書いても運用できます。判断基準は「将来、参照やSDKが増える可能性があるか」「同名型が増えやすいか」です。
書き換えが大量でつらい場合は？
大量発生している場合は、闇雲に手で直す前に以下を検討してください。
- まずは衝突が発生している箇所を1つ完全修飾名にしてビルドが通るか確認（原因確定）
- 原因が確定したら、置換（検索/置換）で機械的に直す
- Importsの整理やエイリアス導入で、変更範囲を小さくできるか検討
それでも直らないときの次の一手は？
System.Windows.Applicationに直しても解決しない場合は、名前解決ではなく参照/ターゲットの問題の可能性が出てきます。WPFならターゲットがnetX.Y-windowsになっているか、UseWPFが有効か、必要な参照が生きているかを確認してください。あわせて、.vbprojの差分（最近の変更）と、NuGetのRestore状態も再チェックすると原因に近づきます。
コメント