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に公開されている。移植はものすごくまじめに行われている。