[アーティクル]
01/31/2019

Connect(); 2018 年特別号

Volume 33 Number 13

.NET Core - .NET Core 3.0 の新機能

執筆者: Scott Hunter; 2018 年特別号

この記事では、プレビュー段階のテクノロジについて説明します。記載している情報は変更される可能性があります。

.NET Core 3.0 は .NET Core プラットフォームの次のメジャーバージョンです。この記事では .NET Core の歴史について説明し、バージョン 1 での Web およびデータワークロードの基本的なサポートから、バージョン 3.0 で Web、デスクトップ、機械学習、コンテナー、IoT などを実行できるようになるまで、どのように進展してきたのかを示します。

.NET Core 1

.NET Core の歩みは数年前に、2016 年のバージョン 1 から始まりました。当時の目標は、オープンソースでクロスプラットフォーム (Windows、macOS、および Linux) の .NET の最初のバージョンを構築することでした。これを主導したのは、オープンソースのフレームワークのみを使用できるお客様と、Linux サーバー上で .NET アプリケーションを実行する必要のある他のお客様でした。.NET Core はクロスプラットフォーム対応なので、IDE を必要とせずに、すべてのものをコマンドラインから行えるように設計されました。さらに、グローバルにインストールされる 1 つの .NET Framework の互換性という課題から学んだこととして、サイドバイサイドをサポートするように設計されました。その一環として、フレームワークをアプリケーションの一部とすることにより、マシンにインストールされているどのフレームワークにもアプリケーションが依存しないようになっています。バージョン 1 は新しいバージョンの ASP.NET と Entity Framework (EF) とともにリリースされ、Web アプリケーションを主に対象としています。

.NET Core 2

バージョン 1 では、.NET が新しいプラットフォームで実行されましたが、.NET API の限られたセットしかサポートしませんでした。これに対処するために、.NET Standard が作成されました。この標準によって指定された API では、コードとバイナリを .NET プラットフォーム間、およびバージョン間で共有できるように、任意の .NET ランタイムを実装する必要があります。.NET Standard 2.0 では、20,000 以上の API が .NET Standard 仕様に加えられました。2017 年 6 月にリリースされた .NET Core のバージョン 2 には .NET Standard 2.0 のサポートが含まれ、それらの API にアクセスできるようになりました。さらに、System.Drawing、System.DirectoryServices など、多くの Windows 専用 API を含む NuGet パッケージである Windows 互換機能パックも導入されました。ASP.NET Core 2.0 では、.NET Core 1.0 にはなかった Razor Pages と SignalR の 2 つのフレームワークが備えられました。Entity Framework Core では、Entity Framework の人気のある機能である遅延読み込みのサポートが追加されました。また、.NET Core 2 では、.NET を最速のフルスタックフレームワークの 1 つにするように開発が継続されています。独立した会社によって運営されている TechEmpower ベンチマークでは、.NET Core が未加工プレーンテキストパフォーマンスで第 7 位、Web およびデータパフォーマンスの Fortunes テストで Java サーブレットおよび Node.js を抑えて第 6 位となりました (bit.ly/2PEE1l1)。

.NET Core 3.0

.NET Core 3.0 は .NET Core プラットフォームの次のメジャーバージョンです。それには、Windows フォーム (WinForms)、Windows Presentation Foundation (WPF)、Entity Framework 6 による Windows デスクトップアプリケーションのサポートなど、多くの魅力的な新機能が含まれています。Web 開発用に、Razor Components (旧称 Blazor) を使用して、C# でクライアント側 Web アプリケーションを構築するためのサポートが追加されました。さらに、C#8.0 および .NET Standard 2.1 のサポートが含まれています。

.NET Core 3.0 によるモノのインターネット (IoT) シナリオのサポートがまもなく追加されます。Raspberry Pi とそれに類似するデバイスで、ハードウェア PIN を (デバイスの制御やセンサーデータの読み取りのために) プログラミングしたり、サポートされるすべての OSes (Raspberry Pi や Arduino など) 上のシリアルポートを介して通信したりすることが可能になります。またこのリリースでは、既に存在する ARM32 機能を補完するために、ARM64 での IoT デバイスサポートが追加されます。

.NET Core 3.0 では、ML.NET のフルサポートも導入されます。これは、.NET 開発者向けに構築されたオープンソースの機械学習フレームワークです。ML.NET は、Azure Machine Learning、Windows Defender、PowerPoint デザインアイデアなどの製品で利用されています。ML.NET を使用すると、感情分析、レコメンデーション、予測、画像分類など、人気のある多くの機械学習のシナリオをアプリに追加できます。詳細については、bit.ly/2OLRGRQ を参照してください。

最近、.NET Core 3.0 の最初のプレビューがリリースされました。.NET Core 3.0 の詳細とプレビューの試用については、aka.ms/netcore3preview1 を参照してください。

デスクトップ (WinForms および WPF) とオープンソース

WinForms と WPF は、最も人気のある .NET アプリケーションタイプのうちの 2 つであり、何百万もの開発者によって使用されています。.NET Core 3.0 では、WinForms と WPF のサポートが追加され、Windows デスクトップ開発が .NET Core に組み込まれました。.NET Core は常にオープンソースであり、どちらのフレームワークも .NET Core の残りの部分とともに GitHub でのオープンソースになります。初めてのこととして、お客様はこれらのフレームワークのオープンな開発を見ることができるようになり、問題のファイリング、バグの修正、新機能の開発を、GitHub においてライブで支援することさえ可能になります。WinUI XAML Library もオープンソースになる予定であり、XAML Islands を使って、WinForms および WPF アプリケーションでそれらのコントロールを使用できるようになります。

既存の WinForms および WPF アプリケーションの多くは Entity Framework を使用してデータにアクセスするので、Entity Framework 6 も .NET Core でサポートされることになります。

なぜ .NET Core でデスクトップアプリケーションを構築するのか、疑問に思うかもしれません。答えは簡単です。.NET Core のすべての先進機能にアクセスできるようになるからです。.NET Core をインストールしなくても、最新バージョンのフレームワーク上でアプリケーションを構築でき、アプリケーションと .NET Core の両方を 1 つの .EXE に発行することができます。.NET Core はサイドバイサイドを念頭に置いて設計されているので、1 つのコンピューターで複数のバージョンが共存でき、設計したバージョンにアプリケーションをロックできます。このサイドバイサイドという特徴により、アプリケーションを損なうリスクを負うことなく、.NET Core 内の API (WinForms、WPF など) を改良できます。

ASP.NET Core 3

とはいえ、.NET Core 3.0 はデスクトップがすべてではありません。Web 用に設計された、多数の魅力的な新機能もあります。開発中の機能のいくつかを見ていきましょう。

お客様からよく寄せられる質問として、RPC (.NET リモート処理や Windows Communication Foundation のような) のエクスペリエンスを .NET Core 上でどうすれば実現できるかというものがあります。gRPC で .NET 開発者向けの高度なサポートを得られるようにするため、マイクロソフトは gRPC (grpc.io) プロジェクトに貢献しています。

マイクロソフトは今年の前半に、Blazor と呼ばれる、.NET を使用するクライアント側の Web 開発の実験を開始しました。Blazor を使えば、JavaScript を 1 行も記述せずに、WebAssembly ベースの .NET ランタイム上で、ブラウザーで直接実行される Web UI コンポーネントを記述できます。Razor 構文を使用してコンポーネントを作成すると、それはコードとともに通常の .NET アセンブリにコンパイルされます。その後、アセンブリと WebAssembly ベースの .NET ランタイムはブラウザーにダウンロードされ、オープンな Web 標準だけを使って実行されます (プラグインや異種コード間の変換は必要ありません)。図 1 に示されているとおりです。

図 1: Blazor によるクライアント側の Web 開発

別の方法として、.NET Core を使用して同じコンポーネントをサーバー上で実行することもできます。この場合、すべての UI 操作と DOM の更新は、SignalR 接続を介して処理されます。図 2 に示されているとおりです。コンポーネントの実行時には、どんな更新が DOM に必要かを追跡し、それらの更新が適用されるよう、SignalR 接続を介してブラウザーに送信します。UI イベントは、同じ接続を使用してサーバーに送信されます。このモデルには、次のようないくつかの利点があります。ダウンロードサイズがはるかに小さくなり、コードがサーバーで集中管理され、.NET Core で実行することの機能上およびパフォーマンス上の利点をすべて得ることができます。

図 2: SignalR を使用してサーバー上で UI の Web コンポーネントを実行する

.NET Core 3.0 では、Blazor コンポーネントモデルを ASP.NET Core に統合しています。この統合コンポーネントモデルは Razor コンポーネントと呼ばれます。Razor コンポーネントは、ASP.NET Core による構成可能な UI と、.NET によるフルスタックの Web 開発の新しい時代をもたらします。.NET Core 3.0 の初期段階では、Razor コンポーネントは、ルーティング可能なスタンドアロンのコンポーネントとして、あるいは Razor Pages および Views から使用されて、サーバー上で実行されます。ただし、同じコンポーネントを WebAssembly のクライアント側で実行することもできます。.NET Core 3.0 の作業と並行して、インタープリターベースの .NET ランタイムを使用して WebAssembly 上で Razor コンポーネントをサポートする作業を続けていきます。これは、後続のリリースに含まれる予定です。その後、.NET コードの WebAssembly への完全な先行コンパイルのサポートをリリースする予定です。これによって、実行時のパフォーマンスの飛躍的な向上がもたらされるでしょう。

EF Core 3.0

LINQ は好評を得ている .NET の機能であり、選択した言語を離れることなくデータベースクエリを記述できます。これは、豊富なタイプ情報を利用して、IntelliSense を取得し、コンパイル時の型チェックを行います。しかし、LINQ では実質的に無制限の複雑なクエリを記述することもでき、それは LINQ プロバイダーにとって大きな挑戦となってきました。EF Core では、SQL に変換できるクエリの部分を選択してから、残りのクエリをメモリ内で実行することにより、この課題の一部を解決します。場合によっては、これは望ましい方法となりますが、他の多くの場合では、アプリケーションが運用環境になるまで識別できない、きわめて非効率なクエリが発生する可能性があります。

EF Core 3.0 では、LINQ の実装の仕組みやテストの方法を大幅に変更する予定です。その目的は、LINQ が、より堅固なものになり (たとえば、パッチリリースによってクエリが壊れることを避ける)、より多くの式を正確に SQL に変換できるようにし、より多くのケースで効率的なクエリを生成するようにし、運用時まで検出されないきわめて非効率なクエリが発生しないようにすることです。

開発者が EF プログラミングモデルに慣れることができるように、私たちは EF Core 用の Cosmos DB プロバイダーで作業してきました。それによって、アプリケーションデータベースとして Azure Cosmos DB を簡単に対象にするためです。その目標は、いくつかの Cosmos DB の利点 (グローバルな配布、「常時オン」の可用性、弾力性のあるスケーラビリティ、低待機時間など) を .NET 開発者が得られるようにすることです。プロバイダーは、自動変更の追跡、LINQ と値の変換など、多くの EF Core 機能を、Cosmos DB での SQL API に対して有効にしていきます。

EF Core 3.0 に含める予定の他の機能としては、プロパティバッグのエンティティ (通常のプロパティではなくインデックス付きプロパティにデータを格納するエンティティ)、データベースビューをクエリ型にリバースエンジニアリングする機能、IAsyncEnumerable<T> サポートや null 許容参照型などの新しい C# 8.0 機能との統合が挙げられます。

以前のバージョンの EF を使用している多くの既存のアプリケーションでは、EF Core への移植に多大の労力を要することでしょう。そのため、EF 6 が .NET Core 上で動作できるようにするための移植も行っています。

.NET Standard 2.1

.NET Standard に準拠することにより、すべての .NET 実装 (.NET Core だけでなく、Xamarin や Unity も含まれる) で動作するライブラリを作成できます。.NET Standard 1.x では、さまざまな実装間で既に共通している API のみをモデル化しました。.NET Standard 2.0 では、より簡単に既存の .NET Framework コードを .NET Core へ移植できるようにすることに重点が置かれています。その結果として、20,000 の API が追加されただけでなく、互換モードも追加されました。それにより、再コンパイルしなくても、.NET Framework ライブラリを .NET Standard ベースのライブラリから参照できます。すべての API が既存の .NET API であったため、どちらのバージョンの標準にとっても、新しいコンポーネントはほとんどありませんでした。

.NET Standard 2.1 では、以下の点が変更されました。約 3,000 の API が追加されました。それらのほとんどはまったく新しいものであり、.NET Core のオープンソース開発の一部として導入されました。それらを標準に追加することにより、.NET Standard のすべての実装に組み込んでいます。

それらの新しい API のうちの一部を紹介します。

Span<T>: .NET Core 2.1 では Span<T> が追加されました。これは配列に似た型です。これにより、マネージドメモリとアンマネージドメモリを統一された方法で表せるようになり、コピーなしのスライスがサポートされます。Span<T> は、.NET Core 2.1 でのパフォーマンス関連のほとんどの改良点の中核を成すものです。より効率的な方法でバッファーを管理することが可能になるため、割り当てやコピーを減らすのに役立ちます。この型の詳細については、Span<T> に関する Stephen Toub の優れた記事をお読みください (msdn.com/magazine/mt814808)。
ValueTask および ValueTask<T>: .NET Core 2.1 での最も顕著な特徴の 1 つは、ハイパフォーマンスシナリオをサポートするための基盤の改良です (bit.ly/2HfIXob)。これには、async/await の効率を高めることも含まれています。 ValueTask <T> は既に存在しており、操作が同期的に完了した場合に結果を返すことができます。その際、新しい Task <T> を割り当てる必要はありません。.NET Core 2.1 では、この点がさらに改良され、対応する非ジェネリック ValueTask が活用されるようになりました。それにより、操作が非同期に完了する必要がある場合でも割り当てを減らすことができ、Socket や NetworkStream のようなタイプの機能を利用できるようになりました。
全般的な利点: .NET Core がオープンソースであったため、ハッシュコードを組み合わせるための System.HashCode や、System.String の新しいオーバーロードなど、基本クラスライブラリ間で小さな機能が多数追加されました。.NET Core には約 800 の新しいメンバーがあり、ほぼすべてが.NET Standard 2.1 に追加されています。

