.NET Coreの概要

connect（）カンファレンスで、 .NET Coreがオープンソースソフトウェアとして完全にリリースされることを発表しました 。 この記事では、.NET Coreをレビューし、それをリリースする方法、.NET Frameworkと比較する方法、およびクロスプラットフォーム開発とオープンソース開発にとってこれが何を意味するかを説明します。

振り返って-.NET Coreの動機

まず、振り返って、.NETプラットフォームが以前にどのように配置されたかを理解しましょう。 これは、.NET Coreの出現につながった個々の決定およびアイデアの動機を理解するのに役立ちます。

.NET-垂直セット

2002年に.NET Frameworkを最初にリリースしたとき、それは唯一のフレームワークでした。 その後すぐに、Windows Mobileなどの小型デバイスに適合する.NET Frameworkのサブセットである.NET Compact Frameworkをリリースしました。 コンパクトなフレームワークには個別のコードベースが必要であり、その上にランタイム、フレームワーク、およびアプリケーションモデル全体が含まれていました。



それ以来、Silverlight、Windows Phone、そして最近ではWindows Storeというサブセットを数回選択する練習を繰り返してきました。 これは、実際には.NETプラットフォームは単一のものではなく、異なるチームによって独立して管理およびサポートされる一連のプラットフォームであるため、断片化につながります。



もちろん、特定のニーズを満たす特殊な機能セットを提供するという考えには何の問題もありません。 これは、体系的なアプローチがなく、他のバーティカルの対応するレイヤーで発生することを考慮せずに各レイヤーで特殊化が発生する場合に問題になります。 そのような決定の結果は、かつては単一のコードベースから開始されたために、多くの共通APIを備えた一連のプラットフォームになります。 一定のAPIを実現するために明示的な（そして高価な）演習を行わない限り、時間が経つにつれて、これは差異の増加につながります。







断片化の問題はどの時点で発生しますか？ 1つの業種のみを対象にしている場合、実際には問題はありません。 特定の業種向けに最適化された一連のAPIが提供されます。 この問題は、多くの垂直方向に向けて、水平方向の何かを実行するとすぐに現れます。 今、あなたはさまざまなAPIの可用性について疑問に思っており、さまざまなターゲット分野で機能するコードのブロックを作成する方法を考えています。



今日、さまざまなデバイスをカバーするアプリケーションを開発するタスクは非常に一般的です。ほとんどの場合、Webサーバー上で何らかのバックエンドが実行され、多くの場合、デスクトップWindowsを使用する管理フロントエンドがあり、ほとんどの人が利用できるモバイルアプリケーションのセットもありますさまざまなデバイス。 したがって、すべての.NETカテゴリをカバーするコンポーネントを作成する開発者をサポートすることが重要です。

ポータブルクラスライブラリ（PCL）の誕生

当初、異なる業種間でコードを分割するための特別な概念はありませんでした。 移植可能なクラスライブラリや共有プロジェクトはありませんでした。 文字通り、多くのプロジェクトを作成し、ファイルリンクと多くの#ifを使用する必要がありました。 これにより、複数のバーティカルを対象とするタスクが非常に困難になりました。



Windows 8が登場する頃には、この問題に対処する計画がありました。 Windowsストアプロファイルを設計したときに、サブセットのより良いモデリングのための新しい概念、契約を導入しました。



.NET Frameworkが設計されたとき、それは常に単一のユニットとして配布されるという前提があったため、分解の問題は重大とは見なされませんでした。 すべてが依存するアセンブリの中心はmscorlibです。 .NET Frameworkに同梱されているmscorlibライブラリには、普遍的にサポートできない多くの機能が含まれています（たとえば、リモート実行やAppDomain）。 これは、各業種がプラットフォームのコアの独自のサブセットを作成するという事実につながります。 したがって、多くの業種向けに設計されたクラスライブラリを作成するのは困難です。



