オープンソース版の.NET Frameworkの「.NET Core」
.NET Coreは、Windows 10とともに登場した「オープンソース版」の.NET Frameworkだ。.NET Coreは、オープンソースソフトウェアとして、Windows 10のリリース翌年、2016年6月に公開された。簡単に言えば.NET Frameworkの根幹の部分だけを取り出して、「Windows以外でも動作できるようにした.NET Framework」だ。
当初、Microsoftは、Windows10のUWPとWindowsBridgeと呼ばれる4つのプロジェクトを組み合わせ、ウェブアプリ、Win32デスクトップアプリ、Androidアプリ、iOSアプリをWindows 10で動作させ、UWPからそれらのアプリを開発できるようにすることを計画した。
さらにはWindows 10をファミリー化して、Xbox OneやWindows Holograph、Windows Mobile、Windows IoTなどの派生バージョンや、プラットフォームを作った。これらすべてで動作できるように考えられたのがUWPであり、UWPアプリだ。

PCだけでなく、Windows Mobile、Xbox、HoloLensなど「Windowsファミリー」全部で動くアプリがUWPアプリだ。このためPCのWindows 10には、「Windows 10 Desktop」なる名称もあった
このため、UWPはWindows 10ファミリーの“最大公約数”的なものになった。WindowsBridgeは、既存の他のプラットフォームのアプリケーションをWindows 10で動かすためのもので、.NET Coreは、UWPで作ったアプリケーションを他のプラットフォームでも動作させるためのものとした。「世の中すべてWindows 10」みたいな計画で、そのための.NETが.NET Coreだったのだ。

Windows Bridgeを使うことで、ウェブアプリ、デスクトップアプリ、Android、iOSのアプリがWindowsで動作。さらにUWPをベースにすることで、さまざまなプラットフォーム向けのアプリを開発できるとしていた
しかし、WindowsBridgeは早々に撤退。残ったのは、Win32アプリをMicrosoftストアで販売するためのDesktop Bridge(Project Centennial)だけ。UWPはマルチプラットフォーム化を想定していたため、Windows固有の機能に依存しないように開発できるようにした。それがために不自由さを生み出し、Windowsのアプリケーション実行環境としても不満足なものになってしまった。実際に初期のUWPには「できないこと」が多すぎた。
.NET Coreが産まれた背景には、Windows 8で導入されたWinRTとWindowsストアアプリがある。モダン環境はWindows 8で産まれた。そのときの実行環境が「WinRT」だ。このとき、Windowsのプログラムは、モダン環境(WinRT、ストアアプリ)とWindows 7までのデスクトップ環境に分離し、それぞれ別の作り方をすることになった。モダン環境はWindows 10ではUWPへと変化した。WinRTは、.NETの実行システムを含んでいたが、ライブラリに相当する部分は、Windowsストア用に作られたWinRT用のものだった。
Windows 8とWindows 10で、Microsoftは、UWP/モダン環境とデスクトップ環境の2つを持つことになった。UWPでアプリを作れば、どのWindows 10でも動き、他のプラットフォームにも移植が簡単というのは“建前”としては理解できるが、その結果として、UWPには「キツい制限」と「不満足なAPI」しかなかったわけだ。
.NET Coreは、.NETの「コア」として作られた。もちろんオープンソース化し、さまざまなプラットフォームに移植可能にするには、Windowsに依存した部分があってはならない。.NETの根幹部分だけを抽出して作り、さまざまなモジュールと組み合わせて、実行環境に合わせたアプリケーションを作れるようにした。.NET Coreは、.NET Frameworkの再構築でもあるのだ。
今風に言えば、「リブート」や「リターンズ」ってやつである。もっとも、APIとしてはWinRTのときに再構築しているので、「リブート・リターンズ」ってやつかもしれない。
その後、Microsoftは方向転換する。せっかくXamarinまで買収してマルチプラットフォーム化を推進したのにUWPにあまりに人気がなく、Windowsの開発者は相変わらずデスクトップアプリばっかり作っているからだ。
そこで開発者に人気のデスクトップアプリケーションへの回帰と、古くなった.NET Frameworkの置き換えとして、.NET Coreを活用することにしたのである。その方向性が見え出したのが、2018~2019年である。具体的な製品としてデスクトップアプリでUWPのユーザーインターフェースを導入可能にする「XAML Islands」や「MSIX」が発表されたのがこの頃だ(どうしようか考え始めたのは、さすがにその前なのだろうが)。
そして.NET Core 3.0(2019年9月リリース)では、Windowsデスクトップアプリケーションの開発をサポートした。.NET Core 3.0がデスクトップアプリに対応するという計画は、.NET Core 3.0がリリースされる前年のBuild 2018で発表されており、この頃には、Project Reunionの下地が出来ていたのだと考えられる。
そして2020年に発表されたのが「Project Reunion」だ。2つに分かれたWindowsの開発環境がこうして一体化する。なんだか、超古代の遺物が元の場所に戻された結果、驚愕の展開となる映画を見ているような気になってくるが、結末にはまだ早い。Project Resunionが完成するのが今年の第4四半期、来年の「お楽しみ」だろう。

この連載の記事
-
第475回
PC
Windowsのコマンドラインの補完機能について解説 -
第474回
PC
Windowsでのコマンドラインのヒストリ機能 -
第473回
PC
Windowsは内部的にどうやってインターネットへの接続状態を確認している? -
第472回
PC
WindowsのエラーをMicrosoftに送信するテレメトリ機能を理解する -
第471回
PC
Windowsのコマンドラインでエイリアスを使う -
第470回
PC
Windows用のパッケージマネージャー「Winget」 プレビュー版で機能が充実してきた -
第469回
PC
Windows Updateの27年 悪役だった頃から改良が進んで、徐々に目立たない存在に -
第468回
PC
2025年のWindowsどうなる!? Windows Insider Programの状況をあらためて見る -
第467回
PC
Copilot+ PCのNPUでカメラを処理する「Windows Studio Effects」 その内容や効果は? -
第466回
PC
PowerToysの最近の新機能には、複数アプリを指定位置に起動する「ワークスペース」や新規作成のカスタマイズがある -
第465回
PC
WindowsのPowerShellからBluetoothデバイスを調べる - この連載の一覧へ