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

この記事では、.NET Core 3.0 の新機能について説明します。This article describes what is new in .NET Core 3.0. 最も大きな強化点の 1 つは、Windows デスクトップ アプリケーションのサポートです (Windows のみ)。One of the biggest enhancements is support for Windows desktop applications (Windows only). .NET Core 3.0 SDK コンポーネントの Windows デスクトップを使用して、Windows フォームおよび Windows Presentation Foundation (WPF) アプリケーションを移植することができます。By using the .NET Core 3.0 SDK component Windows Desktop, you can port your Windows Forms and Windows Presentation Foundation (WPF) applications. 誤解のないように言うと、Windows Desktop コンポーネントは Windows でのみサポートされており、Windows にのみ含まれています。To be clear, the Windows Desktop component is only supported and included on Windows. 詳細については、この記事で後述する「Windows デスクトップ」を参照してください。For more information, see the Windows desktop section later in this article.

.NET Core 3.0 では C# 8.0 のサポートが追加されています。.NET Core 3.0 adds support for C# 8.0. C# の拡張機能では、Visual Studio 2019 バージョン 16.3 以降、Visual Studio for Mac 8.3 以降、または Visual Studio Code を使用することを強くお勧めします。It's highly recommended that you use Visual Studio 2019 version 16.3 or newer, Visual Studio for Mac 8.3 or newer, or Visual Studio Code with the latest C# extension.

.NET Core 3.0 を今すぐダウンロードして Windows、macOS、または Linux 上で使い始めましょう。Download and get started with .NET Core 3.0 right now on Windows, macOS, or Linux.

リリースの詳細については、.NET Core 3.0 のアナウンスを参照してください。For more information about the release, see the .NET Core 3.0 announcement.

.NET Core RC1 は、運用の準備ができていると Microsoft で見なされていたもので、完全にサポートされていました。.NET Core RC1 was considered production ready by Microsoft and was fully supported. プレビュー リリースを使用している場合は、サポートを継続するために RTM バージョンに移行する必要があります。If you're using a preview release, you must move to the RTM version for continued support.

C# 8.0 の言語自体の強化Language improvements C# 8.0

C#8.0 も、このリリースの一部であり、null を許容する参照型の機能非同期ストリーム追加のパターンが含まれます。C# 8.0 is also part of this release, which includes the nullable reference types feature, async streams, and more patterns. C# 8.0 の機能の詳細については、「C# 8.0 の新機能」を参照してください。For more information about C# 8.0 features, see What's new in C# 8.0.

次のような API 機能をサポートするために、言語の機能強化が追加されました。これらについては、以下で詳細に説明します。Language enhancements were added to support the following API features detailed below:

.NET Standard 2.1.NET Standard 2.1

.NET core 3.0 では .NET Standard 2.1 が実装されます。.NET Core 3.0 implements .NET Standard 2.1. しかし、既定の dotnet new classlib テンプレートでは、引き続き .NET Standard 2.0 をターゲットとするプロジェクトが生成されます。However, the default dotnet new classlib template generates a project that still targets .NET Standard 2.0. .NET Standard 2.1 をターゲットにするには、プロジェクト ファイルを編集して TargetFramework プロパティを netstandard2.1 に変更します。To target .NET Standard 2.1, edit your project file and change the TargetFramework property to netstandard2.1:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.1</TargetFramework>
  </PropertyGroup>

</Project>

Visual Studio を使用している場合、Visual Studio 2017 では .NET Standard 2.1 または .NET Core 3.0 がサポートされていないため、Visual Studio 2019 が必要です。If you're using Visual Studio, you need Visual Studio 2019, as Visual Studio 2017 doesn't support .NET Standard 2.1 or .NET Core 3.0.

コンパイル/デプロイCompile/Deploy

既定の実行可能ファイルDefault executables

.NET Core では、既定でフレームワーク依存の実行可能ファイルが作成されるようになりました。.NET Core now builds framework-dependent executables by default. この動作は、グローバルにインストールされているバージョンの .NET Core を使用するアプリケーションの新機能です。This behavior is new for applications that use a globally installed version of .NET Core. 以前は、自己完結型の配置でのみ実行可能ファイルが生成されました。Previously, only self-contained deployments would produce an executable.

dotnet build または dotnet publish の実行中に、使用している SDK の環境およびプラットフォームと一致する実行可能ファイルが作成されます。During dotnet build or dotnet publish, an executable is created that matches the environment and platform of the SDK you're using. これらの実行可能ファイルでは、次のような他のネイティブ実行可能ファイルと同じことを期待できます。You can expect the same things with these executables as you would other native executables, such as:

  • 実行可能ファイルはダブルクリックすることができます。You can double-click on the executable.
  • Windows では myapp.exe、Linux と macOS では./myapp など、コマンド プロンプトからアプリケーションを直接起動できます。You can launch the application from a command prompt directly, such as myapp.exe on Windows, and ./myapp on Linux and macOS.

単一ファイルの実行可能ファイルSingle-file executables

dotnet publish コマンドは、プラットフォーム固有の単一ファイルの実行可能ファイルにアプリをパッケージ化することをサポートします。The dotnet publish command supports packaging your app into a platform-specific single-file executable. 実行可能ファイルは自己展開型であり、アプリの実行に必要なすべての依存関係 (ネイティブを含む) が含まれます。The executable is self-extracting and contains all dependencies (including native) that are required to run your app. アプリを初めて実行すると、アプリ名とビルド ID に基づいてアプリケーションがディレクトリに抽出されます。When the app is first run, the application is extracted to a directory based on the app name and build identifier. アプリケーションを再実行すると、起動は速くなります。Startup is faster when the application is run again. 新しいバージョンが使用されない限り、アプリケーションは自身を 2 回抽出する必要がありません。The application doesn't need to extract itself a second time unless a new version was used.

単一ファイルの実行可能ファイルを発行するには、プロジェクト内またはコマンド ラインで dotnet publish コマンドを使用して PublishSingleFile を設定します。To publish a single-file executable, set the PublishSingleFile in your project or on the command line with the dotnet publish command:

<PropertyGroup>
  <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
  <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

または-or-

dotnet publish -r win10-x64 -p:PublishSingleFile=true

単一ファイルの発行の詳細については、単一ファイル バンドラー設計のドキュメントを参照してください。For more information about single-file publishing, see the single-file bundler design document.

アセンブリのリンクAssembly linking

.NET Core 3.0 SDK に付属するツールを使うと、IL を分析し、未使用のアセンブリをトリミングすることによって、アプリのサイズを減らすことができます。The .NET core 3.0 SDK comes with a tool that can reduce the size of apps by analyzing IL and trimming unused assemblies.