コントラクトの背後にある考え方は、コード分解タスクに適したよく考えられたAPIセットを提供することです。 コントラクトは、コードをコンパイルできる単なるアセンブリです。 従来のアセンブリとは異なり、コントラクトアセンブリは分解タスク専用に設計されています。 コントラクト間の依存関係を明確にトレースし、APIのダンプではなく、1つのことに責任を持つように記述します。 契約には独立したバージョン管理があり、対応するルールに従います。たとえば、新しいAPIが追加された場合、新しいバージョンのアセンブリで利用可能になります。



今日、私たちはコントラクトを使用してすべての業種でAPIをモデル化します。 バーティカルは、サポートする契約を簡単に選択できます。 重要な点は、バーティカルは契約全体をサポートする義務があるか、まったくサポートしない義務があるということです。 つまり、契約のサブセットを含めることはできません。



これにより、以前のようにAPIの個々の違いとは対照的に、既にアセンブリレベルでの業種間のAPIの違いについて話すことができます。 これにより、多くの業種を対象としたコードライブラリのメカニズムを実装できます。 このようなライブラリは現在、ポータブルクラスライブラリとして知られています。

APIフォームユニオンと実装ユニオン

ポータブルコードライブラリは、APIフォームに基づいてさまざまな.NETカテゴリを組み合わせたモデルと考えることができます。 これにより、最も重要なニーズ-さまざまな.NET分野で機能するライブラリを作成する機能に対応できます。 このアプローチは、さまざまな業種、特にWindows 8.1とWindows Phone 8.1をまとめることができるアーキテクチャ計画ツールとしても機能します。



ただし、.NETプラットフォームのさまざまな実装、フォーク（コードブランチ）がまだあります。 これらの実装は、さまざまなチームによって管理され、独立したバージョン管理と異なる配信メカニズムを備えています。 これは、APIの形式を統一するタスクが移動ターゲットになるという事実につながります：APIは、実装がすべての分野に沿って前進する場合にのみ移植可能ですが、コードベースが異なるため、非常に高価な喜びになり、したがって（再）優先順位付けの対象となります。 APIの均一性を完全に実装できたとしても、すべての業種が異なる配信メカニズムを備えているという事実は、エコシステムの一部が常に遅れることを意味します。



実装を統合する方がはるかに優れています。適切に分解された説明を提供するだけでなく、分解された実装を準備する必要があります。 これにより、バーティカルは同じ実装を簡単に使用できます。 垂直の概算では、追加のアクションは不要になります。 ソリューションを適切に設計するだけで実現できます。 もちろん、さまざまな実装が必要な場合もあります。 この良い例は、ファイル操作です。これには、環境に応じて異なるテクノロジーを使用する必要があります。 ただし、この場合でも、特定のコンポーネントを担当する各チームに、さまざまな分野でAPIがどのように機能するかについて考えることは、事実上、単一のAPIセットを提供しようとするよりもはるかに簡単です。 移植性は後から追加できるものではありません。 たとえば、ファイルAPIにはWindowsアクセス制御リスト（ACL）のサポートが含まれていますが、これはすべての環境でサポートされているわけではありません。 APIを設計するときは、そのような点を検討する必要があります。特に、ACLをサポートしていないプラットフォームでは利用できない可能性のある個別のアセンブリで同様の機能を提供する必要があります。

マシン全体のフレームワークとローカルアプリケーションフレームワーク

もう1つの興味深い課題は、.NET Frameworkの配布方法です。



.NET Frameworkは、マシンフレームワーク全体です。 それに加えられた変更は、それに依存するすべてのアプリケーションに影響します。 マシン全体で単一のフレームワークを使用することは、次の問題を解決できるため、賢明な決定でした。

1. 集中サービス
2. ディスク容量の要件を削減
3. アプリケーション間でネイティブコードを共有できます

しかし、すべてに価格があります。



まず、アプリケーション開発者がリリースされたばかりのフレームワークにすぐに切り替えることは困難です。 実際、オペレーティングシステムの最新バージョンに依存するか、必要に応じて.NET Frameworkもインストールできるアプリケーションインストーラーを準備する必要があります。 Web開発者の場合、IT部門が使用を許可するバージョンを指示するため、そのようなオプションさえないかもしれません。 そして、あなたがモバイル開発者である場合、一般に、選択の余地はなく、ターゲットOSのみを決定します。



