.NET Standard とは何か?

list このエントリーをはてなブックマークに追加

.NET Core が 1.0 になってリリースされて、ASP.NET Core MVC が Linux 上で動くようになったと思ったら、今度は .NET Standard ってのが出てきて、え?いきなり、.NET Standard 2.0 ってのは何ですか?ってな感じな人は多いと思いますが(私もそうでして)、ひとまず、.NET Standard とは何なのかを探っていきます。

Introducing .NET Standard | .NET Blog
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

もともと、.NET Core って、Windows に依存する API を切り離してしまって、Linux やら Mac やら動く環境を作るのが目的じゃなかったんですか?と思っていたわけですが、図を見るとちょっと違うようです。

dotnet-today

たぶん、Xamarinを買収した影響(Mono自体を取り込んでしまった影響)が大きいと思うのですが、Linux 上で、何らかの .NET なプログラムを動かそうと思うと、.NET Core なプログラムと mono なプログラムは競合します。上の図では、Xamarin が、iOS/Android に「のみ」依存しているような書き方ですが、実際は Linux 上で動かしているものもあるわけで、Raspberry Pi 上で C# を動かしてツールを作ったり、F# を動かせたりするのはそれです。実運用的に apache と .NET の組み合わせが妥当かどかは別として(LAMPで組むとか、Javaのほうが楽だろうし)、mono を使えば、結構な .net なツールを Linux 上で動かせます。クラスライブラリ自体も大体のところは本家(?)の .NET Framework を網羅しています。まあ、そのあたりが Unity + Mono という組み合わせなわけですが、それとは別なスタイルで .NET Core な環境を Microsoft は独自に始めたわけです。

で、結果的に Xamarin 社と業務提携から買収に至ったわけで、そうなると、上の「Mono Class Library」なところが「Core Library」に置き換わるのかな?と想像するわけじゃないですか。Microsoft 社内としては、Mono と .NET Core のメンテナンスを分散して注力するよりも、.NET Core に統一してしまったほうがよい(Mono の差分な資産はどうするのか?は別として)と思っていたわけです。

が、

dotnet-tomorrow

蓋を開けてみれば、base library の場所が、ごっそり「.NET Standard」に切り替わるって話なんですよね。ええ。.NET Core は 2.0 になることなく、vNext(でいいのか?)という統一された形で、.NET Standard になるわけですね。

すっきりするのはすっきりするんでいいですが、いわゆる OS 依存な低レイヤな部分は、.NET Standard としてどう扱うのか?特にSystem.IO系のセキュリティ絡みは .NET Standard としてどう扱うのか(あるいは扱わないのか)が不明なのですが、ひとまず、ひとつにまとめたい模様です。

PCL Hell が解決するのか?

PCL(Portable Class Library)を作るときに、動作するプラットフォームを選ぶわけですが「そんな未来なことはわかりません」。要は、誰が考えたか知らないのですが、.NET Framework で「Client Profile」っていう Web 系抜きのパッケージを考えたのが間違っていたわけです。

image

and

image

肥大化するアセンブリと、OneClick なインストール環境(だったかな)を利用できるようにするために、Web 系のアセンブリをケチったわけですが、その系譜が、Xamarin.iOS/Android を含める PCL 作りのところまで引き擦られていきます。あのプロファイルの番号は、順列組み合わせになっていて、Silverlight とか、Windows 8.0 とか Windows Phone とか過去の遺物を引きずり回します。まあ、最終的に Proifle7 か Proile78 か Profile259 なマジックナンバーに落ち着くわけですが(苦笑)。

ちなみに、ここの Hell な原因は、アセンブリ名やクラスの厳密性を優先させているのが問題であって、Linux の *.so のように(というか C言語呼び出しのごとく)「名前はどうでもいいから、スタックさえ合っていれば、呼び出せるよ」でもいいわけで、実際 Linux 内で *.so を呼ぶのは非常に簡単ですし、シンボリックも使えて便利です。まあ、その分、競合は発生しそうなんですが、Windows の各種ライブラリみたいに頻繁に更新しない、というのがミソですね。

あと、F# のタイププロバイダーで、ビルドするときの DLL と、出力する DLLと、Xamarin 内で動作する DLL が競合してしまって、Xamarin.Android/iOS 内ではタイププロバイダーを使えないとか、F# のライブラリを参照している C# のライブラリを参照する F# のプロジェクトを作るときにはコツがいるとか、変なことになっているのは、ぜんぶ PCL 絡みの変なことになっているせいです。ええ、F# のライブラリな変な番号も体系も PCL のせいです。F# が流行らないのも PCL のせいだし、ポストが赤いのも PCL のせい。

そんなわけで .NET Standard 1.x が過渡期である

ことが判明して、.NET Core そのものをあれこれと攻めていっても、これも過渡期(2.0がなくて吸収合併するんだったら、まあ VSCode でビルドの仕方ぐらいを覚えるのでよいのでは?)なので、構造的には .NET クラスライブラリの焼き直しの時期なんでしょう。Microsoft 内部の人にはそうなんだけど、外部からすれば、そこで停滞しているわけにはいかない( .NET 以外の分野が主だったりするわけなので)となれば、そこは「最新情報」の獲得にあくせくするのではなくて、

  • 従来型の WPF アプリを極める(内部的に UWP は .NET Standard で統一されるので、UWP でできることが限りなく WPF に近くなる)。
  • スマートフォンは、Xamarin.Forms を拡張してしまうか、Xamarin.iOS/Android で独自に進化させる(特に、Xamarin.Andrid のほう)。
  • Linux で ASP.NET するときは .NET Core を使う

という感じですかね。個人的には。

他にも VR とか Unity とか機械学習で Python とか Alljoyn とか ROS とか、諸々な要因があるわけで、 .NET Standard がそのあたりと「どのくらい組み合わられるか?」が肝になってきます。

もうちょっと真面目な解説はこちらへ

.NET Standard Library
https://docs.com/iwanaga-nobuyuk/3514/net-standard-library

.NET Core とマルチプラットフォーム
http://www.slideshare.net/shozon/net-core-66620714

マイクロソフト、.NETの分裂を未然に防ぐための標準仕様「.NET Standard」を策定 - Publickey
http://www.publickey1.jp/blog/16/netnet_standard.html

カテゴリー: 開発 パーマリンク

.NET Standard とは何か? への1件のフィードバック

  1. ピンバック: Xamarin.Formsに.NET Standardを適用させてみた | 勝手にオザマリン

コメントは停止中です。