.NET Core 2.2 の新機能What's new in .NET Core 2.2

.NET Core 2.2 には、アプリケーションの配置、ランタイム サービスのイベント処理、Azure SQL データベースに対する認証、JIT コンパイラのパフォーマンス、Main メソッド実行前のコード インジェクションに関する機能強化が含まれています。.NET Core 2.2 includes enhancements in application deployment, event handling for runtime services, authentication to Azure SQL databases, JIT compiler performance, and code injection prior to the execution of the Main method.

新しい配置モードNew deployment mode

.NET Core 2.2 以降、フレームワークに依存する実行可能ファイルを配置できます。これは .dll ファイルではなく .exe ファイルとなります。Starting with .NET Core 2.2, you can deploy framework-dependent executables, which are .exe files instead of .dll files. 機能的にはフレームワーク依存の配置と似ていますが、フレームワークに依存する実行可能ファイル (FDE) は引き続き .NET Core のシステム全体の共有バージョンに依存して実行されます。Functionally similar to framework-dependent deployments, framework-dependent executables (FDE) still rely on the presence of a shared system-wide version of .NET Core to run. アプリに含まれるものは、ご自身のコードとサードパーティの依存関係のみです。Your app contains only your code and any third-party dependencies. フレームワーク依存の配置とは異なり、FDE はプラットフォーム固有です。Unlike framework-dependent deployments, FDEs are platform-specific.

この新しい配置モードの際立った利点は、ライブラリの代わりに実行可能ファイルをビルドすることです。これは、最初に dotnet を呼び出すことなく、直接アプリを実行できることを意味します。This new deployment mode has the distinct advantage of building an executable instead of a library, which means you can run your app directly without invoking dotnet first.

コアCore

ランタイム サービスでのイベントの処理Handling events in runtime services

GC、JIT、ThreadPool などのランタイム サービスがどのようにアプリケーションで使われているのか監視して、それがアプリケーションに与えている影響を把握したい場合がよくあります。You may often want to monitor your application's use of runtime services, such as the GC, JIT, and ThreadPool, to understand how they impact your application. Windows システムでは、これは通常、現在のプロセスの ETW イベントを監視することによって行われます。 On Windows systems, this is commonly done by monitoring the ETW events of the current process. これは引き続き正常に動作しますが、権限の低い環境内、または Linux や macOS 上で実行している場合は、常に ETW を使えるとは限りません。 While this continues to work well, it's not always possible to use ETW if you're running in a low-privilege environment or on Linux or macOS. 

.NET Core 2.2 以降では、System.Diagnostics.Tracing.EventListener クラスを使って CoreCLR イベントを使えるようになりました。Starting with .NET Core 2.2, CoreCLR events can now be consumed using the System.Diagnostics.Tracing.EventListener class. これらのイベントでは、GC、JIT、ThreadPool、および相互運用などのランタイム サービスの動作が説明されます。These events describe the behavior of such runtime services as GC, JIT, ThreadPool, and interop. これらは、CoreCLR ETW プロバイダーの一部として公開されるものと同じイベントです。These are the same events that are exposed as part of the CoreCLR ETW provider.  このため、アプリケーションでは、これらのイベントを使うかトランスポート機構を使って、それらをテレメトリ集計サービスに送信できます。  This allows for applications to consume these events or use a transport mechanism to send them to a telemetry aggregation service. 次のコード サンプルでイベントをサブスクライブする方法を確認できます。You can see how to subscribe to events in the following code sample:

internal sealed class SimpleEventListener : EventListener
{
    // Called whenever an EventSource is created.
    protected override void OnEventSourceCreated(EventSource eventSource)
    {
        // Watch for the .NET runtime EventSource and enable all of its events.
        if (eventSource.Name.Equals("Microsoft-Windows-DotNETRuntime"))
        {
            EnableEvents(eventSource, EventLevel.Verbose, (EventKeywords)(-1));
        }
    }

    // Called whenever an event is written.
    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        // Write the contents of the event to the console.
        Console.WriteLine($"ThreadID = {eventData.OSThreadId} ID = {eventData.EventId} Name = {eventData.EventName}");
        for (int i = 0; i < eventData.Payload.Count; i++)
        {
            string payloadString = eventData.Payload[i]?.ToString() ?? string.Empty;
            Console.WriteLine($"\tName = \"{eventData.PayloadNames[i]}\" Value = \"{payloadString}\"");
        }
        Console.WriteLine("\n");
    }
}

さらに、.NET Core 2.2 では次の 2 つのプロパティが EventWrittenEventArgs クラスに追加され、ETW イベントに関する追加情報が提供されます。In addition, .NET Core 2.2 adds the following two properties to the EventWrittenEventArgs class to provide additional information about ETW events:

データData

SqlConnection.AccessToken プロパティを使った Azure SQL データベースに対する AAD 認証AAD authentication to Azure SQL databases with the SqlConnection.AccessToken property