ただし、.NET Frameworkを確実に使用できるようにインストーラーを準備する問題を解決しようとしても、フレームワークを更新すると他のアプリケーションの動作が中断される可能性があります。



停止します、私たち（Microsoft）は、私たちの更新が非常に互換性があると言いませんか？ はい、そうです。 そして、互換性の問題を非常に深刻に考えています。 .NET Frameworkに加えた変更を慎重に分析します。 そして、「重大な」変化となる可能性のあるすべてについて、結果を調べるために別の調査を実施しています。 私たちは、多くの一般的な.NETアプリケーションをテストして、それらが壊れないことを確認するための完全な互換性ラボを持っています。 また、アプリケーションがどの.NET Frameworkによって作成されたかを理解します。 これにより、既存のアプリケーションとの互換性を維持すると同時に、.NET Frameworkの最新バージョンで動作する準備ができているアプリケーションの動作と機能を改善できます。



残念ながら、互換性のある変更でさえアプリケーションを混乱させる可能性があることもわかっています。 以下に例を示します。

• 既存の型にインターフェイスを追加すると 、型のシリアル化方法に影響を与える可能性があるため、アプリケーションが混乱する可能性があります。
• 以前にオーバーロードがなかったメソッドにオーバーロードを追加すると 、コードが複数のメソッドを検出する確率を処理しない場合にリフレクションが中断される可能性があります。
• 内部型の名前を変更すると 、ToString（）メソッドを介して型名が決定されると、アプリケーションが破損する可能性があります。

これらはすべて非常にまれなケースですが、ユーザーベースが18億台の車である場合、99.9％の互換性があるため、180万台の車が影響を受けます。



興味深いことに、多くの場合、影響を受けるアプリケーションを修正するには、かなり簡単な手順が必要です。 ただし、問題は、アプリケーション開発者が故障時に常に利用できるとは限らないことです。 特定の例を見てみましょう。



.NET Framework 4を使用してアプリケーションをテストし、アプリケーションとともにインストールするのはユーザーです。 しかし、ある日、顧客の1人が、マシンを.NET Framework 4.5にアップグレードする別のアプリケーションを提供しました。 顧客がサポートに電話するまで、アプリケーションが壊れていることはわかりません。 この時点で、互換性の問題を修正することは既に高価な作業になる可能性があります：適切なソースを見つけ、問題を再現するようにコンピューターを構成し、アプリケーションをデバッグし、必要な変更を加え、リリースブランチに統合し、ソフトウェアの新しいバージョンをリリースし、テストし、最後に転送する必要があります顧客への更新。



これをこの状況と比較してください。最新バージョンの.NET Frameworkに追加されたいくつかの機能を利用することにしました。 この時点で、開発段階にあり、アプリケーションに変更を加える準備ができています。 わずかな互換性の問題がある場合は、以降の作業で簡単に考慮することができます。



これらの問題のため、.NET Frameworkの新しいバージョンのリリースにはかなりの時間がかかります。 そして、変更が目立つほど、準備に時間がかかります。 これは、ベータ版がすでに実質的に凍結されており、設計変更の要求を満たす機会がほとんどない場合、逆説的な状況につながります。



2年前、NuGetを通じてライブラリの配布を開始しました。 これらのライブラリを.NET Frameworkに追加しなかったため、それらを帯域外としてマークします（オプション）。 追加のライブラリは、アプリケーションにローカルであるため、先ほど説明した問題の影響を受けません。 つまり、アプリケーションの一部であるかのように配布されます。



このアプローチは、一般に、最新バージョンへのアップグレードを妨げるすべての問題をほぼ完全に取り除きます。 アップグレードする能力は、アプリケーションの新しいバージョンをリリースする能力によってのみ制限されます。 また、特定のアプリケーションが使用するライブラリのバージョンを制御することも意味します。 更新は、同じマシン上の他のアプリケーションに影響を与えることなく、1つのアプリケーションのコンテキストで行われます。



