.NET Core以降の.NETにおけるクロスプラットフォームを意識したクラスライブラリ開発について概観します。

1. .NET クロスプラットフォーム
BY YASUSHI KATO
2016-8-19

2. .NET Core リリース！ (2016/6/30)
.NET Runtime(CoreCLR)
.NET Execution Environment(旧称DNX)
.NET Core SDK preview
ASP .NET Core 1.0 （旧称ASP .NET 5 vNext）
Entity Framework Core 1.0
Visual Studio 2015 Update 3

3. .NET Core とは
さまざまな環境で動く .NET Framework のニューファミリー
ライブラリが提供する機能は少なめ
アプリケーションフレームワークとして下の2つ：
1. ASP.NET Core……WEBアプリ。Windows, Linux, Mac OS X, Docker で動作。
2. UWPアプリ……GUIアプリ。Windows 10, Windows Mobile 10, Holo Lens, Xbox One で動作。

4. .NET For
WinRT
CoreFx
Windows
Phone
Windows
Store
今回のテーマはクロスプラットフォーム
.NET Core
ASP.NET Core
UWP
PCL
.NET Standard
.NET Native
共有プロジェクト
Xamarin

5. .NET のバリエーション
.NETにおけるプラットフォームとはなにか？

6. プラットフォーム≠アプリフレームワーク
WPF
WinForms
Silverlight
Mono
Xamarin
Unity
Windows
Mobile
Windows
Store App
Windows
PhoneASP .NET
UWP App

7. ASP.NET
相違のあるフレームワークライブラリ
Base Class Library
Mono Class
Library
.CoreFx
(NET Core)
再整理による
追加分
Windows固有
レガシー
リスト処理、
数値計算、
文字列操作など
ウェブ用
ASP1.0の遺産
IIS固有

8. プロファイルでターゲットを規定
Base Class Library/CLR Mono Class Library/Mono ランタイム
UWPWPF
Windows
Store 8.1
ASP.NET
Core
Mono
WinForms
Xamarin.
iOS
プロファイル≒利用してよい標準ライブラリに関する規約
CoreFx/CoreCLR
Xamarin.
Android
.NET
Full 互換
Mono
Touch
Mono
Android
Windows
Store 8.1
.NET Core.NET Full

9. 結局どれが使えるの……？
• System.Collections
• System.Diagnostics（Eventlog 除く）
• System.Numerics
• System.Text
• System.Drawing
• System.Net
• System.Resources
• System.Xml
• System.Reflectons
• System.Threading
• System.Workflow
• AppDomain
• System.IO の File, Directory
• System.ComponentModel
• System.Security
※単に未実装のものもある（XSLTなど）
おおむね使用可
一部削除
一部整理
異なるAPIに置き換え/削除
W3C準拠の
XmlDocument と
MSXMLの
XmlDocument に分離。

10. ここまでのまとめ
一口に .NET といってもさまざま。
整理のための切り口がプロファイル。
プロファイルによって利用できるライブラリ機能が定まる。
ライブラリの基本的な部分はわりとどの環境でも使える。
アプリに近い部分は特定環境下でしか使えない。
Windows API や Microsoft スタック（MSXML, IIS）に由来する部分は Windows でしか使えない。
ファイル、スレッド、ネットワーク、グラフィクスなどは環境（OS）ごとに異なる。

11. ライブラリ化
いかにして移植可能なコードをこしらえるか？

12. ３つのプロジェクトタイプ
1. 共有プロジェクト
2. 移植可能クラスライブラリ（PCL）
3. .NET Standard クラスライブラリ
プラス Visual C++ Mobile も。
Microsoft Office くらいの規模と歴史があると有用。
NEW!

13. 共有プロジェクト
ソースコードレベルの共有
アセンブリを作らない
#if ～ #endif で切り分けが可能
黒魔術的
◦ 参照先にしか定義がないクラスを利用したり
◦ Partial class の一部だけを定義したり
「リンクとして追加」に類似（よりシームレス）

14. 移植可能クラスライブラリ（PCL）
バイナリレベルの共有
アセンブリを作る
ターゲットのプロファイルを複数選択
プロファイル共通のライブラリのみ使える

15. .NET Standard クラスライブラリ
バイナリレベルの共有
アセンブリを作る
ターゲットは将来を含めてすべて（先のPCLも）
コア部分のみの標準ライブラリが使える。

