Microsoft .NET5を理解する

マイクロソフトの2020年の開発者戦略の重要なテーマの1つは、おそらく世代間のシフトとして最もよく考えられています。これは比較的スムーズな引き継ぎであり、新旧の作業方法の統合として組み立てられています。しかし、最終的には、Project Reunion、WinUI 3、または.NET 5の発売のいずれであっても、新しいテクノロジーは前進し、古いテクノロジーは残されます。

それは悪いことではありません。私たちは多くの理由で物事を行うための新しい方法を開発しますが、それらはしばしば1つの重要なポイントの周りで合体します:新しい方法がより良いです。これは、古いツールでは不可能だった問題を解決し、元のソリューションが定義されていたときに尋ねられなかった新しい質問に答えます。

新しい世界のための新しい.NET

これらすべての理由は、.NETFrameworkから.NET5への移行で一緒になります。20年前に元の.NETFrameworkが定義されていたとき、厳密に定義されたIT環境でモノリシッククライアントサーバーアプリケーションを構築しました。現在、急速に変化するインフラストラクチャを使用して、軽量の分散型マイクロサービスとクロスプラットフォームのモバイルアプリを組み合わせて構築しています。決まり文句にもかかわらず、それはまったく新しい世界です。

.NET Coreは、このような作業方法のために設計されました。クロスプラットフォームは、その初期の段階から、新しいクラウドファーストのモバイルアプリケーションと、従来の.NET開発パターンおよびプラクティスをサポートすることを目的としています。3つのメジャーリリースを通じてますます多くのAPIを採用し、.NET Standardライブラリが、プロジェクトの共有を容易にするコードの共通ターゲット、.NET Framework、およびXamarinを提供し始めたとき。

.NET 5:将来の開発への道

技術的には、この新しいリリースは.NET Core 4である必要がありますが、Microsoftは、.NET Frameworkの現在のリリースとの混同を避けるために、バージョン番号をスキップしています。同時に、より高いバージョン番号に移動し、名前からCoreを削除することは、これがすべての.NET開発の次のステップであることを示しています。同じバージョン番号のレガシープロジェクトがまだ存在するため、ASP.NET Core5.0とEntityFramework Core5の2つのプロジェクトは引き続きコア名を保持します。

これは重要なマイルストーンであり、.NET 5ですべての新しいプロジェクトを開始し、既存のコードを.NETFrameworkから移動することを検討する必要があるポイントを示しています。 Microsoftは.NETFrameworkからサポートを削除していませんが、メンテナンスモードであり、将来のポイントリリースで新しい機能を取得することはありません。すべての新しいAPIとコミュニティ開発は.NET5(および2021の長期サポート.NET 6)で行われます。

WebフォームやWindowsCommunication Foundationなどの一部の使い慣れたテクノロジは.NET5で非推奨になります。それらをまだ使用している場合は、今のところ.NET Framework 4をそのまま使用し、サポートされている新しいテクノロジへの移行を計画することをお勧めします。 ASP.NETのRazorPagesまたはgRPCとして。同様のAPIを提供する代替フレームワークのコミュニティサポートの計画がありますが、新しいアプローチを使用すると、将来を見据えたコードが役立ち、クロスプラットフォームでの作業が容易になります。

.NET 5の少し紛らわしい側面の1つは、.NETStandardライブラリとの連携方法です。それらは、.NET 5ターゲットフレームワークモニカ(TFM)のサブセットになっているため、.NET 5コードで直接参照する必要はありませんが、なくなることはありません。この新しいTFMは古い置き換えるnetcoreapp netstandard 、あなたがニーズをフレームワーク間で共有されるようにするコードを書いているならば、あなたはまだ互換性の目的のために、.NETの標準2.0 TFMを使用することができますが、TFMSを。ただし、ほとんどの場合、.NET 5環境でのみ作業している可能性が高いため、net5.0TFM宣言を安全に実行できます。

.NET5の使用を開始する

.NET 5.0は、C#とF#の両方の新しいバージョンを含む、同じ使い慣れた言語のセットを引き続きホストします。これらは多くの新機能を追加し、Visual Studio 16.8の一部として、または更新されたC#Visual StudioCode拡張機能とともに提供されます。 Microsoftは、フレームワークとそのすべての実装(Monoの多くと同様)を単一のGitHubリポジトリに移動し、開発を統合し、すべてのバージョンが同じ基本機能を持つようにしました。 Microsoftが.NET6に移行すると、Xamarinを含む他の高レベルの実装が導入されます。

新しい.NETは、元の共通言語ランタイム用に開発されたジャストインタイムコンパイラ技術に基づいています。新しいCoreCLRは、複数のプロセッサアーキテクチャ間で機能しながら、パフォーマンスを向上させ続けます。 AppleのM1ARMベースのプロセッサの登場により、.NET for macOSで記述されたコードは、IntelベースとARMベースの両方のハードウェアでネイティブバイナリとして実行されるため、コードはエミュレーションの第2層を通過する必要がなくなります。 ARM64のサポートにより、Microsoft独自のSQ1およびSQ2プロセッサの機能を利用して、.NET5アプリケーションをARMハードウェア上のWindowsでネイティブに実行できるようになります。

Web Assemblyやモバイルオペレーティングシステムなどの一部のシナリオでは、プリコンパイルされたコードが必要です。.NET5は、JITツールとともに事前コンパイルを提供します。AOTコンパイラはすべての開発環境で利用できるようになり、Uno Platformチームは、以前のWeb Assembly言語インタープリターの7〜15倍の、WebAssemblyサポートの大幅な速度向上をすでに確認しています。

リソースが限られたスマートウォッチやIoTハードウェアなど、迅速な起動とメモリフットプリントの削減が必要なアプリのオプションとして、AOTコンパイラを利用できるようにする計画があります。もう1つのオプションは、単一ファイルの展開です。アプリケーションに必要なすべて(ランタイムを含む)が単一のパッケージにバンドルされているため、.NETアプリケーションをコンテナーまたはWindows以外のシステムに簡単にデプロイできます。

新しい.NETを単独で見るべきではありません。Blazorを使用したWebAssemblyおよびMAUI(マルチプラットフォームアプリUI)を使用したクロスプラットフォームUI開発に関する追加の開発も重要です。これらのテクノロジーを組み合わせて使用​​することで、Raspberry PiクラスのハードウェアからAndroidスマートフォン、AWSとAzureで実行されるKubernetesでホストされるコンテナーまで、.NET5でターゲットにできないものはほとんどありません。

2021年に.NET6に移行

重要な点の1つは、これはプロセスのもう1つのステップにすぎないということです。 .NET 5は、Windows APIをOSから分離し、WinRTAPIとWin32APIをProjectReunionで統合し、UIレイヤーとしてWinUI3とMAUIの両方に移行するための重要なテクノロジです。その作業の多くは、これらのプロジェクトの多くのターゲットである.NET6の2021年のリリースでも継続されます。 .NET6が移行を開始するのを待つ必要はありません。開始するのが早ければ早いほどよいので、発生する可能性のある問題に対処する時間を与えることができます。

.NET 5は、.NETジャーニーの次の段階の最初のステップと見なす必要があります。ここでは、すべてのレガシーコードを取得し、移植と更新によって何を進める必要があるか、何を完全に置き換える必要があるかを判断する必要があります。 。2020年が終わると、2021年の開発スケジュールを計画する可能性があります。そのことを念頭に置いて、.NET 5は、Windowsリリース、またはWindowsにまったく縛られなくなった、はるかに動きの速い未来に向けてソフトウェア資産を準備するために何をする必要があるかに焦点を当てるのに役立つレンズである必要があります。