.NET Core 2.2 以降では、Azure Active Directory によって発行されたアクセス トークンを、Azure SQL データベースへの認証に使用できます。Starting with .NET Core 2.2, an access token issued by Azure Active Directory can be used to authenticate to an Azure SQL database. アクセス トークンをサポートするために、SqlConnection クラスに AccessToken プロパティが追加されています。To support access tokens, the AccessToken property has been added to the SqlConnection class. AAD 認証を利用するには、バージョン 4.6 の System.Data.SqlClient NuGet パッケージをダウンロードします。To take advantage of AAD authentication, download version 4.6 of the System.Data.SqlClient NuGet package. この機能を使うために、Microsoft.IdentityModel.Clients.ActiveDirectory NuGet パッケージに含まれる .NET 用 Active Directory 認証ライブラリを使ってアクセス トークンの値を取得できます。In order to use the feature, you can obtain the access token value using the Active Directory Authentication Library for .NET contained in the Microsoft.IdentityModel.Clients.ActiveDirectory NuGet package.

JIT コンパイラの機能強化JIT compiler improvements

階層型コンパイルはオプトイン機能のままTiered compilation remains an opt-in feature

.NET Core 2.1 では、JIT コンパイラに新しいコンパイラ テクノロジである "階層型コンパイル" がオプトイン機能として実装されました。In .NET Core 2.1, the JIT compiler implemented a new compiler technology, tiered compilation, as an opt-in feature. 階層型コンパイルの目標はパフォーマンスの向上です。The goal of tiered compilation is improved performance. JIT コンパイラで実行される重要なタスクの 1 つはコード実行の最適化です。One of the important tasks performed by the JIT compiler is optimizing code execution. ただし、使用頻度の低いコード パスについては、最適化されていないコードの実行にランタイムが費やす時間よりも、コードの最適化にコンパイラが費やす時間の方が多くなる場合があります。For little-used code paths, however, the compiler may spend more time optimizing code than the runtime spends executing unoptimized code. 階層型コンパイルによって JIT コンパイルに次の 2 つのステージが導入されます。Tiered compilation introduces two stages in JIT compilation:

  • 第 1 階層: コードをできるだけ早く生成します。A first tier, which generates code as quickly as possible.

  • 第 2 階層: 頻繁に実行されるメソッドに対して、最適化されたコードを生成します。A second tier, which generates optimized code for those methods that are executed frequently. コンパイルの第 2 階層は、パフォーマンスの向上と並行して実行されます。The second tier of compilation is performed in parallel for enhanced performance.

階層型コンパイルによって得られるパフォーマンスの向上について詳しくは、「Announcing .NET Core 2.2 Preview 2」(.NET Core 2.2 Preview 2 の発表) をご覧ください。For information on the performance improvement that can result from tiered compilation, see Announcing .NET Core 2.2 Preview 2.

.NET Core 2.2 Preview 2 では、階層型コンパイルが既定で有効になっていました。In .NET Core 2.2 Preview 2, tiered compilation was enabled by default. しかし、階層型コンパイルを既定で有効にする準備はまだ整っていないと判断されました。However, we've decided that we are still not ready to enable tiered compilation by default. このため .NET Core 2.2 では、階層型コンパイルはオプトイン機能のままとなります。So in .NET Core 2.2, tiered compilation continues to be an opt-in feature. 階層型コンパイルに対するオプトインについて詳しくは、「.NET Core 2.1 の新機能」の「JIT コンパイラの機能強化」をご覧ください。For information on opting in to tiered compilation, see Jit compiler improvements in What's new in .NET Core 2.1.

ランタイムRuntime

Main メソッド実行前のコードの挿入Injecting code prior to executing the Main method

.NET Core 2.2 以降では、スタートアップ フックを使って、アプリケーションの Main メソッドを実行する前にコードを挿入できます。Starting with .NET Core 2.2, you can use a startup hook to inject code prior to running an application's Main method. スタートアップ フックを使うと、ホストはアプリケーションが配置された後に、再コンパイルしたりアプリケーションを変更したりすることなくその動作をカスタマイズできます。Startup hooks make it possible for a host to customize the behavior of applications after they have been deployed without needing to recompile or change the application.

ホスティング プロバイダーは、 System.Runtime.Loader.AssemblyLoadContext 動作など、メイン エントリ ポイントの読み込み動作に影響を与える可能性がある設定を含む、カスタム構成とポリシーを定義することが想定されています。We expect hosting providers to define custom configuration and policy, including settings that potentially influence the load behavior of the main entry point, such as the System.Runtime.Loader.AssemblyLoadContext behavior. フックは、トレースまたはテレメトリの挿入を設定するため、処理用のコールバックを設定するため、またはその他の環境依存の動作を定義するために使用できます。The hook can be used to set up tracing or telemetry injection, to set up callbacks for handling, or to define other environment-dependent behavior. フックはエントリ ポイントから独立しているため、ユーザー コードを変更する必要はありません。The hook is separate from the entry point, so that user code doesn't need to be modified.

詳細については、「Host startup hook」(スタートアップ フックのホスト) をご覧ください。See Host startup hook for more information.

関連項目See also