16. Before：プロファイルベースのPCL
.NET 4.6
UWP 10
Windows
Phone
8.1
一枚岩の標準ライブラリが前提。
ターゲット＝プロファイルの和
使用可能なライブラリ＝標準ライブラリの積。
×プロファイルが登場するたびに見直し。

17. After：.NET Standard ベースのPCL
.NET 4.6
UWP 10
Windows
Phone
8.1
各標準ライブラリを分解、整理
→個別のパッケージに。
環境を問わぬ標準ライブラリ＝.NET Standard
ターゲット= .NET Standard
必要なものだけ Nuget で追加。
新しい依存関係モデルと Nuget v3 が前提。

18. .NET Standard をサポートする環境
.NET Core
ASP.NET Core
.NET Framework 4.5+
Windows Phone 8+ （Windows Phone Silverlight も）
Windows Store
UWP
Mono/Xamarin
※Visual Studio 2012 以降の世代に限られる。https://docs.microsoft.com/ja-jp/dotnet/articles/standard/library

19. .NET Standard をサポートしない環境
.NET Framework 4.0 以前（ということは Unity も？）
.NET Compact Framework
現実的には3.5で動いているシステムも多い。
OSの都合でバージョンアップできなかったりも….
結構な足かせ

20. 共有プロジェクトか、PCLか
なるべくPCLにしたい
共有プロジェクトのほうが適当なことも
◦ コードの内部処理のごく一部だけ異なる場合
◦ XAML実装のわずかな違い
◦ Windows Phone のハードウェアバックボタン
◦ SQLite for Windows Store の一時フォルダ設定
◦ プロジェクト横断的な違いが多数ある場合
◦ Roslyn は半数くらいが共有プロジェクト！
◦ 依存ライブラリの都合
◦ PCL化がなされていない
◦ すでに別々の道を進んでいる
◦ Mvvm Light, Prism（MVVMライブラリは MVVM Cross のみ）
◦ Entity Framework
ラッパーPCLを作ってまとめる策もある
（bait and switch 技法）

21. 余談：.NET for WinRT とユニットテスト
WinRT ではユニットテスト環境が実用に耐えない。
DIを前提とした設計ではモックも必須だが：
1. 似て非なる貧弱な MSTest
 最新で .NET Core 対応したが、WinRT は放置の模様。
2. Mock フレームワークがない
 リフレクションの制限ゆえに解決の見込みなし。
 Fake Framework → VS Ultimate が必要（そもそもMSのプロジェクトが Moq 使っていたりする）
テストのためのPCL化（再利用性より優先）
DIの重要性がピンと来ない人は
『C#実践開発手法』を。
ちなみに NUnit はいまだにこの状況。
xUnit.net が .NET Core 対応済み。

22. まとめ
これからの.NETとどうつきあっていけばいいのか

23. マルチプラットフォームの時代へ
Windows Runtime から4年、ようやく .NET Core がリリース。
各種のライブラリも実用レベルになってきた。
.NET Core の将来はまだ不透明。
プラットフォームの垣根をなくす方向に行くのは間違いない。

24. そのコード、どこで動きますか？
PCL化、共有プロジェクト化はそれほど難しくない。
まず、ライブラリの標準を知る。
自分のコードがどのプラットフォームで動くのか、認識を。
少なくとも移植を意識した構造を
System.Web と System.Workflow がアプリ独自データの解析と一緒のプロジェクトとかNG!

25. Appendix

26. 既存コードの移植性を検査する
.NET Portability Analyzer がやってくれます。
下のリンクを参照のこと。
https://docs.microsoft.com/ja-jp/dotnet/articles/standard/portability-analyzer

27. ASP.NET から ASP.NET Core への移行
Web API + SPAは難しくない。
MVC + OWIN もモダンな設計ならだいたい同じ。
• ただし、認証は置き換え（→ASP.NET Identity）。
• View を作り込んでいると大変そう（Tag Helper などに違い）。
• その他、細かい違い（MVCとWeb APIの統合による影響）。
IIS依存(using System.Web)は代わりがないことも。
Web Forms は作り直し一択。

28. .NET Standardスペックシート
https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-
standard.md
CoreFXのドキュメントの一部。
バージョンの対応表やサポートしているクラスの一覧などが掲載されている。
※バージョンはMSDNにも記載があるが、こちらがマスターと思われる。