Skip to content

MS_MigrationToDotNetStandard

Jump to bottom
nishi_74322014 edited this page Aug 12, 2026 · 1 revision

.NET Standardへの移行

概要

対象は、.NET Standard 2.0。

  • 「移行元 / 移行先」の「.NET Standard」移行ノウハウをサマリする。
  • .NET Standard に書いた通り、PCL と比べて移行はし易い感じ。

移行メモ: 元ページの「※ ただし、.NET Standard は、.NET 6 で廃止予定との事。」は
誤りである（.NET Standard / .NET 6 を参照）。
netstandard2.0 は現在も有効なターゲットであり、本ページの手順も有効。

ただし、移行先の第一候補は現在 net8.0 等の .NET 本体である。
netstandard2.0 を選ぶのは「.NET Framework からも参照させたいライブラリ」
の場合に限る、と読み替えるのがよい。

詳細

準備

  • 移行プロセスの確認

  • 移行性評価の実施 — 必要に応じて、移行性評価ツールを使用し移行性を評価する。

  • 移行先プロジェクトを準備する。 — 不要なファイルを削除する。

    • packages.config
    • Properties\AssemblyInfo.cs

  • Project ファイルを準備する。
    以下のような Project ファイルを準備する（既存の中身を置き換えればイイ）。

    <Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>
</Project>
    • .NET Standardでは、配下の Source ファイルが自動で追加される。
      必要に応じて、ファイルやフォルダの除外設定を行う。
      ※ netstandard や netcore では、除外されるファイルやフォルダだけが
      Project ファイルに明記される。

  • Project を Visual Studio から開く。
    Project ファイルをダブルクリックするか、空のソリューションに追加する。

  • Project の初期設定を行う。

    <PropertyGroup>
  <TargetFramework>netstandard2.0</TargetFramework>
  <AssemblyName>XXXX</AssemblyName>
  <RootNamespace>YYYY</RootNamespace>
</PropertyGroup>

補足（移行の順序）: 現在の推奨手順は次の通り。
いきなり TFM を変えず、先に csproj 形式だけ変えるのが安全である。

  1. SDK スタイル csproj に変換（TFM は net48 のまま）
    → この時点でビルドが通ることを確認する
  2. .NET Upgrade Assistant で依存関係を分析
    dotnet tool install -g upgrade-assistant
  3. TFM を netstandard2.0（または net8.0）に変更
  4. コンパイル エラーを潰す

1 と 3 を同時にやると、どちらが原因のエラーか切り分けられなくなる。

ポーティング移行

  • 移行対象ファイルを選別する。

    • コンパイル・エラーをチェックしながら移行対象ファイルを選別する。
    • クラス・メソッドの有 / 無については、.NET API Browser を使用すると良い。

  • 必要に応じて、NuGet パッケージを追加する。

    • 「参照無し」が発生したら、NuGet パッケージを確認しインストール。
      NuGet パッケージに netstandard が含まれるかどうかを確認する。
    • 以下のライブラリの移行先を NuGet パッケージから探す。
分類 移行先の例
System 系 System.Configuration.ConfigurationManager
System.Data 系 System.Data.SqlClient → Microsoft.Data.SqlClient / System.Data.Odbc / Npgsql / MySql.Data
ASP.NET Core 系 ※ ココが比較的、大変
その他 log4net / Json.NET

  • 参考：.NET Core に移植する - Windows 互換機能パックの使用
    https://learn.microsoft.com/dotnet/core/porting/windows-compat-pack

  • 必要に応じて、ポーティング移行する。
    以下の Platform や Library に依存していた処理を、削除するかポーティング移行する。

    • Windows
    • net11 - net47 - netXX
    • Microsoft.VisualBasic
    • 上記以外の NuGet パッケージ

パッケージ・マネージャ

NuGet

  • 引き続き使用できる。

    • .NET Standard、.NET Coreでも、
      引き続き NuGet を使用できる。
    • 1 つの NuGet パッケージには、.NET Framework 以外に、
      .NET Standard、.NET Core のライブラリを同梱してパッケージ化できる。

  • Dependencies

    • .NET Standard、.NET Core 開発に活用できる NuGet ライブラリは、
      .NET Standard、.NET Core 側にだけ、Dependencies を持つ。

    ※ しかし、実際には、Dependencies が正確に書かれていないケースも多く、
    　（lib\netXXX 毎に Dependencies が異なるので当然と言えば当然）
    　実際にインストールして .NET Standard に対応しているかどうかを判断する。

System系ライブラリ

*.config

.NET Core configを参照。

