Skip to content

MS_ASPNETModernization

nishi_74322014 edited this page Aug 21, 2026 · 1 revision

ASP.NET の Modernization

概要

以下を行なうことで Modernization が可能と考える。

  • NuGet 化

  • OWIN

  • RouteConfig

  • BundleConfig

  • 個別 の Modernization

    • ASP.NET Web Forms の Modernization
    • ASP.NET MVC の Modernization

補足(本ページの位置づけ): ここで言う Modernization は
**「.NET Framework 版 ASP.NET のまま、中身を今風にする」**という
段階的な近代化を指す。
ASP.NET Coreへの移行(作り直し)とは別の道である。

【選択肢】
  ① 現状維持              … 何もしない(塩漬け)
  ② Modernization         ← 本ページ。ASP.NET のまま近代化
  ③ ASP.NET Core へ移行   … [ASP.NET Coreへの移行](MS_MigrationToASPNETCore)
  ④ 作り直し              … 全面刷新

② の意義は、

  • ③ の前段として、依存関係を整理しておける
    (NuGet 化・OWIN 化は、そのまま移行の準備になる)
  • ③ に踏み切れない事情(工数、要員、Web Forms 資産)がある場合の現実解

という点にある。
特に OWIN 化は ASP.NET Core のミドルウェア モデルと同じ考え方であり、
③ への地ならしとして効果が大きい。

NuGet 化

NuGet に登録されているライブラリについては、その取得方法を NuGet 化する。

NuGet について

コチラを参照。

NuGet の操作手順

コチラを参照。

既存ライブラリの NuGet 化

既存の参照設定して NuGet から取得したものを参照するようにする。

  • 参照設定を削除する。
  • PM> Install-Package XXXXX コマンドにより、パッケージをインストールして参照設定を追加する。
  • Git からは、packages フォルダを削除できる
    (ビルド時に packages.config の内容に従って復元されるため)。

既存 JS、CSS ファイル等の NuGet 化

既存のファイルを削除して NuGet から取得したものを参照するようにする。

  • 既存のファイルを削除する。
  • PM> Install-Package XXXXX コマンドにより、パッケージ(JS、CSS ファイル等)を取得する。
  • JS、CSS ファイルの参照方法を変更する(後述のBundleConfigを使用すると良い)。
  • Git には Content, fonts, Scripts フォルダを含める。
    • ビルド時に packages.config の内容に従って packages フォルダは復元されるが、
      Script や Content フォルダは復元されないため。
    • Script や Content フォルダを復元する場合、
      Visual Studio のパッケージ・マネージャコンソールから、Update-Package を行なう。

補足(JS/CSS を NuGet で配るのは現在は非推奨): 原文の手順は
packages.config 方式の content\ フォルダ機能に依存している。
この機能は、

という 2 つの理由で、現在は使われない。

時期 JS/CSS の取得方法
本ページの時代 NuGetInstall-Package jQuery 等)
中間期 Bower(Visual Studio 2015〜。廃止済み
現在 npm / libman(Library Manager) / CDN

**libman(LibraryManager)**は、
Visual Studio 2017 15.8 以降に標準搭載された軽量な取得ツールで、
npm ほど大掛かりにせず、CDN からファイルだけ取ってくる用途に向く。

// libman.json
{
  "defaultProvider": "cdnjs",
  "libraries": [
    { "library": "jquery@3.7.1", "destination": "wwwroot/lib/jquery/" },
    { "library": "bootstrap@5.3.3", "destination": "wwwroot/lib/bootstrap/" }
  ]
}

既存の ASP.NET を近代化する場合でも、
JS/CSS は NuGet から libman か npm へ移す方が、
後々の ASP.NET Coreへの移行 が楽になる。

既存ライブラリや、JS、CSS ファイルの一括更新

以下の手順で、ライブラリや、JS、CSS ファイルを更新可能。

  • packages.config を最新のものに書き換える。

  • 一度、packages フォルダ、Content, fonts, Scripts フォルダを削除する。

  • ソリューションをリビルドすると、

    • packages フォルダが復元される。
    • Content, fonts, Scripts フォルダは復元されない。
  • 以下のように必要なパッケージに対して、Update-Package を行う。
    (全てのパッケージに対して機械的に Update-Package を行っても良い。)

    • Content, fonts, Scripts フォルダを持つパッケージ
      • Content, fonts, Scripts フォルダを持つパッケージを特定する。
        復元した packages フォルダを調べると、
        Content, fonts, Scripts フォルダを持つパッケージを特定できる。
      • Content, fonts, Scripts フォルダを持つパッケージに対して Update-Package を行う。
    • その他、Update したいパッケージ
      必要に応じて、その他のパッケージに対しても、Update-Package を行う。

移行メモ(誤記): 原文の「パッケージの特定する。」は
**「パッケージを特定する。」**の助詞の誤りと判断し修正した。

最新のテンプレート実装を参考にパッケージをインストール

新しいバージョンでサポートされた機能に必要なパッケージなどを、
新しいテンプレートの packages.config 等から読み取って、
必要に応じて、Install-Package によってパッケージをインストールする。

HttpClientなど、BCL 入りした、ものの差替など。

<package id="Microsoft.Net.Http.ja" version="2.0.20710.0" targetFramework="net46" />
  • ↓に差し替える。
<package id="System.Net.Http" version="4.3.0" targetFramework="net46" />
<package id="System.Net.Http.Formatting.Extension" version="5.2.3.0" targetFramework="net46" />
  • Nuget の場合、以下でインストールできる。
Install-Package System.Net.Http
Install-Package System.Net.Http.Formatting.Extension

補足(System.Net.Http は入れない方がよい場合が多い): 皮肉なことに、
この差し替えは別の問題を招きやすい

net472 以降では System.Net.Http は BCL に含まれるため、
NuGet 版を入れると
「which has a higher version」
MSB3247版衝突が起きる。

ターゲット System.Net.Http の扱い
net45〜net461 NuGet 版が必要な場合がある
net472 以降 BCL 版を使う(NuGet 版は入れない)
.NET Core / .NET ランタイムに含まれる(常に不要)

近代化のついでにターゲット フレームワークを net48 に上げ、
System.* の分割パッケージを外す
のが、現在の正しい方向である
.NETバージョンアップ)。

