ASPX（ASP.NET Web Forms）で asp:Menu を誤って削除してしまい、Visual Studio のツールボックスからドラッグ＆ドロップできない、手書きしてもデザイナー（フォーム画面）に表示されない――そんなときは、コードのミスではなくデザイナーの表示方式が原因になっていることがよくあります。この記事では、最短で復旧する手順と、直らない場合の切り分けをまとめます。
起きている症状を整理：これは「Menuの配置ミス」ではない
まずは状況を整理します。今回のトラブルは、Menu（asp:Menu）に限らず、Web Forms のデザイナー切り替えで発生しやすい典型例です。
- 以前はページに Menu があったが、誤って削除してしまった
- ツールボックスの「Menu」をフォームへドラッグしても、何も起きない／配置されない
- マークアップに
<asp:Menu ... />を手書きしても、デザイナー上に出てこない - プロパティウィンドウに ID は出るのに、デザイン面が真っ白・グレー・反応しない
この時点で「Menu コントロールが壊れた」と思いがちですが、実際にはVisual Studio の Web Forms デザイナーが “Web Live Preview” 側で開かれていることが原因になっているケースが非常に多いです。
原因の本命：Web Live Preview（新デザイナー）では asp:Menu がうまく扱えないことがある
Visual Studio 2022 では、Web Forms のデザイナーが従来の方式（Legacy）だけでなく、Web Live Preview を基盤にした新しいデザイナーでも動くようになっています。これはブラウザ技術（WebView2/Edge）で画面を描画し、実行結果に近い表示やソースとの同期を行う仕組みです。
ただし、新デザイナーは導入当初から「未実装の機能がある」「既存の Web Forms デザイナーと挙動が違う」ことが明言されており、サーバーコントロールの種類やページの構造によっては、デザイン面が正しく表示されないことがあります。
実際に、asp:Menu が Web Live Preview ではサポートされず表示・配置できない可能性があるため、Legacy（従来の Web Forms デザイナー）へ戻すことで復旧した、という報告が Microsoft Q&A でも確認できます。
「新デザイナーだと何が困る？」を表で確認
| 観点 | Web Live Preview（新デザイナー） | Legacy Web Forms Designer（従来） | 現場での使い分け |
|---|---|---|---|
| 描画方式 | ブラウザ技術で実際の表示に近いプレビュー | 従来のデザインサーフェス | 「見た目を確認したい」なら新、「配置編集」なら従来が安定しやすい |
| ドラッグ＆ドロップ | 可能な設計だが、環境・コントロールによって不安定になり得る | Web Forms では長年実績があり、操作感が安定 | ツールボックス操作が必要なら従来に戻すと解決することが多い |
| ビルド要件 | ページ/プロジェクトがビルド・実行できないとデザイン面が読み込めないことがある | ビルドに依存しない場面も多い | 開発途中でビルドが崩れがちなプロジェクトほど従来が便利 |
最短で直す：Legacy Web Forms Designer に切り替える手順
「Menu が置けない／出ない」問題は、まずここを試すのが最短ルートです。ポイントは切り替え後に Visual Studio を再起動することです。
- Visual Studio のメニューから [Tools]（ツール） → [Options]（オプション） を開く
- 左ペインで [Web Forms Designer] を開く（見つからない場合は Options の検索ボックスで “Web Forms” と検索）
- [General]（一般）付近にあるデザイナー設定で、Web Forms designer (requires restart) の項目を確認する
- 設定が Web Live Preview になっている場合は、Legacy Web Forms Designer（従来のデザイナー）を選択する
- Visual Studio を再起動する
再起動後、対象の .aspx を開き直し、Design（デザイン）または Split（分割）表示でフォーム画面を確認してください。多くの場合、これだけで asp:Menu がデザイナーに表示され、ツールボックスから配置できる状態に戻ります。
復元の基本：asp:Menu を「確実に」戻す最小コード
ドラッグ＆ドロップが効くようになったら、ツールボックスから配置しても良いのですが、Web Forms はマークアップに手書きして復旧するのが早い場面も多いです。まずは最小構成で表示させ、あとからプロパティを調整していく方法が安全です。
最小の Menu（固定メニュー）
次のコードは「ページ内に確実に Menu を復元する」ための最小例です。まずは <form runat=”server”> の配下（または MasterPage の ContentPlaceHolder 配下）に置きます。
<asp:Menu ID="MainMenu" runat="server" Orientation="Horizontal">
<Items>
<asp:MenuItem Text="ホーム" NavigateUrl="~/Default.aspx" />
<asp:MenuItem Text="製品">
<asp:MenuItem Text="製品A" NavigateUrl="~/Products/A.aspx" />
<asp:MenuItem Text="製品B" NavigateUrl="~/Products/B.aspx" />
</asp:MenuItem>
<asp:MenuItem Text="お問い合わせ" NavigateUrl="~/Contact.aspx" />
</Items>
</asp:Menu>「まず表示させる」ことが目的なので、スタイルや Static/Dynamic の細かい設定は後回しで問題ありません。デザイナーに出る状態を作れれば、あとはプロパティウィンドウで調整できます。
SiteMap 連動の Menu（サイトマップから自動生成）
複数ページを持つ Web Forms では、Web.sitemap を作ってメニューを自動生成する構成も定番です。復旧後にメニューを育てていくなら、こちらの方が保守が楽になることがあります。
<asp:SiteMapDataSource ID="SiteMapDataSource1" runat="server" ShowStartingNode="False" />
<asp:Menu ID="MainMenu" runat="server"
DataSourceID="SiteMapDataSource1"
Orientation="Horizontal"
StaticDisplayLevels="2">
</asp:Menu>Menu が消えて困ったときに「ページごとにメニューを直す」構造だと復旧が大変です。MasterPage やユーザーコントロール（.ascx）に集約しておくと、今後の事故にも強くなります。
直らないときの切り分け：チェック項目を上から潰す
Legacy に切り替えても改善しない場合は、次のいずれかが重なっていることが多いです。ポイントは、Menu 固有の問題か、デザイナー全体の問題かを切り分けることです。
まずは他のコントロールで確認する
- TextBox や Button はドラッグ＆ドロップできるか
- できるなら「Menu だけ」の可能性が高い
- できないなら「デザイナー側の状態（読み取り専用・エラー・キャッシュ破損）」を疑う
デバッグ実行中だとデザイナーが読み取り専用になることがある
Web アプリをデバッグ実行している最中は、デザイナーが読み取り専用になり、ドラッグ＆ドロップが効かないことがあります。まずはデバッグを停止し、.aspx を開き直してから試してください。
配置先が「置ける場所」になっているか（最重要）
Web Forms のサーバーコントロールは、基本的に <form runat=”server”> 配下に置く必要があります。MasterPage を使っている場合は、Content ページの <asp:Content …> の中でも、正しい ContentPlaceHolder を選んで配置します。
| よくある配置ミス | 起きること | 直し方 |
|---|---|---|
| <form runat=”server”> の外に置いている | デザイナーに出ない／実行時にエラーになることがある | 必ず form 配下へ移動する |
| MasterPage の外枠（親のレイアウト）に落としている | ドロップできない／意図した場所に入らない | ContentPlaceHolder 内の編集可能領域へ置く |
| 子要素を持てないコントロール上に落としている | 禁止カーソルになり配置できない | body/div/panel など“置ける器”へ落とす |
| フォームが二重（<form> が入れ子）になっている | デザイナーが壊れやすい／ポストバックがおかしくなる | runat=server の form は 1 つにする |
Web Live Preview 由来の制約：ビルドできないとデザイン面が読み込めない場合
もし Web Live Preview 側でデザイン面を開いている場合（または切り替えが反映されていない場合）、ページがビルド・実行できない状態だとデザイン面が読み込めないことがあります。コンパイルエラーが出ていないか、参照エラーがないかを先に直すと表示が戻るケースがあります。
デザイナーのキャッシュ破損を疑う場合の対処
設定を戻しても挙動が変わらない、ある日突然デザイナーだけがおかしくなった、という場合は、Visual Studio 側のキャッシュが影響していることがあります。次の流れで「壊れた状態」をリセットできることがあります。
- Visual Studio を終了する
- ソリューション直下の .vs フォルダ（隠しフォルダ）を削除またはリネームする
- Visual Studio を起動し直し、ソリューションを読み込み直す
キャッシュ削除は万能ではありませんが、デザイナーが極端に不安定なときの定番手当として覚えておくと役立ちます。
aspx.designer.cs が壊れている／更新されないとき
「デザイナーには出るのに、コードビハインド（.aspx.cs）でコントロール名が認識されない」「追加したはずのコントロールが designer.cs に生成されない」といった症状は、designer ファイルの更新が止まっている可能性があります。
- まずはプロジェクトを Build（ビルド）して生成を促す
- それでもダメなら、.aspx を右クリックして Convert to Web Application（Web アプリケーションに変換）を実行し、designer を再生成する
Menu を「表示させる」だけならデザイナーの問題ですが、イベントやプロパティをコード側で触る場合は designer の再生成まで行うと復旧が安定します。
「どうしても新デザイナーを使いたい」場合の現実的な回避策
チームや環境によっては、Web Live Preview のメリット（実表示に近いプレビュー、ソース同期など）を活かしたいこともあります。その場合、次のように割り切るのが現実的です。
- UI 部品の配置編集が必要な画面は Legacy デザイナーで作業する
- レイアウト調整や CSS の当て込みなど、見た目の確認は Web Live Preview で行う
- asp:Menu にこだわらず、HTML/CSS（Bootstrap の nav 等）でメニューを実装し、デザイナー依存を減らす
Web Forms の画面開発は「デザイナーで全部やる」より、マークアップ編集＋実行確認の比率を上げた方が、環境差分の影響を受けにくくなります。
再発防止：Menu を誤って消しても即戻せる運用にする
最後に、同じ事故を繰り返さないための実務的な工夫です。どれも地味ですが、復旧スピードが段違いになります。
| 工夫 | 効果 | ポイント |
|---|---|---|
| メニューは MasterPage または .ascx に集約 | 全ページの復旧が 1 箇所で済む | 「各 .aspx にコピペ」は事故の温床 |
| Git / TFVC などで必ず履歴管理 | 誤削除は差分で即復元できる | Menu に限らず“戻せる”が最強 |
| 最小の Menu スニペットを社内メモに残す | 緊急時の復旧が数分で終わる | 本記事の最小コードをそのまま使える |
まとめ：Menu が置けないときは「デザイナーのモード」を疑う
ASPX（Web Forms）で asp:Menu がツールボックスから配置できない／デザイナーに表示されないとき、最も多い原因はWeb Live Preview（新しいデザイナー）に切り替わっていることです。まずは Tools → Options → Web Forms Designer から Legacy Web Forms Designer に戻し、Visual Studio を再起動してください。そこで復旧しない場合は、配置場所（form 配下）、デバッグ中の読み取り専用、ビルドエラー、designer.cs の再生成を順に確認していくと、最短で原因に辿り着けます。
コメント