自己完結型アプリには、コードの実行に必要なものがすべて含まれるので、ホスト コンピューターに .NET をインストールする必要はありません。Self-contained apps include everything needed to run your code, without requiring .NET to be installed on the host computer. ただし、多くの場合、アプリが機能するにはフレームワークの小さなサブセットのみが必要であり、使用されていない他のライブラリは削除できます。However, many times the app only requires a small subset of the framework to function, and other unused libraries could be removed.

.NET Core には、IL リンカー ツールを使ってアプリの IL をスキャンする設定が含まれるようになっています。.NET Core now includes a setting that will use the IL linker tool to scan the IL of your app. このツールでは、必要なコードが検出された後、使われていないライブラリがトリミングされます。This tool detects what code is required, and then trims unused libraries. このツールを使うと、一部のアプリの展開サイズを大幅に削減できます。This tool can significantly reduce the deployment size of some apps.

このツールを有効にするには、プロジェクトで <PublishTrimmed> 設定を追加し、自己完結型アプリを発行します。To enable this tool, add the <PublishTrimmed> setting in your project and publish a self-contained app:

<PropertyGroup>
  <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>
dotnet publish -r <rid> -c Release

たとえば、含まれている基本的な "hello world" という新しいコンソール プロジェクト テンプレートは、発行されるときに、サイズが約 70 MB になります。As an example, the basic "hello world" new console project template that is included, when published, hits about 70 MB in size. <PublishTrimmed> を使うことにより、そのサイズが約 30 MB に減ります。By using <PublishTrimmed>, that size is reduced to about 30 MB.

考慮すべき重要なこととして、リフレクションまたは関連する動的機能を使っているアプリケーションまたはフレームワーク (ASP.NET Core と WPF を含む) では、トリミングすると壊れることがよくあります。It's important to consider that applications or frameworks (including ASP.NET Core and WPF) that use reflection or related dynamic features, will often break when trimmed. このような破損が発生するのは、リンカーはこの動的な動作を認識しておらず、リフレクションに必要なフレームワークの種類を判断できないためです。This breakage occurs because the linker doesn't know about this dynamic behavior and can't determine which framework types are required for reflection. IL リンカー ツールは、このシナリオを認識するように構成できます。The IL Linker tool can be configured to be aware of this scenario.

何よりも、必ずトリミング後のアプリをテストしてください。Above all else, be sure to test your app after trimming.

IL リンカー ツールについて詳しくは、ドキュメントまたは mono/linker リポジトリをご覧ください。For more information about the IL Linker tool, see the documentation or visit the mono/linker repo.

階層型コンパイルTiered compilation

.NET Core 3.0 では、階層型コンパイル (TC) が既定で有効になりました。Tiered compilation (TC) is on by default with .NET Core 3.0. この機能により、ランタイムが状況に応じて Just-In-Time (JIT) コンパイラを使用してパフォーマンスを向上できるようになりました。This feature enables the runtime to more adaptively use the Just-In-Time (JIT) compiler to get better performance.

TC の主な利点は、低品質で高速な階層または高品質で低速な階層を使った (再) JIT メソッドが可能になることです。The main benefit of TC is to enable (re-)jitting methods with a lower-quality-but-faster tier or a higher-quality-but-slower tier. これは、起動から安定した状態まで、さまざまな実行段階を経るときに、アプリケーションのパフォーマンスを向上するために役立ちます。This helps increase performance of an application as it goes through various stages of execution, from startup through steady-state. これは、すべてのメソッドが 1 つの方法 (高品質階層と同じ) でコンパイルされ、起動時のパフォーマンスよりも安定した状態に偏っている非 TC アプローチとは対照的です。This contrasts with the non-TC approach, where every method is compiled a single way (the same as the high-quality tier), which is biased to steady-state over startup performance.

TC が有効になっている場合、起動時に呼び出されるメソッドは次のようになります。When TC is enabled, during startup for a method that is called:

  • メソッドに AOT コンパイル済みコード (ReadyToRun) がある場合は、事前に生成されたコードが使用されます。If the method has AOT-compiled code (ReadyToRun), the pregenerated code will be used.
  • それ以外の場合、メソッドは Just-In-Time になります。Otherwise, the method will be jitted. 通常、これらのメソッドは現在、値型に対してジェネリックです。Typically, these methods currently are generics over value types.
    • クイック JIT では、品質の低いコードがより迅速に生成されます。Quick JIT produces lower-quality code more quickly. クイック JIT は .NET Core 3.0 の、ループを含まないメソッドに対して既定で有効になっており、起動時に優先されます。Quick JIT is enabled by default in .NET Core 3.0 for methods that do not contain loops and is preferred during startup.
    • 完全最適化 JIT では、高品質なコードが低速で生成されます。The fully-optimizing JIT produces higher-quality code more slowly. クイック JIT が使用されないメソッド (たとえば、メソッドの属性が [MethodImpl(MethodImplOptions.AggressiveOptimization)] の場合) では、完全最適化 JIT が使用されます。For methods where Quick JIT would not be used (for example, if the method is attributed with [MethodImpl(MethodImplOptions.AggressiveOptimization)]), the fully-optimizing JIT is used.

最終的に、メソッドが何回も呼び出されると、バックグラウンドの完全最適化 JIT によって Just-In-Time が再実行されます。Eventually, after methods are called a number of times, they are re-jitted with the fully-optimizing JIT in the background.

クイック JIT によって生成されたコードは、実行速度が低下したり、より多くのメモリが割り当てられたり、より多くのスタック領域を使用したりすることがあります。Code generated by Quick JIT may run slower, allocate more memory, or use more stack space. 問題が発生した場合は、プロジェクト ファイルでこの設定を使用して、クイック JIT を無効にすることができます。If there are issues, Quick JIT may be disabled using this setting in your project file:

<PropertyGroup>
  <TieredCompilationQuickJit>false</TieredCompilationQuickJit>
</PropertyGroup>

TC を完全に無効にするには、プロジェクト ファイルでこの設定を使用します。To disable TC completely, use this setting in your project file:

<PropertyGroup>
  <TieredCompilation>false</TieredCompilation>
</PropertyGroup>

プロジェクト ファイルで上記の設定を変更した場合は、クリーン ビルドを反映する必要があります (objbin のディレクトリを削除してリビルドします)。Any changes to the above settings in the project file may require a clean build to be reflected (delete the obj and bin directories and rebuild).

ReadyToRun イメージReadyToRun images

アプリケーション アセンブリを ReadyToRun (R2R) 形式としてコンパイルすることで、.NET Core アプリケーションの起動時間を向上させることができます。You can improve the startup time of your .NET Core application by compiling your application assemblies as ReadyToRun (R2R) format. R2R とは、Ahead-Of-Time (AOT) コンパイルの一種です。R2R is a form of ahead-of-time (AOT) compilation.

