Microsoft de:code 2019に参加した内容を紹介します。
もし間違いなどあれば、ご指摘いただけますと助かります。
...正直ついていけているか怪しかったので、誤解して聞いている可能性は高いので遠慮なく...!
ビデオが公開されたらそちらを確認された方がよろしいかと思います。
とりあえず、サンプルコードと解説を見てみるのがおすすめです！
[CM12] .NET Core マルチ プラットフォームの本質 / 2019年5月30日
TL;DR（要約）
- Core CLRもGitHubにリポジトリを出しているが、この中のmdファイルが、一番大事なドキュメントとなる。
- クロスプラットフォームのために、Bait And Switchが実装されている。
- .NET Frameworkが廃止される。クライアントサイドは、.NET Coreでも.NET Frameworkでも関係ない。サーバーで機会があれば、.NET Coreとすればよいのではないか。新規案件があれば、.NET Coreで実装するという考え方でよい。
リソース
内容について
始めに断っておくが、こんなセッションに来られる方は物好きなかた！
CLIの基礎知識
ライブラリを作るための規格
JISで決まっており、オンラインから参照することができる。
資料の1-6に乗っている内容で重要なのは
- 共通型システム（CTS）
- 共通言語仕様（CLS、相互運用）
.NETで、CLSに相当するものが.NET Standard
これは、標準規格なので、実装は何もない
メタデータ
メタデータとは何なのか？
PEに対応する リトルエンディアン
色々な言語ができた中で、CLSが一番大事である。
【デモ】
windbg wpfapp.exe
Core CLRに設定している。サウンドストライクを読み込むのに、loadbyというコマンドを呼んだのは、core clrを読み込んだ後に呼ぶ必要があるから
デバッガー拡張が読み取れたので、ブレークポイントを設定した。
DumpDomain
.NET Frameworkの場合には、デフォルトでアプリケーションドメインが3つ
Core CLRの場合には、2.0になってから、UpDomainクラスというのが再定義された。
もともとCLIが呼ばれているのことからわかるように、Applicaton Domainごと。
プログラマーにApplication Domainクラスを開放しているかどうかが.1.0と2.0の違いとなる。
VESの仕組みを考えてみる
クラス単位にメンバーをディスパッチしているものが呼ばれる。
初回にはJITが呼ばれていない。JITが呼ばれてポインタが作られる。
2回目以降はネイティブコードがあるのでそれを使って実行される。
DumpLEというコマンドを見れば、どちらかがわかる
標準規格とは？
標準規格が定義しているのは、INとOUTが規格通りであればよい、というもの。
.NET CoreとTarget Framework
共通型システム
既定の型はすべてSystem.Object。
BCLの互換性
NET Core 2.0になった時に、Core CLRに移った。
BCL（Base Class Library）
GitHubに公開されている重要なドキュメント
Core CLRもGitHubにリポジトリを出しているが、この中のmdファイルが、一番大事なドキュメントとなる。
mdファイルに記載されている内容が大事！
1.0から2.0に移る際にチェックインされたドキュメント。Common Language Runtimeを作成するときに作られたドキュメント。
なぜMscorlibが特別なのかということが書いている。
GCの仕組みを知ろう
GCというのは、メモリ上のものを回収している。実行エンジンというものは型が何かを知らないといけない。System.ObjectやGCが何をするかを知らないといけない。
Managed 実行と UnManaged実行のコストの問題上、QコールとFコールが用意されている
Qコールは直接呼ぶものであり、Fコールはメソッドテーブル
ILSpyを実行して確認する
Qコールは、初期化する際にマウントされた実態であり呼び出されたもののオーバーヘッドを限りなく小さくしている。なので、MSCorlibはとくべつなObjectである。
メタパッケージ
【デモ】型を参照するとは？
型を参照するとは、どういうことを示しているのか？そこで、メタデータが実際にどのように見えるのか、ということを見せましょう
- string heapを見てから必要なものを探す
- メンバーはメンバーリファレンステーブル。
- シグネチャは、戻り値などを符号化したバイナリの値。引数の型が変われば符号も変わるなので、オーバーロード
- 今は、C#は戻り値のオーバーロードは許可されていないので、うまくいく
- 型を参照するのは、AssemblyIdentiry以外は、名前と値で区別している
メタデータを見るのは慣れないと結構見るのはつらい
Bait And Switch
Nugetが基本となっている
単純に言うと、コンパイルするときに見に行くアセンブルと発行するときのデプロイ用のアセンブリが違う。
実装するときのアセンブルとコンパイルするときのアセンブリが違ってもよい、という考え方となる。
なぜこういう仕組みを実装しているのか？
クロスプラットフォームのため。
コンパイルするものと、実際に動くものを差し替えてみる（メタデータの特徴を活用したテクニック）。それでも動作する。
要は、名前とシグネチャが一致していたらなんら問題ない（実行時の仕組み上も、実行エンジンはエラーを出力しない）という仕組みは、こういうところに支えられている
メタデータを支える技術
自分でNugetを作るときに、自分がどのランタイムをサポートするかということを考えないといけない。
今は、.NET Standardというものがある。共通のAPIセットがあるわけなので、これに沿っている限りは、考えなくてもよい。
相対的に、.NET Standard Library 2.0ができたことで、あまり考えなくてもよくなった。
アプリの展開方法
ASP.NET はFDDである。.NET Coreで作成した場合も、FDDというところは変わらない。
.NET vNext
.NET のサポートライフサイクルが短い
セキュリティ事故が見つかった時にどうするか。毎年毎年リコンパイルが必要だ、という考えのほうがよい。展開の問題はあるが、サポートライルサイクルは、それぐらい短くなっている。
.NET 5では、1フレームワークに集約
wCF
- Web APIへ移行
WF
- OSSで実装する。
Web Forms
- ASP.NET MVCへ移行。これはViewとしてBlazorを利用するということ。仕組みの基本にあるのは、ASP.NET MVC
Remoting
- RESTやgRPCへ移行
AppDomain マルチホスティング
新井さんの考え方
.NET FrameworkでのC#はどうなるのか。バージョンが上がっても、サポートされる。言語、ライブラリではない、コンパイラが解決する。Roslynが解決する
まとめ
- 実装に互換性はない。
- Microsoftとしては、.NET 5に一本化する
- .NET Frameworkは4.8で開発終了、サポートはずっとされ続けるので、OSの1コンポーネントに過ぎないので、サーバーサイドとしても問題がない
- クライアントサイドは、.NET Coreでも.NET Frameworkでも関係ない
- サーバーで機会があれば、.NET Coreとすればよいのではないか
- 新規案件があれば、.NET Coreで実装する
Appendix
- JISについては、日本からでないと見れないようになっている
最後に
.NET Coreでちゃんと開発しようと思ったら、どういう風に実行されているかをわかったほうが望ましい。すべてGitHubに公開されている。移植はものすごくまじめに行われている。