Project.jsonの変更

先週、 .NET CoreとASP.NETのRC2 / RTMリリーススケジュールを発表しました 。 RC2をリリースしたので、.NET Coreを.xproj / project.jsonなどのプロジェクトから.csproj / MSBuildに移行することについて、もう少し詳しく説明します。



Msbuild



ASP.NETチームがASP.NET 5(ASP.NET Coreは既に)で作業を開始したとき、主な目標の1つは、Windows、Mac、およびLinuxでアプリケーションを簡単に作成および開発する能力でした。 これには、.xproj / project.jsonプロジェクトシステムの作成が必要でした。 主な機能は次のとおりです。



開発を継続し、.NET Core自体の役割を拡張しました。



これはproject.jsonにどのように影響しますか? プラットフォームとしての.NETの重要な原則の1つは、.NETアプリケーションのすべてのモデル(WinForms、WPF、UWP、ASP.NET、IOS、Androidなど)の開発者間でコードを共有する機能です。 これにより、多くの問題が発生します。project.jsonはWebアプリケーションとクラスライブラリの作成には最適ですが、同時に他のアプリケーションモデルとの統合はできません。



2つの方法がありました。 1つ目は、すべての.NETプロジェクトをproject.jsonを使用するように移植することでした。 これには、Visual Studio、Xamarin、およびUnityなどのパートナーのすべてのタイプのプロジェクトに影響するツールを作成/変更する必要があります。 project.jsonを拡張して、これらの各タイプのプロジェクトに必要なすべてのタイプのビルドをサポートし、移行履歴を提供する必要があります。 別の方法は、.xprojプロジェクトと.csprojプロジェクトの間にブリッジを作成し、後者がVisual StudioとXamarin Studioの.xprojプロジェクトを参照できるようにすることです。 このアプローチには欠点があります。たとえば、クライアントがプロジェクトを作成する場合、.xprojと.csprojのどちらかを選択する必要があり、オプションと複雑さが追加されるだけです。



上記のオプションを検討した結果、.NET Coreプロジェクトを.csproj / MSBuildに移行する方が簡単になり、すべての.NETプロジェクトで同じツールキットとビルドシステムを使用できるようになることが明らかになりました。



同時に、project.jsonのメリットを放棄する予定はありません。 そのため、不足している機能をサポートするために.csprojを拡張する予定です。



なぜなら すべての.NETは同じツールセットを使用するため、後からMSBuildを改善できます。 XMLではなくJSONのサポートに関してクライアントやコミュニティからフィードバックをリクエストし、ツールなどで生成される過度に詳細なファイルの数を減らします。 1つのスタックが使用される場合、これらの機能強化はすべての.NETプロジェクトで機能します。



最初の波は、Visual Studio“ 15” RTMの変更です。.NETCoreプロジェクトを開くと、Visual Studioは自動的に.xprojを.csprojに変換し、project.jsonから構成ファイルと.csprojファイル自体にデータを転送します。 コンソール.NETユーティリティを使用してアプリケーションを変換するツールも提供します。



次の波はVisual Studio“ 15”のリリース後であり、プロジェクトの構築とそれらの操作の経験をさらに改善することを目的としています。



オープンで開発



.NET CoreとASP.NET Coreは、完全にオープンに開発された最初の.NETプロジェクトです。 最も可能性が高いのは、チームが最良の製品を作成するために実験しているため、すべての変更が表示されないことです。 GitHub、コミュニティ、さらにはこのブログの間で、透明性の適切なバランスを見つけようとしています。 今後は、何が変化しているのか、なぜ変化しているのかについて、より多くのコンテキストを提供する準備ができているため、このブログを通じて主な変更点を最初に発表します。



次は何ですか



来週、.NET Standardについて書きます。すべてのタイプの.NETプロジェクトでコード共有をより簡単にする方法です。




All Articles