ASP.NET Core + .NET 10 技術解説書
.NET Framework 4.8.1 の開発者を対象とした、ASP.NET Core と .NET 10 の解説書です。
章構成
-
1. 入門編:.NET と Visual Studio の進化
.NET Framework 4.8.1 から .NET 8、そして .NET 10 への進化と、Visual Studio 2022 から Visual Studio 2026 への変化を解説します。
-
2. WebAPI編:現代的な API 開発
Minimal API やコントローラーベースの Web API 開発、依存性の注入 (DI) やシリアライズの変更点を解説します。
-
3. MVC編:移行と現代的な Web 開発
ASP.NET MVC 5 から ASP.NET Core MVC への移行パス、タグヘルパーの活用、構成管理の違いを解説します。
入門編:.NET と Visual Studio の進化
.NET Framework 4.8.1 の開発者を対象に、.NET 10 への進化と開発環境の変化を解説します。
.NET Framework 4.8.1 から .NET 8 への進化
.NET Framework から .NET 8 への移行は、開発モデルと実行環境の大きな変革でした。
-
プラットフォームの共通化
.NET Framework は Windows だけで動作していました。.NET 8 は Windows、macOS、Linux で動作するクロスプラットフォームへと生まれ変わりました。これにより、Windows で開発したコードを Linux サーバーで動かすことが可能になりました。
-
不要な機能の廃止と代替技術
ASP.NET Web Forms や WCF (Windows Communication Foundation) などの古い技術は .NET 8 に移植されていません。Web Forms からの移行先としては Razor Pages や Blazor が推奨されます。WCF の代わりには gRPC やコミュニティによって開発されている Core WCF を使用します。
-
依存性の注入 (DI) の標準搭載
.NET Framework では Unity や Autofac などの外部ライブラリを導入して DI を実現していました。.NET 8 では、フレームワーク自体に軽量な DI コンテナーが組み込まれています。
-
スタートアップ処理の統合
Global.asax や Startup.cs は廃止されました。現在は Program.cs の中に初期設定とリクエストの処理経路 (パイプライン) をすべて記述します。
従来の Global.asax や Web.config による設定から、Program.cs によるコードベースの設定に変わりました。
// .NET 8 以降の Program.cs の例
var builder = WebApplication.CreateBuilder(args);
// DI コンテナーにサービスを登録
builder.Services.AddControllers();
var app = builder.Build();
// ミドルウェアパイプラインの設定
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();
app.Run();
.NET 8 から .NET 10 への進化
.NET 8 から最新の .NET 10 にかけて、さらなる高速化と開発効率の向上が図られました。
-
C# 言語の進化 (C# 12 から C# 14)
クラスの宣言と同時にコンストラクターを定義できる「プライマリコンストラクター」や、配列やリストを簡単に記述できる「コレクション式」が導入されました。これにより、コードの行数が減り、バグが入り込む余地が少なくなりました。
// C# 12 以降のプライマリコンストラクターの例
public class UserService(IUserRepository repository)
{
public void RegisterUser(string name)
{
repository.Save(name);
}
}
-
Native AOT (Ahead-of-Time) コンパイルの本格導入
従来の .NET アプリケーションは、実行時に中間言語 (IL) を機械語に翻訳していました。Native AOT を使うと、ビルド時に直接機械語の実行ファイルを生成します。これにより、起動速度がミリ秒単位になり、使用するメモリ容量も極めて小さくなります。コンテナ環境やサーバーレス環境での実行に最適です。
-
AI 機能のネイティブ統合
.NET 10 では、AI モデルと連携するための標準 API が組み込まれました。外部の AI サービスや、ローカルで動作する小規模言語モデル (SLM) を使ったチャット機能などを、統一されたコードで簡単に呼び出せます。
Visual Studio 2022 から Visual Studio 2026 への進化
開発ツールである Visual Studio も、2022 から 2026 へと大幅に進化しました。
-
GitHub Copilot の深い統合
Visual Studio 2026 では、AI アシスタントである GitHub Copilot が開発環境の一部としてネイティブに動作します。コメントからコードを生成するだけでなく、デバッグ中に発生したエラーの原因を AI が分析し、ワンクリックで修正コードを適用してくれます。
-
診断ツールとプロファイラーの強化
非同期処理 (async/await) の実行状態をグラフィカルに可視化する機能が向上しました。どのタスクが処理待ちになっているかを一目で特定できます。また、メモリリークを自動で検出するスマート分析機能も追加されました。
-
ホットリロードの適用範囲拡大
プログラムを動かしたままコードを修正して反映する「ホットリロード」の成功率が向上しました。ジェネリック型の変更やラムダ式の書き換えなど、これまでプログラムの再起動が必要だった多くのコード変更が、実行したまま即座に反映されるようになりました。
WebAPI編:現代的な API 開発
ASP.NET Core における Web API 開発の基本と、.NET Framework 時代からの移行ポイントを解説します。
従来の Web API と ASP.NET Core Web API の違い
.NET Framework 4.8.1 では、HTML 画面を返す ASP.NET MVC と、JSON などを返す ASP.NET Web API 2 は異なる仕組みで動いていました。継承するベースクラスや、ルーティングの仕組みも別々でした。
ASP.NET Core では、これらが統合されました。画面を返す場合も API を提供する場合も、同じコントローラーの仕組みを使用します。これにより、コードの共通化やテストが非常に簡単になりました。
また、IIS (Internet Information Services) への依存がなくなり、Kestrel という軽量で超高速な Web サーバーが内蔵されました。
コントローラーベース API と Minimal API
ASP.NET Core では、Web API を作成する方法として「コントローラーベース」と「Minimal API」の 2 つから選択できます。
-
コントローラーベース API
従来の開発スタイルに近く、コントローラークラスを作成してその中にアクションメソッドを記述します。機能ごとにファイルを分割しやすいため、大規模な開発に適しています。
-
Minimal API
Program.cs の中に直接ルートと処理を記述する、非常にシンプルな開発スタイルです。クラスの定義やコントローラーのセットアップといった余分なコードが必要ありません。
// Minimal API の記述例 (.NET 10)
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/hello", () => "Hello, World!");
app.Run();
少ない行数で動作し、実行速度もコントローラーベースより高速です。小規模なサービスやマイクロサービスに向いています。
依存性の注入 (DI) とミドルウェアパイプライン
ASP.NET Core の Web API は、DI (依存性の注入) とミドルウェアという 2 つの概念で成り立っています。
-
依存性の注入 (DI)
オブジェクトの生成と依存関係の解決をフレームワークが自動で行う仕組みです。サービスの有効期間には以下の 3 つがあり、用途に応じて登録します。
- Transient: 要求されるたびに新しいインスタンスを作成します。
- Scoped: 1 回の HTTP リクエストの間、同じインスタンスを使い回します。
- Singleton: アプリケーションが起動してから終了するまで、単一のインスタンスを使い回します。
-
ミドルウェアパイプライン
HTTP リクエストが届いてからレスポンスを返すまでに実行される処理の鎖 (チェーン) です。認証、ログ記録、例外処理などの機能を、呼び出したい順番に並べて設定します。
シリアライズとエラーハンドリング
データのやり取りやエラーの返し方も、現代的な標準仕様に合わせて洗練されました。
-
System.Text.Json による高速な JSON 処理
.NET Framework でよく使われていた Newtonsoft.Json に代わり、標準の System.Text.Json が使われます。メモリ消費量が非常に少なく、動作が高速です。
-
RFC 7807 (Problem Details) による統一的なエラー応答
API でエラーが発生した際、エラー内容を標準的な形式でクライアントに返します。ステータスコードやエラーの詳細情報が一貫した JSON フォーマットで出力されるため、クライアント側でのエラー処理が容易になります。
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.4",
"title": "Not Found",
"status": 404,
"detail": "指定されたユーザーが見つかりませんでした。"
}
MVC編:移行と現代的な Web 開発
ASP.NET Core MVC による Web アプリケーション開発と、従来の ASP.NET MVC 5 からの移行方法を解説します。
ASP.NET MVC 5 から ASP.NET Core MVC への移行
.NET Framework 4.8.1 上の ASP.NET MVC 5 アプリケーションを ASP.NET Core MVC へ移行する際、いくつかの重要な違いがあります。
-
Global.asax の廃止
アプリケーション起動時の処理などを行っていた Global.asax は廃止されました。これらの初期化処理はすべて Program.cs に記述します。
-
ルーティング設定の統合
RouteConfig.cs にルーティングを記述する代わりに、Program.cs の中で
MapControllerRouteを使用して設定します。または、コントローラーのクラスやメソッドに直接[Route("...")]属性を付与する「属性ルーティング」も広く使われます。 -
コントローラーの基本クラス
System.Web.Mvc.ControllerからMicrosoft.AspNetCore.Mvc.Controllerへと変更されました。メソッドが返す結果の型も、ActionResultからIActionResultインターフェースへと統一されています。
タグヘルパーとビュー開発の進化
画面を作成する Razor ビューでは、従来の HTML ヘルパーに代わり、「タグヘルパー」という仕組みが導入されました。
-
HTML ヘルパー (従来)
C# のコードに近い書き方をしていました。
@Html.LabelFor(m => m.UserName)
@Html.TextBoxFor(m => m.UserName, new { @class = "form-control" })
-
タグヘルパー (現代)
HTML タグの属性として記述できるため、デザイン崩れが起きにくく、デザイナーにとっても読み書きしやすいのが特徴です。
<label asp-for="UserName"></label>
<input asp-for="UserName" class="form-control" />
標準で多くの便利なタグヘルパーが用意されているほか、開発者が独自のカスタムタグヘルパーを作成することも可能です。
状態管理とセキュリティの変更
セッションの管理やセキュリティ対策の記述方法も変更されました。
-
セッション状態の利用
ASP.NET Core では、セッション機能は標準で無効になっています。利用するには、Program.cs でセッションのサービスを明示的に登録し、ミドルウェアを有効にする必要があります。また、分散キャッシュ(Redis など)を使ったスケールアウトが容易になりました。
-
認証と認可の統合
以前の Forms 認証は廃止され、Cookie 認証や ASP.NET Core Identity という統合されたセキュリティシステムが使われます。ロールやクレーム(ユーザーの属性情報)に基づいた細やかなアクセス制御が可能です。
-
セキュリティ対策
CSRF (クロスサイトリクエストフォージェリ) 対策として、タグヘルパーを使用するだけで自動的に検証用トークンがフォームに埋め込まれます。コントローラー側で
[ValidateAntiForgeryToken]属性を付与することで、安全なリクエスト処理が行えます。
構成管理と環境設定
設定ファイルの扱い方が web.config から appsettings.json に変わりました。
-
JSON 形式への移行と階層構造
設定情報は XML 形式の web.config ではなく、JSON 形式の appsettings.json に記述します。値の階層構造を表現しやすくなりました。
-
型安全な設定の読み込み
設定値を C# のクラス(POCO)に自動的に割り当てる「オプションパターン」が標準でサポートされています。DI を介して、型安全に設定値を取り出すことができます。
-
シークレット情報の管理
開発用のデータベース接続文字列などの機密情報は、プロジェクトファイルの外にある「ユーザーシークレット (User Secrets)」に保存します。これにより、誤って機密情報を Git 等のソースコード管理に登録してしまうリスクを防げます。