VB.NET（Visual Studio 2022）で「フォームを.aspxにリネームしたのにメニューが作れない」という相談は少なくありません。拡張子を変えるだけではデスクトップ用フォームはASPXにならないため、まずWeb側の正しい土台を用意し、その上でナビゲーションを実装する必要があります。
「フォームを.aspxにリネーム」ではWebページにならない理由
最初に押さえておきたいのは、拡張子の変更は「変換」ではないという点です。Windowsフォーム（WinForms）やWPFの画面は、Visual Studioが生成するデスクトップアプリ用のクラスであり、実行時はWindows上で動くEXEの一部として描画されます。一方、ASPX（ASP.NET Web Forms）は、IIS（またはIIS Express）上で動くWebアプリとして、HTTPリクエストに応答してHTMLを生成する仕組みです。
たとえばWordファイルを「.xlsx」にリネームしてもExcelファイルにならないのと同様に、Windowsフォームのファイル名を.aspxにしても、ASP.NETが解釈できるページにはなりません。結果として、デザイナーが開けない、ビルドでエラーになる、実行しても表示できない、といった問題が起きます。
| 項目 | Windowsフォーム（デスクトップ） | ASPX（ASP.NET Web Forms） |
|---|---|---|
| 実行環境 | Windows上のEXE（ローカルで描画） | IIS / IIS Express（HTTPで配信） |
| 主なファイル構成 | .vb / .Designer.vb / .resx | .aspx / .aspx.vb / .aspx.designer.vb（+Web.config等） |
| UIの仕組み | コントロールを直接配置し、イベントで動く | HTMLを生成し、ポストバックでイベントを再現 |
| メニューの作り方 | MenuStrip、TreeViewなど | asp:Menu、Bootstrapのナビ、独自HTMLなど |
最初にやるべきこと：プロジェクト種別を確認する
「ASPXでメニューを作りたい」なら、まずWeb Formsが動くプロジェクトになっている必要があります。Visual Studio 2022では、同じVB.NETでもプロジェクト種別によって作れる画面や動く仕組みがまったく異なります。
確認ポイント（Visual Studio 2022）
- ソリューションエクスプローラーでプロジェクトを右クリック →「プロパティ」を開き、ターゲットフレームワークを確認する
- 参照にSystem.Webがあるか（Web Formsは基本的に.NET Framework + System.Webが前提）
- Web.config、Global.asax、App_Startなど、Webアプリ特有の構成があるか
| あなたの状況 | 起きやすい状態 | 次にやるべきこと |
|---|---|---|
| WinForms/WPFのプロジェクトで.aspxを作ろうとしている | ASPXのデザイナーが開けない、実行できない | Web Forms（.NET Framework）プロジェクトを新規に作る |
| ASP.NET Core（.NET 6/7/8）でWebを作っている | .aspxが存在しない（Razorの.cshtmlが中心） | ASPXにこだわるならWeb Formsへ、こだわらないならRazorでナビを作る |
| ASP.NET Web Formsプロジェクト（.NET Framework）で作っている | 正しい道筋。メニュー実装の選択肢が多い | Master Pageを軸にナビを共通化する |
リネームしてしまった場合の安全な戻し方
既存のフォームを.aspxにリネームした場合、ファイル間の関連付け（Partialクラス、Designerファイル、resxなど）が崩れている可能性があります。まずは元の拡張子に戻すことを優先してください。
- ソース管理（Git等）を使っているなら、履歴から元に戻すのが最も確実
- ソース管理がない場合は、拡張子を戻し、フォームデザイナーが開けるか確認する
- Designerやresxが壊れているときは、新規フォームを作って部品を移植した方が早いことも多い
ここで大事なのは、「Webで見せたいからファイルをWebっぽくする」ではなく、Webアプリとして動く土台を作ってから画面を作るという順序です。
ASPX（Web Forms）でメニュー（ナビゲーション）を作る王道手順
ASPXページでメニューを作る場合、まずおすすめしたいのはMaster Page（マスターページ）を使って、全ページ共通のナビゲーションを一箇所にまとめる方法です。ページごとに同じHTMLをコピペすると、リンク追加や並び替えのたびに修正漏れが起きます。
手順1：Web Formsプロジェクトを正規ルートで作成する
Visual Studio 2022で次の流れで作ると、Web Formsとして必要な構成が揃います。
- 「新しいプロジェクトの作成」→ ASP.NET Web アプリケーション (.NET Framework)
- テンプレート選択で Web Forms を選ぶ（必要に応じて「認証」も設定）
- 言語はVB.NETでもOK（Web FormsはVBの実績が多い）
手順2：Master Pageを作り、メニューを置く
Web Formsでは、Master Page（例：Site.Master）にメニューを配置し、各ページはContentページとして中身だけを差し替えるのが定石です。
<%@ Master Language="VB" AutoEventWireup="false" CodeBehind="Site.master.vb" Inherits="WebApplication1.SiteMaster" %>
<!DOCTYPE html>
<html>
<head runat="server">
<meta charset="utf-8" />
<title><asp:ContentPlaceHolder ID="TitleContent" runat="server" /></title>
</head>
<body>
<form id="form1" runat="server">
<!-- ここに共通メニューを置く -->
<asp:Menu ID="MainMenu" runat="server" Orientation="Horizontal">
<Items>
<asp:MenuItem Text="ホーム" NavigateUrl="~/Default.aspx" />
<asp:MenuItem Text="商品一覧" NavigateUrl="~/Products.aspx" />
<asp:MenuItem Text="お問い合わせ" NavigateUrl="~/Contact.aspx" />
</Items>
</asp:Menu>
<!-- 各ページの中身はここに入る -->
<asp:ContentPlaceHolder ID="MainContent" runat="server" />
</form>
</body>
</html>ポイントは次の通りです。
- Web Formsのサーバーコントロール（asp:Menuなど）はrunat=”server”が必須
- 基本的にページ全体を包む<form runat=”server”>が必要（ポストバックに使う）
- メニューを全ページ共通にしたいなら、Contentページ側ではなくMaster Page側に置く
手順3：メニュー項目を「一箇所」で管理する（SiteMapの活用）
ページ数が増えると、Master PageにMenuItemを直書きする方式は管理が大変になります。Web Formsにはサイトマップ（Web.sitemap）で階層構造を定義し、メニューに自動反映する仕組みがあります。
<?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0">
<siteMapNode url="~/Default.aspx" title="ホーム">
<siteMapNode url="~/Products.aspx" title="商品一覧" />
<siteMapNode url="~/Contact.aspx" title="お問い合わせ" />
</siteMapNode>
</siteMap>Master Page側は次のようにデータソースをつなぐだけで、サイトマップの構成がメニューに反映されます。
<asp:SiteMapDataSource ID="SiteMapDataSource1" runat="server" />
<asp:Menu ID="MainMenu" runat="server" DataSourceID="SiteMapDataSource1" Orientation="Horizontal" />この方式のメリットは、リンク追加や並び替えをWeb.sitemapだけで完結できることです。さらにパンくず（SiteMapPath）とも連携しやすく、Webサイトとしての導線が整えやすくなります。
「Menuコントロール」だけが正解ではない：Bootstrapナビで作る方法
最近のWebサイトらしい見た目にしたい場合、Web FormsでもHTML + CSSフレームワーク（Bootstrapなど）でナビゲーションを作るのが現場ではよくあります。サーバーコントロールは手軽ですが、CSSの自由度やレスポンシブ対応で苦戦することがあるためです。
BootstrapナビをWeb Formsで使うときの考え方
- ナビ自体はほぼHTMLで作り、URL解決だけWeb Formsに任せる
- <a>タグにrunat=”server”を付け、href=”~/…”でルート相対を使う
- 共通化はMaster Pageに置く（やることはMenuコントロールと同じ）
<nav class="navbar navbar-expand-lg navbar-light bg-light">
<div class="container-fluid">
<a class="navbar-brand" runat="server" href="~/Default.aspx">MyApp</a>
<div class="collapse navbar-collapse">
<ul class="navbar-nav me-auto">
<li class="nav-item">
<a class="nav-link" runat="server" href="~/Default.aspx">ホーム</a>
</li>
<li class="nav-item">
<a class="nav-link" runat="server" href="~/Products.aspx">商品一覧</a>
</li>
<li class="nav-item">
<a class="nav-link" runat="server" href="~/Contact.aspx">お問い合わせ</a>
</li>
</ul>
</div>
</div>
</nav>このやり方なら、見た目はBootstrapに寄せつつ、パスの解決や環境差異（仮想ディレクトリ配下など）をWeb Forms側に任せられます。WordPressのテーマ編集のようにHTMLを扱う感覚に近いので、Webの作法に慣れる練習にもなります。
実装方式の比較：どれを選ぶべきか
| 方式 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| asp:Menu（MenuItem直書き） | ページ数が少ない、まず動かしたい | 最短で動く、コード量が少ない | ページが増えると管理がつらい |
| asp:Menu + Web.sitemap | 階層がある、導線を整えたい | メニューを一元管理できる、パンくずと相性が良い | サイトマップの設計が必要 |
| Bootstrap等のHTMLナビ | 見た目重視、レスポンシブ対応したい | デザイン自由度が高い、フロント寄りの資産が活きる | HTML/CSSの基礎が必要 |
| ユーザーコントロール（.ascx）で共通化 | メニュー以外も共通部品化したい | 再利用しやすい、テストもしやすい | 構成管理のルール作りが必要 |
テンプレートを使うのが最短：既製のメニューを編集して流用する
学習コストを下げたいなら、最初からナビゲーションが入ったテンプレートを作って、そのメニューを編集するのが近道です。Web Formsでも、プロジェクトテンプレートによってはBootstrapのナビが既に配置されていることがあります。
テンプレート流用の具体例（やることは「編集」だけにする）
- 新規でWeb Formsプロジェクトを作成し、まずはF5で起動して動作確認する
- Master Page（Site.Masterなど）を開き、ナビゲーション部分を探す
- 「Home」「About」「Contact」など既定のリンク名を、自分のページ構成に置き換える
- リンク先（NavigateUrlやhref）を実際のASPXに合わせる
テンプレートを使う最大のメリットは、動く最小構成が最初から揃っている点です。メニュー以外にも、レイアウト、CSS参照、スクリプト読み込み、レスポンシブ対応の雛形が入っているので、「まず形にする」までが一気に短縮できます。
WinForms資産をWebに持っていきたいときの現実的な進め方
「既存フォームをASPXにしたい」という発想の背景には、たいてい既存の画面や処理をWebでも使いたいという目的があります。ただし、UIは仕組みが別物なので、画面そのものを流用するのは難しいです。ここでおすすめなのは、流用できるものと作り直すものを切り分けることです。
| 流用できる可能性が高い | 作り直しになりやすい |
|---|---|
| 計算ロジック、業務ルール、DBアクセス層（整理すれば） | 画面レイアウト、コントロール配置、画面イベントの流れ |
| データモデル、共通ユーティリティ | Drag&Drop、右クリックメニューなどデスクトップ特有UI |
おすすめの分離パターン
- 業務ロジックをクラスライブラリ（Class Library）に切り出し、WinFormsとWeb Formsから参照する
- 将来的にWeb以外（モバイル等）も考えるなら、Web APIを作ってロジックをサービス化する
- 画面側はWebの作法（入力→送信→結果表示）に合わせて設計し直す
この分離ができると、「画面は別でも中身の処理は共有できる」状態になり、リネームのような危険な操作をせずに移行を進められます。
よくあるつまずきポイントとチェックリスト
ASPXでメニューを作る段階で起きやすいミスを、実務でよくある順にまとめます。該当するものがあれば、そこを直すだけで一気に前に進むことが多いです。
| 症状 | 原因 | 対処 |
|---|---|---|
| asp:Menuが表示されない | runat=”server”がない、Master Pageのform配置が崩れている | Menuとformにrunat=”server”があるか確認 |
| リンク先が404になる | 相対パスが想定と違う、仮想ディレクトリ配下 | NavigateUrlに~/を使う（ルート相対） |
| デザインが崩れる | CSSが当たっていない、テンプレートの参照が外れている | Master Pageのhead内でCSS参照を確認 |
| ポストバック後に状態が消える | ViewStateやDataBindのタイミングが原因 | IsPostBackを見て初回のみバインドする |
| そもそも.asax/.configがない | Webプロジェクトではなくデスクトップ側で作業している | Web Formsプロジェクトを作り直して移植 |
「ASPXで作るべきか」を迷ったときの判断軸
最後に、これから新規開発をする場合の判断材料も整理しておきます。既存資産やチームの事情でWeb Formsを選ぶケースは十分ありますが、選定理由が曖昧だと後で苦しくなるためです。
- 既存がWeb Formsで統一されている → Web Forms継続が合理的（保守性・学習コスト）
- 完全新規で長期運用、クラウドやコンテナも視野 → ASP.NET Core（Razor Pages/MVC/Blazor）を検討
- VB.NETで画面も書きたい → Web Forms（.NET Framework）が現実的
- 将来の採用・情報量・ライブラリ互換性を重視 → C#中心のスタックが有利
ただし、本記事のテーマは「フォームを.aspxにリネームしても動かない」問題の解消です。迷っている段階でも、まずは正しいWebプロジェクトを作り、Master Pageにナビを置くところまで進めれば、メニュー作成の全体像が掴めます。
まとめ：最短ルートは「土台を揃えてからメニューを作る」
- Windowsフォームを.aspxにリネームしても、ASPXページにはならない
- ASPXで作りたいなら、Web Forms（.NET Framework）のプロジェクトとして作成する
- メニューはMaster Pageに集約し、asp:Menu、Web.sitemap、Bootstrapナビなどから最適な方式を選ぶ
- 既存WinForms資産を活かすなら、UIは作り直し、ロジックは分離して共有するのが現実的
ここまで整えば、「メニューをどう作るか」だけでなく、「Webとして保守しやすい構成とは何か」まで一気に理解が進みます。まずはテンプレートで動くものを作り、Master Pageのナビを自分のページ構成に置き換えるところから始めてみてください。
コメント