R2R バイナリでは、アプリケーションの読み込み時に Just-In-Time (JIT) コンパイラで行う必要がある作業量を減らすことにより、起動時のパフォーマンスが向上します。R2R binaries improve startup performance by reducing the amount of work the just-in-time (JIT) compiler needs to do as your application loads. バイナリには、JIT で生成されるものと似たネイティブ コードが含まれます。The binaries contain similar native code compared to what the JIT would produce. ただし、R2R バイナリは、中間言語 (IL) コード (一部のシナリオでまだ必要です) と同じコードのネイティブ バージョンの両方が含まれるため、大きくなります。However, R2R binaries are larger because they contain both intermediate language (IL) code, which is still needed for some scenarios, and the native version of the same code. R2R は、Linux x64 や Windows x64 などの特定のランタイム環境 (RID) をターゲットとする自己完結型アプリを発行するときにのみ使用できます。R2R is only available when you publish a self-contained app that targets specific runtime environments (RID) such as Linux x64 or Windows x64.

ReadyToRun としてプロジェクトをコンパイルするには、次の手順を行います。To compile your project as ReadyToRun, do the following:

  1. <PublishReadyToRun> 設定をプロジェクトに追加します。Add the <PublishReadyToRun> setting to your project:

    <PropertyGroup>
      <PublishReadyToRun>true</PublishReadyToRun>
    </PropertyGroup>
    
  2. 自己完結型アプリを発行します。Publish a self-contained app. たとえば、次のコマンドでは、Windows の 64 ビット版向けの自己完結型アプリが作成されます。For example, this command creates a self-contained app for the 64-bit version of Windows:

    dotnet publish -c Release -r win-x64 --self-contained
    

クロス プラットフォーム/アーキテクチャの制限Cross platform/architecture restrictions

現在、ReadyToRun コンパイラではクロスターゲットはサポートされていません。The ReadyToRun compiler doesn't currently support cross-targeting. 特定のターゲットに対してコンパイルする必要があります。You must compile on a given target. たとえば、Windows x64 用の R2R イメージが必要な場合は、その環境で publish コマンドを実行する必要があります。For example, if you want R2R images for Windows x64, you need to run the publish command on that environment.

クロスターゲットに対する例外:Exceptions to cross-targeting:

  • Windows x64 を使って、Windows ARM32、ARM64、x86 のイメージをコンパイルできます。Windows x64 can be used to compile Windows ARM32, ARM64, and x86 images.
  • Windows x86 を使って、Windows ARM32 のイメージをコンパイルできます。Windows x86 can be used to compile Windows ARM32 images.
  • Linux x64 を使って、Linux ARM32 と ARM64 のイメージをコンパイルできます。Linux x64 can be used to compile Linux ARM32 and ARM64 images.

ランタイム/SDKRuntime/SDK

メジャーバージョンのロールフォワードMajor-version Roll Forward

.NET Core 3.0 では、アプリを最新メジャー バージョンの .NET Core にロールフォワードできるようにするオプトイン機能が導入されました。.NET Core 3.0 introduces an opt-in feature that allows your app to roll forward to the latest major version of .NET Core. さらに、ロールフォワードをアプリに適用する方法を制御する新しい設定が追加されました。Additionally, a new setting has been added to control how roll forward is applied to your app. これは、以下の方法で構成できます。This can be configured in the following ways:

  • プロジェクト ファイルのプロパティ: RollForwardProject file property: RollForward
  • ランタイム構成ファイルのプロパティ: rollForwardRuntime configuration file property: rollForward
  • 環境変数: DOTNET_ROLL_FORWARDEnvironment variable: DOTNET_ROLL_FORWARD
  • コマンドライン引数: --roll-forwardCommand-line argument: --roll-forward

次の値のいずれかを指定する必要があります。One of the following values must be specified. 設定を省略すると、Minor が既定値になります。If the setting is omitted, Minor is the default.

  • LatestPatchLatestPatch
    最新のパッチ バージョンにロールフォワードします。Roll forward to the highest patch version. これで、マイナー バージョンのロールフォワードが無効になります。This disables minor version roll forward.
  • MinorMinor
    要求されたマイナー バージョンが見つからない場合は、それよりも高い最小マイナー バージョンにロールフォワードします。Roll forward to the lowest higher minor version, if requested minor version is missing. 要求されたマイナー バージョンが存在する場合は、LatestPatch ポリシーが使用されます。If the requested minor version is present, then the LatestPatch policy is used.
  • MajorMajor
    要求されたメジャー バージョンが見つからない場合は、それよりも高い最小メジャー バージョンで最小マイナー バージョンにロールフォワードします。Roll forward to lowest higher major version, and lowest minor version, if requested major version is missing. 要求されたメジャー バージョンが存在する場合は、Minor ポリシーが使用されます。If the requested major version is present, then the Minor policy is used.
  • LatestMinorLatestMinor
    要求されたマイナー バージョンが存在する場合でも、最上位のマイナー バージョンにロールフォワードします。Roll forward to highest minor version, even if requested minor version is present. コンポーネント ホスティング シナリオを対象としています。Intended for component hosting scenarios.
  • LatestMajorLatestMajor
    要求されたメジャーが存在する場合でも、最上位のメジャー バージョンで最上位のマイナー バージョンにロールフォワードします。Roll forward to highest major and highest minor version, even if requested major is present. コンポーネント ホスティング シナリオを対象としています。Intended for component hosting scenarios.
  • DisableDisable
    ロールフォワードしません。Don't roll forward. 指定されたバージョンにのみバインドします。Only bind to specified version. このポリシーは、最新のパッチにロールフォワードする機能が無効になるため、一般的な使用にはお勧めできません。This policy isn't recommended for general use because it disables the ability to roll forward to the latest patches. この値はテスト用にのみ推奨されます。This value is only recommended for testing.

Disable の設定を除くすべての設定では、利用できる最新のパッチ バージョンが使用されます。Besides the Disable setting, all settings will use the highest available patch version.

ビルドによる依存関係のコピーBuild copies dependencies

dotnet build コマンドでは、アプリケーションの NuGet 依存関係が NuGet キャッシュからビルド出力フォルダーにコピーされるようになりました。The dotnet build command now copies NuGet dependencies for your application from the NuGet cache to the build output folder. 以前は、依存関係のコピーは dotnet publish の一部としてのみ行われていました。Previously, dependencies were only copied as part of dotnet publish.

リンクや razor ページの発行など、まだ発行が必要な操作がいくつかあります。There are some operations, like linking and razor page publishing that will still require publishing.

ローカル ツールLocal tools