補足: app.config / web.config の
ConfigurationManager.AppSettings は、
System.Configuration.ConfigurationManager パッケージで一応使えるが、
.NET の作法では appsettings.json ＋ IConfiguration に移す。
環境変数・ユーザー シークレット・Key Vault などを
同じ API で重ねられるのが利点である。

ADO.NET

補足（最新化）: System.Data.DataSetExtensions は
その後 .NET Core 3.0 で利用可能になった（netstandard2.0 でも参照可）。
一方、型付き DataSet（xsd.exe による生成）は今も未対応である。
型付き DataSet を多用した資産は、
Dapper / EF Core への置き換えが必要になりやすい。

その他ライブラリ

log4net

その他

移行元 移行先
DotNetZip System.IO.Compression（標準）
System.Net.Mail MailKit
System.Drawing ImageProcessor → 現在は ImageSharp / SkiaSharp

補足（最新化）: System.Drawing.Common は
.NET 6 で Windows 専用となり（SYSLIB0038）、
.NET 7 以降、非 Windows では実行時に例外になる。
クロスプラットフォームで画像処理を行うなら
ImageSharp / SkiaSharp への移行が必須である。

System.Net.Mail（SmtpClient）も
「新規開発では非推奨」とドキュメントに明記されており、
MailKit が公式に案内されている。

ASP.NET Core系ライブラリ

  • 対応するライブラリが Microsoft.AspNetCore.XXXX にある可能性がある。
  • これらのライブラリは ASP.NET Core ではなく、
    .NET Standard 前提になる。

System.Web

RootPath

# 内容 net netcore, netstandard
1 現在のアプリケーションのルート仮想パス（「/」や「/アプリ名」のような） HttpContext.Current.Request.ApplicationPath HttpContext.Request.PathBase
2 サーバー アプリケーションのルート ディレクトリの物理ファイル システム パス HttpRequest.PhysicalApplicationPath IWebHostEnvironment.ContentRootPath

移行メモ（最新化）: 元ページは 2 の移行先を
IApplicationEnvironment.ApplicationBasePath としていたが、
これは ASP.NET Core 1.0 時代の API で既に存在しない。
現在は IWebHostEnvironment の
ContentRootPath（アプリのルート）/ WebRootPath（wwwroot）を使う
（IHostingEnvironment も .NET Core 3.0 で非推奨になった）。

HttpContext

※ 上記の「Mimicking HttpContext.Current」で .NET Standard な
ライブラリ化も可能。

補足（推奨されるやり方）: HttpContext.Current を模倣する手法は
移行の一時しのぎとしては有効だが、恒久的な設計としては勧められない。

  • 静的アクセスはテストできない（差し替えられない）
  • 非同期処理で AsyncLocal の伝播に依存し、取りこぼしが起きうる
  • 「どこからでも触れる」ため、層の分離が壊れる

正攻法は IHttpContextAccessor を DI で受け取るか、
そもそも下位層に HttpContext を渡さず、
必要な値だけを引数で渡す設計に直すことである。

Session / Cookie

その他

  • System.Web.Routing.RouteTable → Microsoft.AspNetCore.Routing

Microsoft.Owin

対応するライブラリが Microsoft.AspNetCore.XXXX にある可能性がある。

  • Base64Url → Microsoft.AspNetCore.WebUtilities

ASP.NET Core系ミドルウェア

Filters

Microsoft.AspNetCore.Mvc.Filters

  • Filter パイプラインが再実装されて、分かりやすくシンプルになった。

  • ASP.NET MVC 5 と同じように扱える抽象クラスが
    Core MVC でも用意されている。
    （ActionFilterAttribute, ResultFilterAttribute, ExceptionFilterAttribute）

  • Resource Filter により、キャッシュなどパフォーマンスの改善の実装が容易に。

  • ただし、一部にインターフェイスの変更はある（フィルタ・メソッド、属性の引数）

  • また、下記が追加された。

    • 非同期版のメソッドの追加。
    • 属性だけでなく DI と連携した適用が可能になった。

  • 参考

MVC / WebAPI

  • Controller クラス — 上記の Filters の影響により、
    一部のメソッドにインターフェイスの変更がある。

  • WebAPI の Controller クラス — ベースクラスが
    MVC の Controller と統合された。

  • 参考

参考

.NET Standardは .NET Core のサブセットなので、
≒ .NET Core。なので、以下のリンクは .NET Core への移行の情報を含む。

内部リンク

microsoft.com

Tags: 移行, .NET開発, .NET Core, .NET Standard, 移行

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally