• 戻る（ASP.NET）

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

• NuGet 化

• OWIN化

• RouteConfig

• BundleConfig

  • Bundle & Minification
  • CDN フォールバック
  • 画面からのリンクを設定

• 個別 の 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 から取得したものを参照するようにする。

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

既存のファイルを削除して 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\ フォルダ機能に依存している。
この機能は、

• PackageReference 方式では動かない
  （NuGet を使用したパッケージ管理）
• フロントエンドの世界では npm が標準になった

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

時期	JS/CSS の取得方法
本ページの時代	NuGet（Install-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": "[email protected]", "destination": "wwwroot/lib/jquery/" },
    { "library": "[email protected]", "destination": "wwwroot/lib/bootstrap/" }
  ]
}

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

以下の手順で、ライブラリや、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 によってパッケージをインストールする。

<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 化が最も後々効く。

【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 へ」**という道筋で捉えるのが妥当である。

• ASP.NET MVC 4 以降には、既定で実装されている。

• Modernization は、

  • ASP.NET Web Forms
  • ASP.NET MVC 4 以前

が対象となる。

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

する。

• その他、個別のファイルについては、
  ASP.NET Web Forms 、 ASP.NET MVC個別で
  • Bundle & Minification
  • CDN フォールバック

する。

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

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

• インストール方法

Install-Package Bootstrap 

• jQuery
  • ウェブブラウザ用の JavaScript コードをより容易に記述
    できるようにするために設計された軽量な JavaScript ライブラリ
  • インストール方法

Install-Package jQuery

• jQuery UI
  Bootstrap と競合する。Bootstrap を優先する場合、インストールしない。
  • インタラクティブな Web サイトを開発するために使用される、
    jQuery をベースにした JavaScript のライブラリ
  • インストール方法

Install-Package jQuery.UI.Combined

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

• インストール方法

Install-Package Modernizr

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 が面倒を見る」
という分担になっている。

• 著名なフロントエンド 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 と同じように設定可能だが、
  現バージョンでは設定不可能なもよう。

• 参考

  • ASP.NET MVC 5 主要 JavaScriptライブラリのCDN、Fallbackまとめ - KatsuYuzuのブログ
    http://katsuyuzu.hatenablog.jp/entry/2014/10/02/000330

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

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

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

CDN を使う場合は SRI（Subresource Integrity）を必ず付ける。

<script src="https://cdn.jsdelivr.net/npm/[email protected]/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 にまとめて書けるため、
「どこに置くか」を意識する必要がなくなる。

以下を参照。

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

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

• ASP.NET MVC
• ASP.NET Web Pages

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

• .NET Standard
• .NET Core
• ASP.NET Core

補足（この節の見立ての、その後）: 原文の分析
（エンタープライズ寄りで 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 へ作り直す

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

• [ASP.NET Optimization] javascript や cssの Bundle と Minification 機能を使ってみる - Netplanetes
  http://www.pine4.net/Memo/Article/Archives/545

• 効果的なフォールバック戦略の作成方法
  https://learn.microsoft.com/ja-jp/previous-versions/aspnet/hh273396(v=vs.100)

• jQuery, jQueryUI, Bootstrap利用時のCDNフォールバック対応　 | auxak blog
  http://blog.auxak.com/cdn-fallback/

• CDNダウン時のjs/cssのフォールバック | odekakeshimasyo.me
  https://odekakeshimasyo.me/web-cdn-fallback.html

• パブリックCDNからのロードに対して、フォールバックを行う - Qiita
  http://qiita.com/jkr_2255/items/6c195a0de5e3ebaf4ac1

• 既存の ASP.NET アプリのアップグレード
  https://learn.microsoft.com/ja-jp/dotnet/architecture/modernize-with-azure-containers/
• ASP.NET Core での静的ファイルのバンドルと縮小
  https://learn.microsoft.com/ja-jp/aspnet/core/client-side/bundling-and-minification
• ASP.NET Core での LibraryManager (LibMan)
  https://learn.microsoft.com/ja-jp/aspnet/core/client-side/libman/

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