Windows用として生まれて、クロスプラットフォームに育った.NETの宿命というか。System名前空間から始まるライブラリと、Microsoft名前空間から始まるライブラリの話。

System or Microsoft

Systemなんて名前、基本的には標準ライブラリ用なわけですが。

「.NET系開発者はサードパーティ ライブラリにも平然とSystemの名前を付けることがある」みたいな問題もありますが、それは今回は置いておきます。今回は割かし標準に近いところ、マイクロソフトによる公式実装のライブラリの話です。

「.NET = マイクロソフト」(他のOSは「そのマイクロソフト.NETの移植」)だった頃には割かし何でもSystem名前空間にされていたわけですが、オープンソース、コミュニティによる推進、クロスプラットフォームなんかをうたうようになった最近はそれではまずいということで、Microsoft名前空間なライブラリが増えています。

Systemやめました

WindowsにべったりなものがSystem名前空間だったんですよねぇ、長らく。それが徐々に、クロスプラットフォームに耐えうるものがSystem、そうでないものは別の名前空間へと変化。だいたい、2012年頃(Windows 8が出た頃、.NET的には.NET 4.5くらいの頃)が境目。

GUIフレームワーク

「Windowsにべったり」というとGUIフレームワーク系のもので、以下のような感じ。わかりやすく、「.NETから分離します」「Systemやめます」の流れ。

  • Windows Forms (System.Windows.Forms.dll)
    • .NET 1.0時代からあるGUI
    • だいたいのクラスがSystem.Windows.Forms名前空間
    • Win32 API感丸出し。
    • それでも、Monoががんばって移植作業したのでなんとか「標準」の体は保ってる
  • WPF (WindowsBase.dll, PresentationCore.dll, PresentationFramework.dll)
    • だいたいのクラスがSystem.Windows名前空間
    • .NET 3.0。この時代もまだまだSystem名前空間
    • アセンブリ名からはSystemが外れる
    • さすがに高機能すぎて移植無理で、完全にWindows用
  • Windows Runtime, Windows.UI
    • ついに、GUIフレームワークは.NETから分離
      • WPF的なものをC++ネイティブ実装した上で、.NETから参照しやすいAPI用意したもの
    • .NETの世代的には.NET 4.5時代の出来事
    • 名前空間はさすがにWindows

Web

ASP.NETもSystem名前空間をやめました。まあ「標準」に組み込むにはちょっとでかすぎる感じはあります。

境目は5。ASP.NET MVC 4まではSystem.Web.Mvc名前空間。ASP.NET MVC 5でMicrosoft.AspNetに。Webフレームワークの1つにすぎないASP.NETがWeb名前空間を名乗る仰々しさも軽減。

悪名高きSystem.Web.dll (IISにべったり)依存とかも切って、晴れてクロスプラットフォームに。

Systemやめてませんでした

ここまではわかりやすく、「Systemやめました」なものなのでいいんですが。問題はここから。

プレビュー版実装から標準に昇格

.NET 4辺りの頃からなんですが、プレビュー版の間は仮にMicrosoft名前空間で実装しておいて、標準ライブラリに取り込めるとなった段階で初めてSystem名前空間に変更するというような開発フローを取っていました。

  • dynamic関連
    • プレビューの頃はMicrosoft.Dynamic
    • .NET 4ではSystem.Dynamic
  • Task関連
    • プレビューの頃はMicrosoft.Threading.Tasks
    • .NET 4ではSystem.Threading.Tasks
  • async関連
    • プレビューの頃はMicrosoft.Runtime.CompilerServices
      • (Taskクラスなどの既存のクラスの拡張はSystem名前空間。CompilerServicesだけが新規)
    • .NET 4.5ではSystem.Runtime.CompilerServices

これは「Systemに正式配属されました」なので問題ないんですが、ちょっと困るのがこの先。

バックポーティング実装

この手の新機能を、古いフレームワーク上でも使えるようにするバックポーティング実装があります。

  • Microsoft.Bcl
    • .NET 4.5のCallerMemberNameAttribute、Tuple、IProgressなんかを.NET 4で使えるようにするもの
  • Microsoft.Bcl.Async
    • C# 5 (.NET 4.5)の非同期メソッドを.NET 4で使えるようにするもの
  • Microsoft.Net.Http
    • .NET 4.5のSystem.Net.Http.HttpClientを.NET 4で使えるようにするもの

こいつら、中身の名前空間はSystemのくせに、パッケージ名はMicrosoft。プレビュー時代の名残なのかなんなのか。(未来の)標準ライブラリなのに。

やっぱりSystemダメでした

同系統で、一瞬「標準」に昇格した奴がいます。

お気づきでしょうか。ETWのWの文字。「for Windows」。これまで「.NET 4.5のあたりでWindowsべったりな奴はSystemから外れた」とさんざん説明してきたところで、こいつの存在に頭抱えることに。

ちなみに、こいつ、その後も、Microsoft名前空間実装が生き残っていたりします。

  • Microsoft.Diagnostics.Tracing.EventSource
    • 曰く
      • 「EventSourceクラスは標準にも含まれているけど、こっちの方が新しくて機能多い」
      • 「System.Diagnostics.Tracing.EventSourceの方にとりこまれるまでのギャップ解消に使って」

「Systemの方にとりこまれるまで」と書かれているものの、何かこのままMicrosoftの方にすべきなんじゃないかという予感もひしひしと…

逆に、なぜMicrosoft…

逆に、「なぜそれをMicrosoft名前空間にした」というものもあったりはします。

こいつ。

  • Microsoft.CSharp
    • C# 4のdynamicの中で使うやつ
      • C#のオーバーロード解決ルールに従って、実行時バインディングするためのライブラリ
    • この名前で、C#コンパイラーそのものを指すライブラリではないのでそこも要注意

C# 4のdynamicを使うのに必須のライブラリです。Mono版C#コンパイラーでも必須(Mono版のMicrosoft.CSharp実装あり)です。確かに、C#に依存した機能なのでSystem名前空間だと変なんですが。一方で、マイクロソフト実装でなくても必須なものにMicrosoft名前空間というのも嫌な感じで。

まとめ

最近のノリだと、

  • .NET Core (オープンソースでクロスプラットフォームな.NET)でも「標準」となるべき基本ライブラリだけがSystem名前空間
  • その他のマイクロソフト公式実装はMicrosoft名前空間

になっているんですが、過去さかのぼると何でも間でもSystem名前空間だったし、その名残がいまだちらほらあったりします。特に、System.Diagnostics.Tracing.EventSourceとかどうするんだろう…

最近の投稿

アーカイブ