これにより、より柔軟な方法で更新プログラムをリリースできます。 NuGetは、プレリリースバージョンを試す機会も提供します。これにより、特定のAPIの操作に関する厳密な約束なしに、ビルドをリリースできます。 このアプローチにより、アセンブリ設計の新鮮な外観を提供するプロセスをサポートすることができます-気に入らない場合は、変更するだけです。 これの良い例は、不変のコレクションです。 ベータ期間は約9か月続きました。 最初のバージョンをリリースする前に、適切な設計を得るために多くの時間を費やしました。 言うまでもなく、ライブラリのデザインの最終バージョンは、多くのレビューのおかげで、初期バージョンよりもはるかに優れています。

.NET Coreへようこそ

これらのすべての側面により、将来、.NETプラットフォームの形成へのアプローチを再考し、変更することを余儀なくされました。 これにより、.NET Coreが作成されました。





.NET Coreは、データセンターからタッチデバイスまで、さまざまな業種で使用できるモジュール式の実装であり、オープンソースで利用でき、Windows、Linux、およびMac OSXでMicrosoftによってサポートされています。



.NET Coreとは何か、および新しいアプローチが上記の問題にどのように対処しているかを詳しく見てみましょう。

.NET NativeおよびASP.NETの統合実装

.NET Nativeを設計したとき、.NET Frameworkをクラスライブラリフレームワークの基盤として使用できないことは明らかでした。 .NET Nativeが実際にフレームワークをアプリケーションとマージし、ネイティブコードを生成する前にアプリケーションで不要な部分を削除するのはこのためです（このプロセスをおおまかに単純化するため、こちらで詳細を調べることができます ）。 前に説明したように、.NET Frameworkの実装は分解されません。これにより、リンカーがアプリケーションに「コンパイル」されるフレームワークの部分を減らすことが難しくなります-依存関係のある領域は単純に非常に大きくなります。



ASP.NET 5でも同様の問題が発生しました。 .NET Nativeを使用しませんが、新しいASP.NET 5 Webスタックの目標の1つは、Web開発者がIT部門と調整して最新バージョンの機能を追加する必要がないように、簡単にコピーできるスタックを提供することでした。 このシナリオでは、フレームワークはアプリケーションとともに配置する必要があるため、フレームワークのサイズを最小化することが重要です。



実際、.NET Coreは.NET Frameworkのフォークであり、その実装は分解タスク用に最適化されています。 .NET Native（モバイルデバイス）とASP.NET 5（Web開発のサーバー側）のスクリプトは順番が異なりますが、統合されたBase Class Library（BCL）を作成できました。







.NET Core BCLで利用可能なAPIセットは、両方の業種で同じです。.NETNativeとASP.NET 5の両方で。BCLには、.NETランタイムに固有の非常に薄いレイヤーがあります。 現時点では、2つの実装があります。1つは.NETネイティブ環境専用、もう1つはASP.NET 5で使用されるCoreCLR専用です。ただし、このレイヤーはあまり頻繁に変更されません。 StringやInt32などの型が含まれています。 ほとんどのBCLは、そのまま再利用できる純粋なMSILアセンブリです。 つまり、APIは同じように見えるだけでなく、同じ実装を使用します。 たとえば、コレクションに異なる実装を使用する理由はありません。



BCLの上に、アプリケーションモデルに固有のAPIがあります。 特に、.NET Nativeは、WinRT相互運用機能など、Windowsクライアント開発に固有のAPIを提供します。 ASP.NET 5は、Web開発のサーバー側に固有のMVCなどのAPIも追加します。



.NET Coreは、.NET NativeまたはASP.NET 5 BCLに固有ではないコードと見なされます。 ランタイム環境は一般化されたタスクを対象とし、モジュール式になるように設計されています。 このようにして、それらは将来の.NET分野の基盤を形成します。

ファーストクラスの配信メカニズムとしてのNuGet