.NET Core 3.0 にローカル ツールが導入されました。.NET Core 3.0 introduces local tools. ローカル ツールはグローバル ツールに似ていますが、ディスク上の特定の場所に関連付けられています。Local tools are similar to global tools but are associated with a particular location on disk. ローカル ツールはグローバルには使用できず、NuGet パッケージとして配布されます。Local tools aren't available globally and are distributed as NuGet packages.

警告

.NET Core 3.0 Preview 1 で dotnet tool restoredotnet tool install の実行などのローカル ツールを試した場合は、ローカル ツールのキャッシュ フォルダーを削除します。If you tried local tools in .NET Core 3.0 Preview 1, such as running dotnet tool restore or dotnet tool install, delete the local tools cache folder. そうしないと、ローカル ツールは新しいリリースで動作しません。Otherwise, local tools won't work on any newer release. このフォルダーは次の場所にあります。This folder is located at:

macOS、Linux の場合: rm -r $HOME/.dotnet/toolResolverCacheOn macOS, Linux: rm -r $HOME/.dotnet/toolResolverCache

Windows の場合: rmdir /s %USERPROFILE%\.dotnet\toolResolverCacheOn Windows: rmdir /s %USERPROFILE%\.dotnet\toolResolverCache

ローカル ツールは、現在のディレクトリ内のマニフェスト ファイル名 dotnet-tools.json に依存しています。Local tools rely on a manifest file name dotnet-tools.json in your current directory. このマニフェスト ファイルは、ツールをそのフォルダー下で使用できるように定義します。This manifest file defines the tools to be available at that folder and below. コードを使用するすべての人が確実に同じツールを復元して使用できるように、自分のコードと一緒にマニフェスト ファイルを配布することができます。You can distribute the manifest file with your code to ensure that anyone who works with your code can restore and use the same tools.

グローバル ツールとローカル ツールの両方で、ランタイムの互換バージョンが必要です。For both global and local tools, a compatible version of the runtime is required. 現在 NuGet.org 上にある多くのツールは、.NET Core Runtime 2.1 をターゲットとしています。Many tools currently on NuGet.org target .NET Core Runtime 2.1. グローバルにまたはローカルにこのようなツールをインストールするには、NET Core 2.1 ランタイムをインストールする必要があります。To install these tools globally or locally, you would still need to install the NET Core 2.1 Runtime.

小さいガベージ コレクションのヒープ サイズSmaller Garbage Collection heap sizes

ガベージ コレクターの既定のヒープ サイズが縮小され、.NET Core のメモリ使用量が減少しました。The Garbage Collector's default heap size has been reduced resulting in .NET Core using less memory. この変更は、最新のプロセッサ キャッシュ サイズでは、世代 0 の割り当て予算に合わせたものです。This change better aligns with the generation 0 allocation budget with modern processor cache sizes.

ガベージ コレクションのラージ ページのサポートGarbage Collection Large Page support

ラージ ページ (Linux ではヒュージ ページとも呼ばれます) は、オペレーティング システムがネイティブ ページ サイズ (多くの場合は 4K) よりも大きいメモリ領域を確立して、このようなラージ ページを要求するアプリケーションのパフォーマンスを向上できる機能です。Large Pages (also known as Huge Pages on Linux) is a feature where the operating system is able to establish memory regions larger than the native page size (often 4K) to improve performance of the application requesting these large pages.

Windows 上でラージ ページを割り当てることを選択するオプトイン機能として、GCLargePages 設定を使用してガベージ コレクターを構成できるようになりました。The Garbage Collector can now be configured with the GCLargePages setting as an opt-in feature to choose to allocate large pages on Windows.

Windows デスクトップ & COMWindows Desktop & COM

.NET Core SDK Windows インストーラー.NET Core SDK Windows Installer

Windows 用の MSI インストーラーは、.NET Core 3.0 から変更されました。The MSI installer for Windows has changed starting with .NET Core 3.0. SDK インストーラーは、SDK 機能帯リリースのアップグレードを実行するようになります。The SDK installers will now upgrade SDK feature-band releases in place. 機能帯は、バージョン番号の "パッチ" セクションの 100 番台のグループで定義されます。Feature bands are defined in the hundreds groups in the patch section of the version number. たとえば、3.0.1013.0.201 は 2 つの異なる機能帯のバージョンですが、3.0.1013.0.199 は同じ機能帯に含まれます。For example, 3.0.101 and 3.0.201 are versions in two different feature bands while 3.0.101 and 3.0.199 are in the same feature band. また、.NET Core SDK 3.0.101 をインストールすると、.NET Core SDK 3.0.100 が存在する場合はマシンから削除されます。And, when .NET Core SDK 3.0.101 is installed, .NET Core SDK 3.0.100 will be removed from the machine if it exists. 同じマシンに .NET Core SDK 3.0.200 をインストールすると、.NET Core SDK 3.0.101 は削除されません。When .NET Core SDK 3.0.200 is installed on the same machine, .NET Core SDK 3.0.101 won't be removed.

バージョン管理の詳細については、「.NET Core をバージョン管理する方法の概要」を参照してください。For more information about versioning, see Overview of how .NET Core is versioned.

Windows デスクトップWindows desktop

.NET Core 3.0 は、Windows Presentation Foundation (WPF) および Windows フォームを使用した Windows デスクトップ アプリケーションをサポートしています。.NET Core 3.0 supports Windows desktop applications using Windows Presentation Foundation (WPF) and Windows Forms. これらのフレームワークでは、Windows UI XAML ライブラリ (WinUI) の最新のコントロールと Fluent スタイルを XAML Islands 経由で使用することもできます。These frameworks also support using modern controls and Fluent styling from the Windows UI XAML Library (WinUI) via XAML islands.

Windows デスクトップ コンポーネントは、Windows .NET Core 3.0 SDK の一部です。The Windows Desktop component is part of the Windows .NET Core 3.0 SDK.

次の dotnet コマンドを使用して、新しい WPF または Windows フォーム アプリケーションを作成できます。You can create a new WPF or Windows Forms app with the following dotnet commands:

dotnet new wpf
dotnet new winforms

Visual Studio 2019 では、.NET Core 3.0 Windows フォームと WPF 用に、新しいプロジェクト テンプレートが追加されました。Visual Studio 2019 adds New Project templates for .NET Core 3.0 Windows Forms and WPF.

既存の .NET Framework アプリケーションを移植する方法の詳細については、WPF プロジェクトの移植Windows フォーム プロジェクトの移植に関する記事を参照してください。For more information about how to port an existing .NET Framework application, see Port WPF projects and Port Windows Forms projects.

WinForms の高 DPIWinForms high DPI

.NET Core Windows フォーム アプリケーションでは、Application.SetHighDpiMode(HighDpiMode) を使用して高 DPI モードを設定できます。.NET Core Windows Forms applications can set high DPI mode with Application.SetHighDpiMode(HighDpiMode). Application.Run の前の App.Manifest や P/Invoke などの他の方法で設定を指定しない限り、SetHighDpiMode メソッドによって、対応する高 DPI モードが設定されます。The SetHighDpiMode method sets the corresponding high DPI mode unless the setting has been set by other means like App.Manifest or P/Invoke before Application.Run.

System.Windows.Forms.HighDpiMode 列挙型で表される highDpiMode に使用できる値は次のとおりです。The possible highDpiMode values, as expressed by the System.Windows.Forms.HighDpiMode enum are:

  • DpiUnaware
  • SystemAware
  • PerMonitor
  • PerMonitorV2
  • DpiUnawareGdiScaled

高 DPI モードの詳細については、「Windows での高 DPI デスクトップ アプリケーション開発」をご覧ください。For more information about high DPI modes, see High DPI Desktop Application Development on Windows.

COM コンポーネントの作成Create COM components

Windows 上で、COM 呼び出し可能なマネージ コンポーネントを作成できるようになりました。On Windows, you can now create COM-callable managed components. この機能は、COM アドイン モデルに .NET Core を使用する場合と、.NET Framework にパリティを提供する場合にも重要です。This capability is critical to use .NET Core with COM add-in models and also to provide parity with .NET Framework.

COM サーバーとして mscoree.dll が使用されていた .NET Framework とは異なり、COM コンポーネントを構築すると、.NET Core によって bin ディレクトリにネイティブ ランチャー DLL が追加されます。Unlike .NET Framework where the mscoree.dll was used as the COM server, .NET Core will add a native launcher dll to the bin directory when you build your COM component.

COM コンポーネントを作成して使用する方法の例については、COM のデモに関する記事を参照してください。For an example of how to create a COM component and consume it, see the COM Demo.

Windows のネイティブ相互運用機能Windows Native Interop

Windows では、フラット C API、COM、および WinRT の形式で、質の高いネイティブ API を提供しています。Windows offers a rich native API in the form of flat C APIs, COM, and WinRT. .NET Core は P/Invoke をサポートしますが、.NET Core 3.0 では COM API の CoCreateWinRT API のアクティブ化を行う機能が追加されました。While .NET Core supports P/Invoke, .NET Core 3.0 adds the ability to CoCreate COM APIs and Activate WinRT APIs. コード例については、Excel のデモを参照してください。For a code example, see the Excel Demo.

MSIX のデプロイMSIX Deployment

MSIX は新しい Windows アプリケーション パッケージ形式です。MSIX is a new Windows application package format. これは、Windows 10 に .NET Core 3.0 のデスクトップ アプリケーションを展開するために使用できます。It can be used to deploy .NET Core 3.0 desktop applications to Windows 10.

Windows アプリケーション パッケージ プロジェクトは、Visual Studio 2019 で使用でき、自己完結型の .NET Core アプリケーションを使用して、MSIX パッケージを作成することができます。The Windows Application Packaging Project, available in Visual Studio 2019, allows you to create MSIX packages with self-contained .NET Core applications.

.NET Core プロジェクト ファイルの <RuntimeIdentifiers> プロパティで、サポートされているランタイムを指定する必要があります。The .NET Core project file must specify the supported runtimes in the <RuntimeIdentifiers> property:

<RuntimeIdentifiers>win-x86;win-x64</RuntimeIdentifiers>

Linux の機能強化Linux improvements

Linux 用 SerialPortSerialPort for Linux

.Net Core 3.0 では、Linux 上の System.IO.Ports.SerialPort に対する基本サポートを提供しています。.NET Core 3.0 provides basic support for System.IO.Ports.SerialPort on Linux.

以前の .NET Core では、Windows 上の SerialPort の使用のみをサポートしていました。Previously, .NET Core only supported using SerialPort on Windows.

Linux 上のシリアル ポートの制限付きサポートの詳細については、GitHub 問題 #33146 を参照してください。For more information about the limited support for the serial port on Linux, see GitHub issue #33146.

Docker と cgroup のメモリ制限Docker and cgroup memory Limits

Linux 上の Docker を使用した .NET Core 3.0 の実行は、cgroup のメモリ制限と適切に連携するようになりました。Running .NET Core 3.0 on Linux with Docker works better with cgroup memory limits. docker run -m のように、メモリ制限を使用して Docker コンテナーを実行すると、.NET Core の動作が変わります。Running a Docker container with memory limits, such as with docker run -m, changes how .NET Core behaves.

  • 既定のガベージ コレクター (GC) ヒープ サイズ: 最大 20 MB、またはコンテナーのメモリ制限の 75%。Default Garbage Collector (GC) heap size: maximum of 20 mb or 75% of the memory limit on the container.
  • 明示的なサイズは、cgroup 制限の絶対数または割合として設定できます。Explicit size can be set as an absolute number or percentage of cgroup limit.
  • GC ヒープあたりの最小予約セグメント サイズは 16 MB です。Minimum reserved segment size per GC heap is 16 mb. このサイズによって、マシン上に作成されるヒープ数が減ります。This size reduces the number of heaps that are created on machines.

Raspberry Pi の GPIO サポートGPIO Support for Raspberry Pi

GPIO プログラミングに使用できる 2 つのパッケージが NuGet にリリースされました。Two packages have been released to NuGet that you can use for GPIO programming:

GPIO パッケージには、GPIOSPII2C、および PWM デバイス用の API が含まれています。The GPIO packages include APIs for GPIO, SPI, I2C, and PWM devices. IoT バインディング パッケージにはデバイス バインディングが含まれています。The IoT bindings package includes device bindings. 詳細については、デバイス GitHub リポジトリを参照してください。For more information, see the devices GitHub repo.

ARM64 Linux のサポートARM64 Linux support

.NET Core 3.0 では、Linux 用の ARM64 のサポートが追加されています。.NET Core 3.0 adds support for ARM64 for Linux. 現在、ARM64 の主なユース ケースは、IoT シナリオを使用しています。The primary use case for ARM64 is currently with IoT scenarios. 詳細については、.NET Core ARM64 の状態に関する記事を参照してください。For more information, see .NET Core ARM64 Status.

ARM64 上の .NET Core 用の Docker イメージは、Alpine、Debian、および Ubuntu に使用できます。Docker images for .NET Core on ARM64 are available for Alpine, Debian, and Ubuntu.

注意

ARM64 Windows のサポートはまだ使用できません。ARM64 Windows support isn't yet available.

セキュリティSecurity

Linux 上の TLS 1.3 と OpenSSL 1.1.1TLS 1.3 & OpenSSL 1.1.1 on Linux

