MS_DotNetCrossPlatform - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

.NETのクロスプラットフォーム対応

概要

  • 以前は、PCLのレベルのクロスプラットフォーム対応しか無かったが、
    .NET Coreの登場により、状況は大きく変わった。

  • マイクロソフトは、あらゆる環境に対応する開発ツール群を提供しようとしている。

    • Any Developer（どんな開発者にも）
    • Any App（どんなアプリケーションにも）
    • Any Platform（どんなプラットフォームにも）

    この中の、Any Platform に対応するのが、.NET Core。

俯瞰図

とりあえず雰囲気を掴むための最新の図。

.NETのクロスプラットフォーム対応

参考

  • 【特別企画】Windowsにこだわらない、サティア・ナデラのMicrosoft - クラウド Watch
    https://cloud.watch.impress.co.jp/docs/special/678748.html

    • .NET はマルチプラットフォーム化される

      こういった変化に対応し、さらに Microsoft 独自のテクノロジーを
      生かしていくためには、.NET Framework をスタンダードにして、
      マルチプラットフォームで動作できるようにしていく必要があるのだと思われる。

  • 「好みのデバイスで好みの開発言語を」--新しいVisual Studioの世界 - ZDNet Japan
    https://japan.zdnet.com/article/35092575/

    .NET スタンダードライブラリを構築して、.NET エコシステムの拡大を目指す。

用語

色々用語が出てくるので纏める。

CLI

  • 共通言語基盤（CLI : Common Language Infrastructure）
  • .NET Frameworkの基幹を構成する仕様
    （ECMA-335 および ISO/IEC 23271）
  • CLI は、言語やプラットフォームに依存しない環境を定義しており、
    様々な言語で書いたソースコードを他のプラットフォームでも使える。

移行メモ（紛らわしい略語）: .NET の文脈で CLI は 2 つある。

略語 意味
CLI Common Language Infrastructure（本節の意味。ECMA-335）
CLI Command Line Interface（dotnet コマンドの意味。.NET CLI）

現在の文書で「.NET CLI」と書かれていれば、ほぼ後者（dotnet コマンド）である。

概念

  • 共通型システム

    • CTS : Common Type System
    • プログラミング言語間で共通して用いられる型の集合

  • メタデータ

    • プログラムの構造に関する情報。
    • プログラミング言語上やツールなどから参照できる。

  • 共通言語仕様

    • CLS : Common Language Specification
    • 相互運用性のためのプログラミング言語に対する規定

  • 仮想実行システム

    • VES : Virtual Execution System
    • CLI に適合したプログラムの読込と実行。
    • メタデータを活用して動的に機械語を生成する。

移行メモ（正誤）: 元ページは VES を
「Virtual Execution Evnironment」としていたが、
ECMA-335 の正しい語は Virtual Execution System である。

参考

.NET Framework

皆さんご存知の .NET Framework。

BCL

  • BCL : Base Class Library（基本クラスライブラリ）
  • 全ての CLI 言語から利用可能な共通言語基盤 (CLI) 標準ライブラリ

FCL

  • FCL : Framework Class Library
  • .NET Framework の BCL の意味で使用される、BCL のスーパーセット
  • CLI で定義されている標準ライブラリの .NET Framework 実装
  • マイクロソフト固有の名前空間を含む

PCL

  • PCL : Portable Class Library
  • PCL の後継は.NET Standard。
  • Microsoft プラットフォーム間でコードを共有できる
    クロスプラットフォーム アプリ・ライブラリを開発可能。

補足（PCL がなぜ廃れたか）: PCL は
「対象プラットフォームの**共通部分（積集合）**だけを使う」という方式だった。
対象を増やすほど使える API が減るという構造的な弱点があり、
プロファイルの組み合わせ爆発（Profile7、Profile111 …）も起きた。

.NET Standardはこれを逆転し、
「バージョン番号で API セットを定め、各実装がそれを満たす」
という方式にした。PCL は現在では非推奨である。

TFM

Target Framework Monikers (TFMs)

.NET Core : netcoreapp

  • Console アプリケーション : .NET Core
  • デスクトップ・アプリケーション : UWP
  • Web アプリケーション : ASP.NET Core

Mono : mono or xamarin

  • monoandroid
  • monotouch
  • monomac
  • xamarinios
  • xamarinmac

※ Xamarin

.NET Standard : netstandard

.NET 実装の動作の統一性を確立、
クロスプラットフォーム対応を推進する。

.NET 5 : net5.0

補足（最新化：TFM は統合された）: .NET 5 以降、
TFM は次のように整理され、netcoreapp / xamarin 系は使われなくなった。

TFM 意味
net8.0 プラットフォーム非依存（Windows / Linux / macOS で動く）
net8.0-windows Windows 専用 API を使う（Windows Forms / WPF / COM）
net8.0-android / net8.0-ios / net8.0-maccatalyst .NET MAUI 等
netstandard2.0 .NET Frameworkとも共有したいライブラリ向け（現役）

つまり「.NET Core / Mono / .NET Framework という
3 系統をどう繋ぐか」という本ページの問題意識は、
.NET 5 でランタイムが 1 本化されたことでほぼ解消した。
.NET Standardの役割も、
「.NET Framework を切れないライブラリ」に限定されつつある。

GUI

補足（GUI だけは統合されなかった）: ランタイムが 1 本化された後も、
GUI のクロスプラットフォーム化は未解決のままである。

選択肢 対象
Windows Forms / WPF Windows のみ
.NET MAUI Android / iOS / macOS / Windows（Linux 非対応）
Uno Platform 上記 + Linux + WebAssembly
Avalonia UI Windows / Linux / macOS + モバイル + WebAssembly（OSS で実績が増えている）
Blazor ブラウザ（＋ Hybrid でデスクトップ）

Linux デスクトップまで含めたい場合、
Microsoft 純正には答えがなく、Avalonia / Uno という
サードパーティ製を選ぶことになる点は押さえておきたい。

移行

アナライザー

Roslyn ベースのアナライザー

.NET API アナライザー

.NET Portability Analyzer

補足（現在の推奨ツール）: .NET Portability Analyzer は
アーカイブされ、後継は .NET Upgrade Assistant となっている。

dotnet tool install -g upgrade-assistant
upgrade-assistant upgrade <プロジェクト>

try-convert（プロジェクト形式の SDK スタイル化）も内包しており、
現在の移行作業ではこちらが起点になる。

Porting Assistant for .NET

補足（AWS が出した理由）: 「何故か」と書かれているが、動機は明確である。
.NET Framework アプリは Windows Server ライセンスを必要とするため、
AWS 上で動かすとコストが高い。
.NET Core化して Linux で動かせれば、
顧客のコストが下がり、AWS の競争力も上がる。
Microsoft にとっては Azure への囲い込みが弱まるため、
クラウド ベンダ間の競争の産物と見るのが正確である。

なお Porting Assistant for .NET も現在は開発が停滞しており、
実務では .NET Upgrade Assistant を使うのが無難である。

アンマネージド

事例

移行性の評価

.NET Core 2.0

.NET Core 3 DesktopPack

.NET 5への移行

移行元

https://github.com/OpenTouryoProject/OpenTouryo/tree/02-20

移行先

https://github.com/OpenTouryoProject/OpenTouryo/tree/SupportNetStandard2%26NetCore2

参考

.NET API Browser

https://learn.microsoft.com/dotnet/api/

  • ターゲット フレームワークを切り替えて、
    API がどの実装で使えるかを確認できる。

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

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

⚠️ **GitHub.com Fallback** ⚠️