OWIN

補足(OWIN 化の戦略的な意味): 数ある近代化項目の中で、
OWIN 化が最も後々効く

【System.Web に密結合した ASP.NET】
   HttpContext.Current に依存 → IIS 前提 → 移行が困難

【OWIN 化した ASP.NET】
   Startup.cs で app.Use(...) を並べる
     → ASP.NET Core のミドルウェアと同じ考え方
     → 認証(Katana の Cookie/OAuth ミドルウェア)が
       ASP.NET Core とほぼ同じ API になる
     → 移行時にコードの多くが流用できる

実際、ASP.NET Core のミドルウェア パイプラインは
OWIN の設計思想をそのまま発展させたもの
である。

ただし、OWIN(Katana)自体は既にメンテナンスされていないため、
「OWIN 化 → そこで止まる」のではなく
**「OWIN 化を経て ASP.NET Core へ」**という道筋で捉えるのが妥当である。

が対象となる。

  • ここでは、以下の様なウェブサイトや Web アプリケーションを作成する
    フロントエンド Web アプリケーションフレームワークのファイル群を

する。

する。

Bundle & Minification

Bootstrap

  • HTML 及び CSS ベースのデザインテンプレートとして用意されている。

    • タイポグラフィ
    • フォーム
    • ボタン
    • ナビゲーション
    • その他構成要素
    • JavaScript 用拡張
    • , etc.
  • インストール方法

Install-Package Bootstrap 

jQuery

  • jQuery
    • ウェブブラウザ用の JavaScript コードをより容易に記述
      できるようにするために設計された軽量な JavaScript ライブラリ
    • インストール方法
Install-Package jQuery
  • jQuery UI
    Bootstrap と競合する。Bootstrap を優先する場合、インストールしない。
    • インタラクティブな Web サイトを開発するために使用される、
      jQuery をベースにした JavaScript のライブラリ
    • インストール方法
Install-Package jQuery.UI.Combined

modernizr

ブラウザの機能サポート状況をチェックし、
HTML タグにサポート状況を判別できるクラスを付与、
結果を記録した modernizr グローバルオブジェクトを生成する。

  • インストール方法
Install-Package Modernizr

Respond.js

IE8 以下でレスポンシブ Web デザインを実現する。

  • インストール方法
Install-Package Respond

補足(この節のライブラリ選定は見直しが要る/最新化): 本節は
IE8 が現役だった時代の構成である。現在の状況を補っておく。

ライブラリ 現況
Bootstrap 現役(5.x)。ただし jQuery 依存を廃止(Bootstrap 5)
jQuery 現役(3.x)だが、新規では不要なことが多い
jQuery UI 開発終了(2021 に最終版。非推奨)
modernizr 役目を終えた(対象ブラウザが機能を全部持っている)
Respond.js 不要(IE8 対応のため。IE 自体がサポート終了)

IE は 2022 年 6 月にサポート終了しており、
Respond.js / modernizr を近代化の名目で導入する意味は無い。
むしろ外すのが近代化である。

また、Bundle & Minification(System.Web.Optimization)自体も、
フロントエンドのビルド ツール(Vite / webpack / esbuild)に
置き換わっている。

時期 手段
本ページの時代 System.Web.Optimization(BundleConfig.cs)
ASP.NET Core 初期 BundlerMinifier(bundleconfig.json廃止済み
現在 npm ベースのバンドラー(Vite / esbuild) or CDN

ASP.NET Core には asp-append-version(キャッシュ バスティング)や
<environment> タグ ヘルパー(開発/本番の切り替え)が用意されており、
「バンドルはフロント側のツールに任せ、
配信とバージョニングだけ ASP.NET Core が面倒を見る」
という分担になっている。

CDNフォールバック

機能概要

  • 著名なフロントエンド Web アプリケーションフレームワークのファイル群は
    CDN から配布されている。
  • これらのファイル群を Bundle & Minification する場合、
    同時に、CDN フォールバックの設定をすることができる。

設定の仕方

  • ScriptBundle、または StyleBundle コンストラクターの第 2 引数に、
    CDNの URL を追加
  • CdnFallbackExpression プロパティに、
    ライブラリがロードできたかどうかを判定するための式を指定する。

設定の例

  • ScriptBundle の場合
ScriptBundle jquery = new ScriptBundle(
                     "~/bundles/jquery",
                     "http://ajax.aspnetcdnn.com/ajax/jQuery/jquery-2.0.0.min.js")
                         .Include("~/Scripts/jquery-{version}.js");
jquery.CdnFallbackExpression = "window.jQuery";
bundles.Add(jquery);
  • StyleBundle の場合
    インターフェイス上は ScriptBundle と同じように設定可能だが、
    現バージョンでは設定不可能なもよう。

  • 参考

補足(CDN 利用は現在は慎重に): 公開 CDN から
ライブラリを読み込む構成は、現在は推奨されないことが多い

理由 内容
キャッシュ共有の効果が消えた ブラウザがオリジンごとにキャッシュを分離(2020 頃〜)
サプライ チェーン リスク CDN が改竄されると全利用者に影響
可用性 CDN 障害・遮断(社内網、特定国)で壊れる
プライバシー 第三者に IP・Referer が渡る

「他サイトで既にキャッシュ済みだから速い」というかつての最大の利点は、
ブラウザ側の仕様変更で失われている

CDN を使う場合は SRI(Subresource Integrity)を必ず付ける

<script src="https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js"
        integrity="sha256-/JqT3SQfawRcv/BIHPThkBvs0OEvtFFmqPF/lYI/Cxo="
        crossorigin="anonymous"></script>

ASP.NET Core では asp-fallback-* タグ ヘルパー
本節のフォールバックに相当する機能を提供する。

<script src="https://cdn.../jquery.min.js"
        asp-fallback-src="~/lib/jquery/jquery.min.js"
        asp-fallback-test="window.jQuery"
        integrity="sha256-..." crossorigin="anonymous"></script>

原文の「StyleBundle では設定不可能」という観測については、
ASP.NET Core のタグ ヘルパーでは
asp-fallback-test-class / -property / -value により
CSS でもフォールバック判定ができるようになっている。

リンクのさせ方

ヘッダでリンク

  • CSS ファイルはヘッダでリンクする。
  • JS ファイルもヘッダでリンクする。
    • modernizr など、初期処理に必要なもの。
    • ・・・

フッタでリンク

それ以外の JS ファイルはフッタでリンクする。

補足(現在は defer を使う): 「フッタに置く」という手法は、
defer 属性で置き換えられる

<!-- head に置いても、HTML 解析をブロックせず、解析完了後に順番通り実行される -->
<script src="app.js" defer></script>

<!-- 順序を問わない独立したスクリプトなら async -->
<script src="analytics.js" async></script>
手法 特徴
フッタに配置 古典的。HTML の構造とスクリプトの位置が離れる
defer head に書ける。順序が保証される(推奨)
async ダウンロード完了順に実行(順序不定)
type="module" 既定で defer 相当

defer を使えば head にまとめて書けるため、
「どこに置くか」を意識する必要がなくなる。

個別 の Modernization

以下を参照。

その他

Web サービス開発へ対応するASP.NET Core

Visual Studio、ASP.NET(特に Web Forms)は、
エンタープライズ向けであったこともあり、
Web サービス隆盛の時代の流れに乗り遅れた感はある。

Web サービス

このため、現在は、Web サービスの分野に適合したフレームワークをリリースしている。

Linux プラットフォーム

また、Web サービスの分野で多用される Linux プラットフォーム上で
動作する OSS のランタイムの提供を開始している。

補足(この節の見立ての、その後): 原文の分析
(エンタープライズ寄りで Web サービスの流れに乗り遅れた)は
妥当な整理である。その後の展開を補っておく。

【原文の時点】
   ASP.NET MVC / Web Pages で追いつこうとしている段階

【現在】
   ・ASP.NET Core が Linux / コンテナで一級市民に
   ・TechEmpower 等のベンチマークで最上位群の性能
   ・最小 API / gRPC / SignalR で「Web サービス」用途を網羅
   ・Web Pages は事実上終息(Razor Pages が後継的位置づけ)

一方で、Web Forms には後継が用意されなかった
.NET 6への移行)。
Web Forms 資産を抱える場合、

  • ② Modernization で延命する(本ページ)
  • Blazor へ作り直す(コンポーネント指向で発想が近い)
  • Razor Pages / MVC へ作り直す

のいずれかを選ぶことになる。

参考

Bundle & Minification

CDNフォールバック

Microsoft Learn


Tags: 移行, .NET開発, ASP.NET, ASP.NET Web Forms, OWIN, NuGet

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

(未着手)

開発基盤部会 Wiki

移行管理: DONETODO

Clone this wiki locally