.NET Core では、特定の環境で使用できるようになったときに、OpenSSL 1.1.1 の TLS 1.3 のサポートを利用できるようになりました。.NET Core now takes advantage of TLS 1.3 support in OpenSSL 1.1.1, when it's available in a given environment. TLS 1.3 の場合:With TLS 1.3:

  • クライアントとサーバー間に必要なラウンド トリップ回数が減るため、接続時間が改善されます。Connection times are improved with reduced round trips required between the client and server.
  • 古い安全ではないさまざまな暗号化アルゴリズムが削除されたので、セキュリティが強化されました。Improved security because of the removal of various obsolete and insecure cryptographic algorithms.

使用できる場合、.NET Core 3.0 では Linux システム上で OpenSSL 1.1.1OpenSSL 1.1.0、または OpenSSL 1.0.2 が使用されます。When available, .NET Core 3.0 uses OpenSSL 1.1.1, OpenSSL 1.1.0, or OpenSSL 1.0.2 on a Linux system. OpenSSL 1.1.1 が使用できる場合、System.Net.Security.SslStream 型と System.Net.Http.HttpClient 型の両方が TLS 1.3 を使用します (クライアントとサーバーの両方が TLS 1.3 をサポートしている場合)。When OpenSSL 1.1.1 is available, both System.Net.Security.SslStream and System.Net.Http.HttpClient types will use TLS 1.3 (assuming both the client and server support TLS 1.3).

重要

Windows と macOS はまだ TLS 1.3 をサポートしていません。Windows and macOS do not yet support TLS 1.3. サポートされるようになったら、.NET Core 3.0 はこれらのオペレーティング システムで TLS 1.3 をサポートする予定です。.NET Core 3.0 will support TLS 1.3 on these operating systems when support becomes available.

次の C# 8.0 の例は、https://www.cloudflare.com に接続している Ubuntu 18.10 上の .NET Core 3.0 を示しています。The following C# 8.0 example demonstrates .NET Core 3.0 on Ubuntu 18.10 connecting to https://www.cloudflare.com:

using System;
using System.Net.Security;
using System.Net.Sockets;
using System.Threading.Tasks;

namespace whats_new
{
    public static class TLS
    {
        public static async Task ConnectCloudFlare()
        {
            var targetHost = "www.cloudflare.com";

            using TcpClient tcpClient = new TcpClient();

            await tcpClient.ConnectAsync(targetHost, 443);

            using SslStream sslStream = new SslStream(tcpClient.GetStream());
            
            await sslStream.AuthenticateAsClientAsync(targetHost);
            await Console.Out.WriteLineAsync($"Connected to {targetHost} with {sslStream.SslProtocol}");
        }
    }
}

暗号化の暗号Cryptography ciphers

.NET 3.0 では、AES-GCM および AES-CCM の暗号のサポートが追加され、それぞれ System.Security.Cryptography.AesGcm および System.Security.Cryptography.AesCcm で実装されています。.NET 3.0 adds support for AES-GCM and AES-CCM ciphers, implemented with System.Security.Cryptography.AesGcm and System.Security.Cryptography.AesCcm respectively. これらのアルゴリズムは、いずれも Authenticated Encryption with Association Data (AEAD) アルゴリズムです。These algorithms are both Authenticated Encryption with Association Data (AEAD) algorithms.

次のコードは、AesGcm 暗号を使用してランダム データの暗号化と復号化を行う例です。The following code demonstrates using AesGcm cipher to encrypt and decrypt random data.

using System;
using System.Linq;
using System.Security.Cryptography;

namespace whats_new
{
    public static class Cipher
    {
        public static void Run()
        {
            // key should be: pre-known, derived, or transported via another channel, such as RSA encryption
            byte[] key = new byte[16];
            RandomNumberGenerator.Fill(key);

            byte[] nonce = new byte[12];
            RandomNumberGenerator.Fill(nonce);

            // normally this would be your data
            byte[] dataToEncrypt = new byte[1234];
            byte[] associatedData = new byte[333];
            RandomNumberGenerator.Fill(dataToEncrypt);
            RandomNumberGenerator.Fill(associatedData);

            // these will be filled during the encryption
            byte[] tag = new byte[16];
            byte[] ciphertext = new byte[dataToEncrypt.Length];

            using (AesGcm aesGcm = new AesGcm(key))
            {
                aesGcm.Encrypt(nonce, dataToEncrypt, ciphertext, tag, associatedData);
            }

            // tag, nonce, ciphertext, associatedData should be sent to the other part

            byte[] decryptedData = new byte[ciphertext.Length];

            using (AesGcm aesGcm = new AesGcm(key))
            {
                aesGcm.Decrypt(nonce, ciphertext, tag, decryptedData, associatedData);
            }

            // do something with the data
            // this should always print that data is the same
            Console.WriteLine($"AES-GCM: Decrypted data is {(dataToEncrypt.SequenceEqual(decryptedData) ? "the same as" : "different than")} original data.");
        }
    }
}

暗号化キーのインポート/エクスポートCryptographic Key Import/Export

.NET Core 3.0 は、標準形式からの非対称の公開キーと秘密キーのインポートとエクスポートをサポートしています。.NET Core 3.0 supports the import and export of asymmetric public and private keys from standard formats. X.509 証明書を使用する必要はありません。You don't need to use an X.509 certificate.

RSADSAECDsaECDiffieHellman などのすべてのキー種類は、以下の形式をサポートします。All key types, such as RSA, DSA, ECDsa, and ECDiffieHellman, support the following formats:

  • 公開キーPublic Key

    • X.509 SubjectPublicKeyInfoX.509 SubjectPublicKeyInfo
  • 秘密キーPrivate key

    • PKCS#8 PrivateKeyInfoPKCS#8 PrivateKeyInfo
    • PKCS#8 EncryptedPrivateKeyInfoPKCS#8 EncryptedPrivateKeyInfo

RSA キーは以下もサポートしています。RSA keys also support:

  • 公開キーPublic Key

    • PKCS#1 RSAPublicKeyPKCS#1 RSAPublicKey
  • 秘密キーPrivate key

    • PKCS#1 RSAPrivateKeyPKCS#1 RSAPrivateKey

エクスポートメソッドからは、DER でエンコードされたバイナリ データが生成され、インポート メソッドもそのようなデータを期待します。The export methods produce DER-encoded binary data, and the import methods expect the same. キーがテキストに適した PEM 形式で格納されている場合、呼び出し元は import メソッドを呼び出す前にコンテンツを base64 でデコードする必要があります。If a key is stored in the text-friendly PEM format, the caller will need to base64-decode the content before calling an import method.

using System;
using System.Security.Cryptography;

namespace whats_new
{
    public static class RSATest
    {
        public static void Run(string keyFile)
        {
            using var rsa = RSA.Create();

            byte[] keyBytes = System.IO.File.ReadAllBytes(keyFile);
            rsa.ImportRSAPrivateKey(keyBytes, out int bytesRead);

            Console.WriteLine($"Read {bytesRead} bytes, {keyBytes.Length - bytesRead} extra byte(s) in file.");
            RSAParameters rsaParameters = rsa.ExportParameters(true);
            Console.WriteLine(BitConverter.ToString(rsaParameters.D));
        }
    }
}