.NET Frameworkとは異なり、.NET CoreプラットフォームはNuGetパッケージのセットとして提供されます。 NuGetに依存しているのは、これがまさにライブラリエコシステムのほとんどが既に配置されている場所だからです。

.NET Core全体を単一のNuGetパッケージとして提供する代わりに、モジュール性と適切な分解に向けた取り組みを継続するために、一連のNuGetパッケージに分解します。







BCLレイヤーでは、ビルドとNuGetパッケージが直接対応します。



将来的には、NuGetパッケージの名前はアセンブリと同じになります。 たとえば、不変のコレクションはMicrosoft.Bcl.Immutableという名前で配布されなくなり、代わりにSystem.Collections.Immutableというパッケージに含まれます。



さらに、アセンブリのバージョン管理にセマンティックアプローチを使用することにしました。 NuGetパッケージのバージョン番号は、アセンブリのバージョンと一致します。



アセンブリとパッケージ間の命名とバージョン管理の一貫性により、検索が非常に容易になります。 System.Fooに含まれるパッケージ、バージョン= 1.2.3.0について質問する必要はありません。これは、バージョン1.2.3のSystem.Fooパッケージに含まれています。



NuGetを使用すると、.NET Coreを柔軟に提供できます。 したがって、NuGetパッケージのアップデートをリリースする場合、対応するリンクをNuGetにアップデートするだけです。



また、NuGetを介してフレームワークを提供すると、ネイティブの.NET依存関係とサードパーティの依存関係の違いがなくなります。これは、NuGetの依存関係に過ぎません。 これにより、サードパーティのパッケージは、たとえば、System.Collectionsライブラリの最新バージョンが必要であることを宣言できます。 サードパーティパッケージをインストールすると、System.Collectionsへのリンクを更新できるようになりました。 依存関係グラフを理解する必要はありません-それに変更を加えるには同意のみが必要です。



NuGetベースの配信により、.NET Coreプラットフォームがローカルアプリケーションフレームワークに変わります。 .NET Coreのモジュール設計により、すべてのアプリケーションは必要なものだけをインストールする必要があります。 また、複数のアプリケーションが同じフレームワークビルドを使用する場合、リソースをスマートに共有できるように取り組んでいます。 ただし、目標は、更新が同じマシン上の他のアプリケーションに影響を与えないように、各アプリケーションが論理的に独自のフレームワークを持つようにすることです。



配信メカニズムとしてNuGetを使用するという決定は、相互運用性へのコミットメントを変更するものではありません。 引き続きこのタスクを可能な限り真剣に受け止め、パッケージが安定したものとしてマークされると、アプリケーションやアプリケーションを混乱させる可能性のあるAPIや動作を変更しません。 ただし、アプリケーションのオンプレミス展開により、追加された変更によってアプリケーションが破損するまれなケースが開発プロセスに限定されることを確認できます。 つまり、.NET Coreの場合、このような違反はパッケージリンクを更新したときにのみ発生します。 現時点では、アプリケーションの互換性の問題を修正するか、NuGetパッケージの以前のバージョンにロールバックするという2つのオプションがあります。 ただし、.NET Frameworkとは異なり、このような違反は、顧客にアプリケーションを配信した後、または運用サーバーに展開した後は発生しません。

企業での使用に対応。

NuGetによる配信モデルを使用すると、柔軟なリリースプロセスとより高速な更新を行うことができます。 ただし、今日の.NET Frameworkでの作業に存在する、1か所で取得した経験を取り除くことは望みません。



厳密に言えば、.NET Frameworkは非常に美しいため、1つのユニットとして提供されます。つまり、Microsoftはコンポーネントを1つのエンティティとしてテストおよびサポートしています。 .NET Coreの場合、この機能も提供します。 .NET Core配布の概念を紹介します。 簡単に言えば、これはテストした特定のバージョンのすべてのパッケージの単なるスライスです。



基本的な考え方は、チームが個々のパッケージを担当することです。 コマンドの1つのパッケージの新しいバージョンのリリースでは、依存するコンポーネントのコンテキストでそのコンポーネントのみをテストする必要があります。 異なるNuGetパッケージを混在させることができるため、コンポーネントの個別の組み合わせがうまくドッキングされない状況に陥ることがあります。 .NET Coreのディストリビューションでは、すべてのコンポーネントが相互に組み合わせてテストされるため、このような問題は発生しません。



ディストリビューションは、個々のパッケージよりも低い頻度でリリースされる予定です。 現在、年間4つの問題について検討しています。 これにより、Nastは必要なテストを実行し、エラーを修正し、コードに署名するために必要な時間の余裕を得ることができます。

.NET CoreはNuGetパッケージのセットとして配布されますが、これはプロジェクトを作成するたびにパッケージをダウンロードする必要があるという意味ではありません。 ディストリビューション用のオフラインインストーラーを提供しており、それらをVisual Studioにも含めるため、新しいプロジェクトの作成は現在と同じくらい速く、開発プロセス中にインターネット接続を必要としません。



アプリケーションローカル展開は、新機能への依存の影響を分離するのに優れていますが、すべての場合に完全に適しているとは限りません。 重要なバグ修正は、効果的であるために迅速かつ全体的に配布されなければなりません。 .NETの場合は常にそうであったように、セキュリティ更新プログラムのリリースに全面的に取り組んでいます。



.NET Frameworkの一元的な更新で過去に見た互換性の問題を回避するには、セキュリティの脆弱性のみに焦点を合わせることが重要です。 もちろん、同時に、そのような更新によってアプリケーションの動作が中断される可能性はまだわずかです。 そのため、すべてのアプリケーションが脆弱性で動作する場合よりも小さなアプリケーションのセットが動作を停止することを想定することが許容される場合、本当に重大な問題についてのみ更新をリリースします。

オープンソースとクロスプラットフォームの基盤

サポートされている形式で.NETクロスプラットフォームを作成するために、.NET Coreのソースコードを開くことにしました。



過去の経験から、オープンソースの成功はその周辺のコミュニティに依存することがわかっています。 この重要な側面は、コミュニティがコードレビューに参加し、設計ドキュメントに精通し、製品に変更を加えることを可能にするオープンで透明な開発プロセスです。



オープンソースにより、.NETの統合をクロスプラットフォーム開発に拡張できます。 コレクションなどの基本コンポーネントを数回実装する必要がある状況は、エコシステムに悪影響を及ぼします。 .NET Coreの目標は、Windows、Linux、およびMac OSXを含むすべてのプラットフォームでコードを作成および保守するために使用できる単一のコードベースを持つことです。



もちろん、ファイルシステムなどの個々のコンポーネントには、個別の実装が必要です。 NuGetによる配信モデルでは、これらの違いを無視できます。 各環境にさまざまな実装を提供する単一のNuGetパッケージを使用できます。 ただし、ここで重要な点は、コンポーネントの内部キッチンであることです。 開発者の観点から見ると、これは異なるプラットフォームで実行される単一のAPIです。



これを見るもう1つの方法は、オープンソースの出力が、より柔軟な方法で.NETコンポーネントをリリースするという当社のコミットメントの継続であることです。

1. オープンソースにより、「リアルタイム」で実装と開発の一般的な方向性を理解することができます
2. NuGet.orgによるパケットリリースにより、コンポーネントレベルの柔軟性が得られます
3. ディストリビューションはプラットフォームレベルの柔軟性を提供します

3つの要素すべてが存在するため、意思決定の幅広い柔軟性と成熟度を実現できます。

.NET Coreを既存のプラットフォームに接続する

.NET Coreは、後続のすべてのスタックのコアになるように設計しましたが、誰もが使用できる「単一のユニバーサルスタック」を作成するジレンマに非常に精通しています。







既存のスタックとの良好な互換性を維持しながら、将来の基盤を築くというバランスが取れているように思えます。 これらのプラットフォームのいくつかを詳しく見てみましょう。

.NET Framework 4.6

.NET Frameworkは依然としてリッチデスクトップアプリケーションを作成するための重要なプラットフォームであり、.NET Coreはそれを変更しません。



Visual Studio 2015のコンテキストでは、.NET Coreが.NET Frameworkの純粋なサブセットであることを確認することが目標です。 つまり、機能にギャップはないはずです。 Visual Studio 2015のリリースにより、.NET Coreは.NET Frameworkよりも速く成長すると予想されます。 これは、ある時点で、.NET Coreベースのプラットフォームでのみ利用可能な機会があることを意味します。



.NET Frameworkの更新を引き続きリリースします。 私たちの現在の計画には、今日と同じ頻度の新しい問題が含まれています。つまり、1年に1回程度です。 これらの更新では、.NET Coreから.NET Frameworkに革新を移植します。 ただし、単にすべての新機能を盲目的に転送するのではなく、コストと利点の分析に基づいて行います。 前述したように、.NET Frameworkのアドオンだけでも、既存のアプリケーションで問題が発生する可能性があります。 ここでの目標は、.NET Framework上の既存のアプリケーションとの互換性を損なうことなく、APIと動作の違いを最小限に抑えることです。



重要！ それどころか、投資の一部は.NET Frameworkでのみ行われます。たとえば、 WPFロードマップで発表した計画です。

モノ

皆さんの多くは、.NET Core for Monoのクロスプラットフォームの歴史が何を意味するのかと尋ねてきました。 実際、Monoプロジェクトは（再）オープンソースの.NET Framework実装です。 その結果、.NET Frameworkからの共通の豊富なAPIだけでなく、特に分解の点でそれ自体の問題もあります。



モノは生きており、広いエコシステムを持っています。 そのため、.NET Coreに関係なく、 オープンソースの使いやすいGitHubライセンスの下で.NET Framework Reference Sourceの一部もリリースしました。 これは、Monoコミュニティが.NET FrameworkとMonoの違いをなくし、同じコードを使用するのを助けるために特に行われました。 ただし、.NET Frameworkは複雑であるため、GitHubでオープンソースプロジェクトとして起動する準備ができていません。特に、変更要求を受け入れることはできません。



別の見方をすると、.NET Frameworkには実際には2つの分岐点があります。 1つのフォークはMicrosoftによって提供され、Windowsでのみ機能します。 もう1つのフォークはMonoです。これはLinuxおよびMacで使用できます。



.NET Coreを使用すると、.NETスタック全体をオープンソースプロジェクトとして開発できます。 したがって、別のフォークを維持する必要はもうありません。Monoコミュニティと共に、.NET CoreをWindows、Linux、およびMac OSXで正常に動作させます。 また、Monoコミュニティは、コンパクトな.NET Coreスタックを革新し、Microsoftが興味を持たない環境に移植することもできます。

WindowsストアとWindows Phone

Windowsストア8.1およびWindows Phone 8.1プラットフォームは、どちらも.NET Frameworkの非常に小さなサブセットです。 ただし、これらは.NET Coreのサブセットでもあります。 これにより、これらのプラットフォームの両方の実装の基礎として.NET Coreを引き続き使用できます。 , , .



, BCL API, , , ASP.NET 5. , . , .NET Framework .



BCL API Windows Store Windows Phone , .NET .NET Core.

.NET Core .NET

.NET Core .NET-, , .NET, .



, , .NET Core, , .NET Framework. : , :

• , , , - .
• , - , , #if.

«Sharing code across platforms» .



, .NET Core. , .NET Core, API. , NuGet-, .



, .NET Core, API, . - NuGet-, .



, , .NET Core.

まとめ

.NET Core – .NET-, NuGet. Mono, Windows, Linux Mac, Microsoft .



, .NET Framework . .NET Core, NuGet-, . Visual Studio , NuGet-, -.



, , NuGet-.



, , ( ), @dotnet .NET Foundation . , .

:

• ;
• .NET Framework .NET Core [ ] ;
• F# Linux ;
• - .NET (OWIN) ;
• : .NET Core ;
• .NET Core .NET Standard ;
• ASP.NET Core: -API ASP.NET Swagger .