詳細については、.NET Standard 2.1 のお知らせ (bit.ly/2RCW2fX) をご確認ください。

C# 8.0

C#8.0 は次のバージョンの C# であり、いくつかの主要な方法で、C# 言語を改善します。null 許容参照型は、null 参照例外を回避し、null セーフなコーディング手法を推進するのに役立ちます。たとえば、文字列型の変数やパラメーターに null を割り当てたときに警告を受け取る機能を採用できます。null を必要とする場合には、“string?” という null 許容参照型を使用して、その旨を示す必要があります。

async/await が単独の非同期結果に対して行うことを、Async Streams がデータの非同期ストリームに対して行います。新しいフレームワーク型である IAsyncEnumerable<T> は IEnumerable<T> の非同期バージョンであり、同様に foreach と yield return を行います。

public static async IAsyncEnumerable<T> FilterAsync<T>(
  this IAsyncEnumerable<T> source,
  Func<T, Task<bool>> predicate)
{
  await foreach (T element in source)
  {
    if (await predicate(element)) yield return element;
  }
}

他の機能の 1 つとして、既存の実装を壊すことなく、既定のインターフェイスメンバー実装によって、インターフェイスが新しいメンバーを追加できるという機能があります。Switch 式によって、より簡潔なパターンマッチングが可能になり、パターンは再帰的で、テスト対象の値に、より深く掘り下げることができます。詳細については、C#8.0 (aka.ms/csharp8) を参照してください。

.NET Framework と .NET Core の今後の進展

.NET Framework は、10 億以上のマシンにインストールされている .NET の実装です。そのため、可能な限り互換性を維持する必要があります。こうした理由で、.NET Core よりもゆっくりとしたペースで前進しています。アプリケーションは以前の動作に依存しているため、セキュリティ修正やバグ修正でさえ、アプリケーションが機能しなくなる原因になりかねません。マイクロソフトは、.NET Framework が、最新のネットワークプロトコル、セキュリティ標準、Windows 機能を常にサポートしていることを確認しています。

.NET Core は、オープンソースでクロスプラットフォームの、最も動きの速いバージョンの .NET といえます。そのサイドバイサイドという特徴により、.NET Framework では適用するリスクを冒せないような変更も行うことができます。時経つうちに、NET Framework では採用できないような新しい API や言語の機能が .NET Core で採用されていくでしょう。

既存の .NET Framework アプリケーションを利用しており、.NET Core の機能をどれも活用する必要がないのであれば、.NET Core に移行するべきだと圧力を感じる必要はありません。.NET Framework と .NET Core は両方とも十分にサポートされていきます。.NET Framework は常に Windows の一部です。マイクロソフト内部にも、.NET Framework に基づく多数の大きな製品ラインがあり、今後も .NET Framework はベースであり続けます。しかし、今後の進展により、.NET Core と .NET Framework に含まれる機能は幾分異なってくるでしょう。

まとめ

.NET Core 3.0 は、2019 年の後半にリリースされる予定です。オープンソース版の WinForms と WPF (Windows デスクトップ開発用) が含まれることになります。Entity Framework 6 も含められます。さらに、ASP.NET Core、Entity Framework Core、.NET Standard と C# はすべて、重要な更新プログラムを受け取ります。このバージョンの .NET Core は、新しい .NET アプリケーションとして真剣に検討する必要があります。詳細については、aka.ms/netcore3preview1 を参照してください。

.NET の未来と、.NET Core がより多くのワークロードを担うようになることを楽しみにしています。.NET Core 3.0 のプレビューをお試しになり、フィードバックをお送りください。

Scott Hunter氏は、.NET のプログラム管理のディレクターとしてマイクロソフトのために働き、ランタイム、フレームワーク、マネージド言語 (C#、F#、VB.NET) および .NET ツールを監督しています。Hunter 氏が Mustang Software および Starbase を含むいくつかのスタートアップ企業の CTO となる以前、彼はさまざまなテクノロジに注目していましたが、Web のプログラミングこそが、常に彼の情熱の対象でした。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Ankit Asthana、Damian Edwards、Richard Lander、Immo Landwerth、Beth Massi、Mads Torgersen に心より感謝いたします。

この記事について MSDN マガジンフォーラムで議論する