PKCS#8 ファイルは System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo を使用して検査できます。また、 PFX/PKCS#12 ファイルは System.Security.Cryptography.Pkcs.Pkcs12Info を使用して検査できます。PKCS#8 files can be inspected with System.Security.Cryptography.Pkcs.Pkcs8PrivateKeyInfo and PFX/PKCS#12 files can be inspected with System.Security.Cryptography.Pkcs.Pkcs12Info. PFX/PKCS#12 ファイルは System.Security.Cryptography.Pkcs.Pkcs12Builder を使用して操作できます。PFX/PKCS#12 files can be manipulated with System.Security.Cryptography.Pkcs.Pkcs12Builder.

.NET Core 3.0 API の変更.NET Core 3.0 API changes

範囲とインデックスRanges and indices

新しい System.Index 型はインデックス作成に使用できます。The new System.Index type can be used for indexing. 先頭からカウントする int か、末尾からカウントするプレフィックス ^ 演算子 (C#) を使用して作成することができます。You can create one from an int that counts from the beginning, or with a prefix ^ operator (C#) that counts from the end:

Index i1 = 3;  // number 3 from beginning
Index i2 = ^4; // number 4 from end
int[] a = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
Console.WriteLine($"{a[i1]}, {a[i2]}"); // "3, 6"

また、System.Range 型もあります。これは開始値と終了値の 2 つの Index 値から構成され、x..y の範囲式 (C#) で記述できます。There's also the System.Range type, which consists of two Index values, one for the start and one for the end, and can be written with a x..y range expression (C#). これで、Range を使用してインデックスを付け、スライスを生成することができます。You can then index with a Range, which produces a slice:

var slice = a[i1..i2]; // { 3, 4, 5 }

詳細については、範囲とインデックスのチュートリアルを参照してください。For more information, see the ranges and indices tutorial.

非同期ストリームAsync streams

IAsyncEnumerable<T> 型は、IEnumerable<T> の新しい非同期バージョンです。The IAsyncEnumerable<T> type is a new asynchronous version of IEnumerable<T>. この言語では、その要素を使用するために IAsyncEnumerable<T> よりも await foreach を行い、要素を生成するために yield return を使用することができます。The language lets you await foreach over IAsyncEnumerable<T> to consume their elements, and use yield return to them to produce elements.

非同期ストリームの生成の両方の使用例を次に示します。The following example demonstrates both production and consumption of async streams. foreach ステートメントは非同期であり、yield return を使用して呼び出し元の非同期ストリームを生成します。The foreach statement is async and itself uses yield return to produce an async stream for callers. (yield return を使用する) このパターンは、非同期ストリームを生成するモデルに推奨されます。This pattern (using yield return) is the recommended model for producing async streams.

async IAsyncEnumerable<int> GetBigResultsAsync()
{
    await foreach (var result in GetResultsAsync())
    {
        if (result > 20) yield return result;
    }
}

await foreach を実行できるだけでなく、非同期反復子を作成することもできます。たとえば、awaityield の両方を行うことができる IAsyncEnumerable/IAsyncEnumerator を返す反復子です。In addition to being able to await foreach, you can also create async iterators, for example, an iterator that returns an IAsyncEnumerable/IAsyncEnumerator that you can both await and yield in. 破棄する必要があるオブジェクトの場合は、StreamTimer など、さまざまな BCL 型が実装する IAsyncDisposable を使用できます。For objects that need to be disposed, you can use IAsyncDisposable, which various BCL types implement, such as Stream and Timer.

詳細については、非同期ストリームのチュートリアルを参照してください。For more information, see the async streams tutorial.

IEEE 浮動小数点数IEEE Floating-point

浮動小数点 API は、IEEE 754-2008 リビジョンに準拠するように更新されます。Floating point APIs are being updated to comply with IEEE 754-2008 revision. これらの変更の目的は、すべての必要な操作を公開し、それらの動作が IEEE 仕様に準拠していることを保証することです。浮動小数点の改良の詳細については、「Floating-Point Parsing and Formatting improvements in .NET Core 3.0 (.NET Core 3.0 の浮動小数点の解析と形式の改良)」のブログ記事を参照してください。The goal of these changes is to expose all required operations and ensure that they're behaviorally compliant with the IEEE spec. For more information about floating-point improvements, see the Floating-Point Parsing and Formatting improvements in .NET Core 3.0 blog post.

次のような解析および書式設定の修正があります。Parsing and formatting fixes include:

  • 任意の長さの入力を正しく解析して丸める。Correctly parse and round inputs of any length.
  • 負のゼロを正しく解析して書式設定する。Correctly parse and format negative zero.
  • 大文字と小文字を区別しないチェックを実行し、可能な場合には省略可能な先行の + を許可することで、InfinityNaN を正しく解析する。Correctly parse Infinity and NaN by doing a case-insensitive check and allowing an optional preceding + where applicable.

新しい System.Math API には以下が含まれます。New System.Math APIs include:

  • BitIncrement(Double)BitDecrement(Double)BitIncrement(Double) and BitDecrement(Double)
    nextUp および nextDown の IEEE 演算に相当します。Corresponds to the nextUp and nextDown IEEE operations. 入力よりも大きいか小さいかを比較する最小の浮動小数点をそれぞれ返します。They return the smallest floating-point number that compares greater or lesser than the input (respectively). たとえば、Math.BitIncrement(0.0)double.Epsilon を返します。For example, Math.BitIncrement(0.0) would return double.Epsilon.

  • MaxMagnitude(Double, Double)MinMagnitude(Double, Double)MaxMagnitude(Double, Double) and MinMagnitude(Double, Double)
    maxNumMag および minNumMag の IEEE 演算に相当します。2 つの入力の大きさがより大きいまたはより小さい値をそれぞれ返します。Corresponds to the maxNumMag and minNumMag IEEE operations, they return the value that is greater or lesser in magnitude of the two inputs (respectively). たとえば、Math.MaxMagnitude(2.0, -3.0)-3.0 を返します。For example, Math.MaxMagnitude(2.0, -3.0) would return -3.0.

  • ILogB(Double)
    整数値を返す logB IEEE 演算に相当します。入力パラメーターの 2 を底とする積分対数を返します。Corresponds to the logB IEEE operation that returns an integral value, it returns the integral base-2 log of the input parameter. このメソッドは実質的に floor(log2(x)) と同じですが、最小限の丸め誤差で実行されます。This method is effectively the same as floor(log2(x)), but done with minimal rounding error.

  • ScaleB(Double, Int32)
    整数値を受け取る scaleB IEEE 演算に相当します。これは実質的に x * pow(2, n) と同じですが、最小限の丸め誤差で実行されます。Corresponds to the scaleB IEEE operation that takes an integral value, it returns effectively x * pow(2, n), but is done with minimal rounding error.

  • Log2(Double)
    log2 IEEE 演算に相当します。2 を底とする対数を返します。Corresponds to the log2 IEEE operation, it returns the base-2 logarithm. 丸め誤差を最小限に抑えます。It minimizes rounding error.

  • FusedMultiplyAdd(Double, Double, Double)
    fma IEEE 演算に相当します。融合型積和演算を実行します。Corresponds to the fma IEEE operation, it performs a fused multiply add. つまり、単一操作として (x * y) + z を実行することで、丸め誤差を最小限に抑えます。That is, it does (x * y) + z as a single operation, thereby minimizing the rounding error. 例では、FusedMultiplyAdd(1e308, 2.0, -1e308)1e308 を返します。An example would be FusedMultiplyAdd(1e308, 2.0, -1e308) which returns 1e308. 正規の (1e308 * 2.0) - 1e308double.PositiveInfinity を返します。The regular (1e308 * 2.0) - 1e308 returns double.PositiveInfinity.

  • CopySign(Double, Double)
    copySign IEEE 演算に相当します。x の値を返しますが、y の符号と共に返されます。Corresponds to the copySign IEEE operation, it returns the value of x, but with the sign of y.

.NET プラットフォーム依存性.NET Platform-Dependent Intrinsics

特定のパフォーマンス指向 CPU 命令 (SIMDビット操作命令セット) にアクセスできるようにする API が追加されました。APIs have been added that allow access to certain perf-oriented CPU instructions, such as the SIMD or Bit Manipulation instruction sets. これらの命令は、データを並列で効率的に処理するといった、特定のシナリオでパフォーマンスを大幅に向上するのに役立ちます。These instructions can help achieve significant performance improvements in certain scenarios, such as processing data efficiently in parallel.

.NET ライブラリでは、必要に応じて、パフォーマンスを向上するためにこれらの命令が使用されるようになりました。Where appropriate, the .NET libraries have begun using these instructions to improve performance.

詳細については、「.NET Platform Dependent Intrinsics (.NET プラットフォーム依存性)」を参照してください。For more information, see .NET Platform Dependent Intrinsics.

強化された .NET Core バージョン APIImproved .NET Core Version APIs

.NET Core 3.0 以降、.NET Core に提供されているバージョン API から、期待どおりの情報が返されるようになりました。Starting with .NET Core 3.0, the version APIs provided with .NET Core now return the information you expect. 次に例を示します。For example:

System.Console.WriteLine($"Environment.Version: {System.Environment.Version}");

// Old result
//   Environment.Version: 4.0.30319.42000
//
// New result
//   Environment.Version: 3.0.0
System.Console.WriteLine($"RuntimeInformation.FrameworkDescription: {System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription}");

// Old result
//   RuntimeInformation.FrameworkDescription: .NET Core 4.6.27415.71
//
// New result (notice the value includes any preview release information)
//   RuntimeInformation.FrameworkDescription: .NET Core 3.0.0-preview4-27615-11

警告

破壊的変更。Breaking change. バージョン管理スキームが変更されたので、これは技術的には破壊的変更です。This is technically a breaking change because the versioning scheme has changed.

高速な組み込み JSON のサポートFast built-in JSON support

.NET ユーザーは、Json.NET や他のよく使われている JSON ライブラリに大きく依存しています。これは今後も推奨されます。.NET users have largely relied on Json.NET and other popular JSON libraries, which continue to be good choices. Json.NET では .NET の文字列が基本のデータ型 (内部的には UTF-16) として使用されます。Json.NET uses .NET strings as its base datatype, which is UTF-16 under the hood.

新しい組み込みの JSON サポートは、高パフォーマンス、低割り当てで、Span<byte> に基づいています。The new built-in JSON support is high-performance, low allocation, and based on Span<byte>. System.Text.Json名前空間と種類の詳細については、「.NET での JSON のシリアル化 - 概要」を参照してください。For more information about the System.Text.Json namespace and types, see JSON serialization in .NET - overview. JSON シリアル化の一般的なシナリオに関するチュートリアルについては、「.NET で JSON をシリアル化および逆シリアル化する方法」を参照してください。参照してください。For tutorials on common JSON serialization scenarios, see How to serialize and deserialize JSON in .NET.

HTTP/2 のサポートHTTP/2 support

System.Net.Http.HttpClient 型は HTTP/2 プロトコルをサポートしています。The System.Net.Http.HttpClient type supports the HTTP/2 protocol. HTTP/2 が有効な場合、HTTP プロトコルのバージョンは TLS/ALPN を介してネゴシエートされ、HTTP/2 はサーバーがそれを使用することを選択した場合に使用されます。If HTTP/2 is enabled, the HTTP protocol version is negotiated via TLS/ALPN, and HTTP/2 is used if the server elects to use it.

既定のプロトコルは HTTP/1.1 のままですが、2 つの方法で HTTP/2 を有効にすることができます。The default protocol remains HTTP/1.1, but HTTP/2 can be enabled in two different ways. 1 つ目として、HTTP/2 を使うように HTTP 要求メッセージを設定することができます。First, you can set the HTTP request message to use HTTP/2:

var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") };

// HTTP/1.1 request
using (var response = await client.GetAsync("/"))
    Console.WriteLine(response.Content);

// HTTP/2 request
using (var request = new HttpRequestMessage(HttpMethod.Get, "/") { Version = new Version(2, 0) })
using (var response = await client.SendAsync(request))
    Console.WriteLine(response.Content);

2 つ目として、既定で HTTP/2 を使うように HttpClient を変更することができます。Second, you can change HttpClient to use HTTP/2 by default:

var client = new HttpClient()
{
    BaseAddress = new Uri("https://localhost:5001"),
    DefaultRequestVersion = new Version(2, 0)
};

// HTTP/2 is default
using (var response = await client.GetAsync("/"))
    Console.WriteLine(response.Content);

多くの場合、アプリケーションを開発しているときは、暗号化されていない接続を使います。Many times when you're developing an application, you want to use an unencrypted connection. ターゲット エンドポイントで HTTP/2 が使われることがわかっている場合は、HTTP/2 用の暗号化されていない接続を有効にできます。If you know the target endpoint will be using HTTP/2, you can turn on unencrypted connections for HTTP/2. 有効にするには、DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT 環境変数を 1 に設定するか、またはアプリのコンテキストで有効にします。You can turn it on by setting the DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT environment variable to 1 or by enabling it in the app context:

AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);

次の手順Next steps