ASP.NET Core 2.2 から3.0 への移行

Scott AddieRick Anderson

この記事では、既存の ASP.NET Core 2.2 プロジェクトを ASP.NET Core 3.0 に更新する方法について説明します。 新しい ASP.NET Core 3.0 プロジェクトを作成すると、次のような場合に役立ちます。

  • ASP.NET Core 2.2 コードと比較します。
  • 関連する変更を ASP.NET Core 3.0 プロジェクトにコピーします。

必須コンポーネント

global.json での .NET Core SDK バージョンの更新

ソリューションが特定の .NET Core SDK バージョンをターゲットとするファイル のglobal.js に依存している場合は、その version プロパティをコンピューターにインストールされている3.0 バージョンに更新します。

{
  "sdk": {
    "version": "3.0.100"
  }
}

プロジェクトファイルを更新する

ターゲットフレームワークを更新する

ASP.NET Core 3.0 以降は、.NET Core 上でのみ実行されます。 ターゲットフレームワークモニカー (TFM)を次のように設定し netcoreapp3.0 ます。

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

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

</Project>

古いパッケージ参照の削除

ASP.NET Core 3.0 では、多数の NuGet パッケージが生成されません。 このようなパッケージ参照は、プロジェクトファイルから削除する必要があります。 ASP.NET Core 2.2 web アプリの場合は、次のプロジェクトファイルを検討してください。

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

  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App"/>
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />
  </ItemGroup>

</Project>

ASP.NET Core 3.0 の更新されたプロジェクトファイル:

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

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

</Project>

更新された ASP.NET Core 3.0 プロジェクトファイル:

  • <PropertyGroup> では、次のことが行われます。

    • TFM をに更新します。 netcoreapp3.0
    • 要素を削除 <AspNetCoreHostingModel> します。 詳細については、このドキュメントの「 インプロセスホスティングモデル 」を参照してください。
  • <ItemGroup> では、次のことが行われます。

    • Microsoft.AspNetCore.App が削除されます。 詳細については、このドキュメントの「 Framework リファレンス 」を参照してください。
    • Microsoft.AspNetCore.Razor.Design が削除され、次の一覧のパッケージが生成されなくなりました。

生成されなくなったパッケージの完全な一覧を表示するには、次の展開リストを選択します。

生成されなくなったパッケージの一覧をクリックして展開します
  • Microsoft.AspNetCore
  • Microsoft.AspNetCore.All
  • Microsoft.AspNetCore.App
  • Microsoft.AspNetCore.Antiforgery
  • Microsoft.AspNetCore.Authentication
  • Microsoft.AspNetCore.Authentication.Abstractions
  • AspNetCore。 Cookie2$s
  • Microsoft.AspNetCore.Authentication.Core
  • Microsoft.AspNetCore.Authentication.OAuth
  • Microsoft.AspNetCore.Authorization.Policy
  • AspNetCore。 Cookieポリシー
  • Microsoft.AspNetCore.Cors
  • Microsoft.AspNetCore.Diagnostics
  • Microsoft.AspNetCore.Diagnostics.HealthChecks
  • Microsoft.AspNetCore.HostFiltering
  • Microsoft.AspNetCore.Hosting
  • Microsoft.AspNetCore.Hosting.Abstractions
  • Microsoft.AspNetCore.Hosting.Server.Abstractions
  • Microsoft.AspNetCore.Http
  • Microsoft.AspNetCore.Http.Abstractions
  • Microsoft.AspNetCore.Http.Connections
  • Microsoft.AspNetCore.Http.Extensions
  • Microsoft.AspNetCore.HttpOverrides
  • Microsoft.AspNetCore.HttpsPolicy
  • AspNetCore。Identity
  • Microsoft.AspNetCore.Localization
  • Microsoft.AspNetCore.Localization.Routing
  • Microsoft.AspNetCore.Mvc
  • Microsoft.AspNetCore.Mvc.Abstractions
  • Microsoft.AspNetCore.Mvc.Analyzers
  • Microsoft.AspNetCore.Mvc.ApiExplorer
  • Microsoft.AspNetCore.Mvc.Api.Analyzers
  • Microsoft.AspNetCore.Mvc.Core
  • Microsoft.AspNetCore.Mvc.Cors
  • Microsoft.AspNetCore.Mvc.DataAnnotations
  • Microsoft.AspNetCore.Mvc.Formatters.Json
  • Microsoft.AspNetCore.Mvc.Formatters.Xml
  • Microsoft.AspNetCore.Mvc.Localization
  • Microsoft.AspNetCore.Mvc.Razor
  • AspNetCore. Razor .ViewCompilation
  • AspNetCore。 Razorトピック
  • Microsoft.AspNetCore.Mvc.TagHelpers
  • Microsoft.AspNetCore.Mvc.ViewFeatures
  • AspNetCore。Razor
  • AspNetCore Razor .ランタイム
  • AspNetCore Razor .デザイン
  • Microsoft.AspNetCore.ResponseCaching
  • Microsoft.AspNetCore.ResponseCaching.Abstractions
  • Microsoft.AspNetCore.ResponseCompression
  • Microsoft.AspNetCore.Rewrite
  • Microsoft.AspNetCore.Routing
  • Microsoft.AspNetCore.Routing.Abstractions
  • Microsoft.AspNetCore.Server.HttpSys
  • Microsoft.AspNetCore.Server.IIS
  • Microsoft.AspNetCore.Server.IISIntegration
  • Microsoft.AspNetCore.Server.Kestrel
  • AspNetCore. Kestrel .Core
  • AspNetCore. Kestrel .Ssl
  • AspNetCore. Kestrel .Transport。抽象化
  • AspNetCore. Kestrel .Transport. Sockets
  • Microsoft.AspNetCore.Session
  • AspNetCore。SignalR
  • AspNetCore SignalR .Core
  • Microsoft.AspNetCore.StaticFiles
  • Microsoft.AspNetCore.WebSockets
  • Microsoft.AspNetCore.WebUtilities
  • Microsoft.Net.Http.Headers

壊れた変更を確認する

壊れた変更を確認する

フレームワーク リファレンス

上記の ASP.NET を通じて使用できる ASP.NET Core の機能は、共有フレームワークの一部として Microsoft.AspNetCore.App 利用できます。 共有フレームワーク は、コンピューター上にインストールされたアセンブリ (.dll ファイル) のセットであり、ランタイム コンポーネントと Targeting Pack を含みます。 詳しくは、共有フレームワークに関するページをご覧ください。

  • Microsoft.NET.Sdk.Web SDK を対象とするプロジェクトは、Microsoft.AspNetCore.App フレームワークを暗黙に参照します。

    これらのプロジェクトには、追加の参照は必要ありません。

    <Project Sdk="Microsoft.NET.Sdk.Web">
      <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
      </PropertyGroup>
        ...
    </Project>
    
  • または SDK を対象 Microsoft.NET.Sdk とする Microsoft.NET.Sdk.Razor プロジェクトでは、 に明示的な を追加する FrameworkReference 必要があります Microsoft.AspNetCore.App

    <Project Sdk="Microsoft.NET.Sdk.Razor">
      <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
      </PropertyGroup>
    
      <ItemGroup>
        <FrameworkReference Include="Microsoft.AspNetCore.App" />
      </ItemGroup>
        ...
    </Project>
    

Docker を使用したフレームワークに依存するビルド

ASP.NET Core 共有フレームワークに依存するパッケージを使用するコンソール アプリのフレームワークに依存するビルドでは、次のランタイム エラーが発生する可能性があります。

It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '3.0.0' was not found.
  - No frameworks were found.

Microsoft.AspNetCore.App は、ASP.NET Core ランタイムを含む共有フレームワークであり 、dotnet/core/aspnet Docker イメージにのみ存在します。 3.0 SDK を使用すると、共有フレームワークで使用できるライブラリの複製を含めないで、ASP.NET Core を使用してフレームワークに依存するビルドのサイズを減らします。 これは最大 18 MB の節約になる可能性がありますが、アプリを実行するには ASP.NET Core ランタイムが存在/インストールされている必要があります。

アプリが ASP.NET Core 共有フレームワークに対する依存関係 (直接または間接) を持つかどうかを確認するには、アプリのビルド/発行中に生成された runtimeconfig.json ファイルを調べてください。 次の JSON ファイルは、ASP.NET Core 共有フレームワークへの依存関係を示しています。

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "framework": {
      "name": "Microsoft.AspNetCore.App",
      "version": "3.0.0"
    },
    "configProperties": {
      "System.GC.Server": true
    }
  }
}

アプリで Docker を使用している場合は、Core 3.0 の ASP.NET を使用します。 たとえば、「 docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0 」のように入力します。

削除されたアセンブリのパッケージ参照を追加する

ASP.NET Core 3.0 では、以前にパッケージ参照の一部だったアセンブリが Microsoft.AspNetCore.App 削除されます。 削除されたアセンブリを視覚化するには、2 つの共有フレームワーク フォルダーを比較します。 たとえば、バージョン 2.2.7 と 3.0.0 の比較を次に示します。

共有フレームワーク アセンブリの比較

削除されたアセンブリによって提供される機能を引き続き使用するには、対応するパッケージの 3.0 バージョンを参照します。

スタートアップの変更

次の図は、Core 2.2 Pages Web アプリの ASP.NET 行と変更行 Razor を示しています。

ASP.NET Core 2.2 Razor Web アプリ内の削除および変更された行

上の図では、削除されたコードが赤で表示されています。 削除されたコードには、ファイルを比較する前に削除されたオプション cookie コードは表示されません。

次の図は、Core 3.0 Pages Web アプリの ASP.NET 行と変更行 Razor を示しています。

Core 3.0 Razor Web アプリで追加および変更された行 ASP.NET Core 3.0 ::no-loc::: Web アプリ

上の図では、追加されたコードが緑色で表示されています。 次の変更点について説明します。

アナライザーのサポート

以前に Microsoft.NET.Sdk.Web Microsoft.AspNetCore.Mvc.Analyzers パッケージの一部として出荷されたアナライザーを暗黙的に参照するプロジェクト。 これらを有効にするには、追加の参照は必要ありません。

アプリで以前に Microsoft.AspNetCore.Mvc.Api.Analyzersパッケージを使用して出荷されたAPIアナライザーを使用している場合は、プロジェクト ファイルを編集して、.NET Core Web SDK の一部として出荷されたアナライザーを参照します。

<Project Sdk="Microsoft.NET.Sdk.Web">
    <PropertyGroup>
        <TargetFramework>netcoreapp3.0</TargetFramework>
        <IncludeOpenAPIAnalyzers>true</IncludeOpenAPIAnalyzers>
    </PropertyGroup>

    ...
</Project>

Razor クラス ライブラリ

Razor MVC の UI コンポーネントを提供するクラス ライブラリ プロジェクトでは、プロジェクト ファイルで AddRazorSupportForMvc プロパティを設定する必要があります。

<PropertyGroup>
  <AddRazorSupportForMvc>true</AddRazorSupportForMvc>
</PropertyGroup>

インプロセス ホスティング モデル

プロジェクトの既定では 、Core 3.0 以降の ASP.NET インプロセス ホスティング モデルが使用されます。 必要に応じて、プロジェクト <AspNetCoreHostingModel> ファイルの 値が の場合は、 プロパティを削除できます InProcess

Kestrel

構成

( Kestrel Program.cs ) によって提供される Web ホスト ビルダー ConfigureWebHostDefaults に構成を移行します

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.ConfigureKestrel(serverOptions =>
            {
                // Set properties and call methods on options
            })
            .UseStartup<Startup>();
        });

アプリが ではなく を使用して手動でホストを作成 ConfigureWebHost する場合は ConfigureWebHostDefaults UseKestrel 、Web ホスト ビルダーで を呼び出します。

public static void Main(string[] args)
{
    var host = new HostBuilder()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .ConfigureWebHost(webBuilder =>
        {
            webBuilder.UseKestrel(serverOptions =>
            {
                // Set properties and call methods on options
            })
            .UseIISIntegration()
            .UseStartup<Startup>();
        })
        .Build();

    host.Run();
}

接続ミドルウェアが接続アダプターを置き換える

接続アダプター ( Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter ) が から削除されました Kestrel 。 接続アダプターを接続ミドルウェアに置き換える。 接続ミドルウェアは、ASP.NET Core パイプラインの HTTP ミドルウェアに似ていますが、下位の接続用です。 HTTPS と接続のログ:

  • 接続アダプターから接続ミドルウェアに移動されました。
  • これらの拡張メソッドは、以前のバージョンの ASP.NET Core と同様に動作します。

詳細については、記事 の 「ListenOptions.Protocols」セクションの TlsFilterConnectionHandler の例を参照 Kestrel してください

トランスポートの抽象化が移動され、公開されました

Kestrel トランスポート層は、Connections.Abstractions のパブリック インターフェイスとして公開されています。 これらの更新プログラムの一部として、次の手順を実行します。

  • Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions および関連付けられている型が削除されました。
  • NoDelay が からトランスポート ListenOptions オプションに移動されました。
  • Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions.Internal.SchedulingMode が から削除されました KestrelServerOptions

詳細については、次の GitHub リソースを参照してください。

Kestrel 要求トレーラー ヘッダー

以前のバージョンの ASP.NET Core を対象とするアプリの場合:

  • Kestrel は、HTTP/1.1 チャンク トレーラー ヘッダーを要求ヘッダー コレクションに追加します。
  • トレーラーは、要求本文が最後まで読み取った後に使用できます。

これにより、ヘッダーとトレーラー間のあいまいさについていくつかの懸念が生じ、トレーラーは 3.0 の新しいコレクション ( ) に移動されました RequestTrailerExtensions

HTTP/2 要求トレーラーは次のとおりです。

  • ASP.NET Core 2.2 では使用できません。
  • として 3.0 で使用できます RequestTrailerExtensions

これらのトレーラーにアクセスするために、新しい要求拡張メソッドが存在します。 HTTP/1.1 と同様に、要求本文が最後まで読み取った後にトレーラーを使用できます。

3.0 リリースでは、次の RequestTrailerExtensions 方法を使用できます。

  • GetDeclaredTrailers: 本文の後に Trailer 予想されるトレーラーを一覧表示する要求ヘッダーを取得します。
  • SupportsTrailers: 要求がトレーラー ヘッダーの受信をサポートしているかどうかを示します。
  • CheckTrailersAvailable: 要求がトレーラーをサポートし、読み取り可能な場合に確認します。 このチェックでは、読み取るトレーラーが存在するとは見なされます。 このメソッドによって が返された場合でも、読 true み取るトレーラーがない可能性があります。
  • GetTrailer: 要求された末尾のヘッダーを応答から取得します。 を SupportsTrailers 呼び出す前に確認します。要求が末尾のヘッダーをサポートしない場合は GetTrailer NotSupportedException が発生する可能性があります。

詳細については、「要求トレーラー を別のコレクションに置く (dotnet/AspNetCore #10410)」を参照してください

AllowSynchronousIO が無効

AllowSynchronousIO は、、、、 などの同期 I/O API を有効 HttpRequest.Body.Read または HttpResponse.Body.Write 無効にします Stream.Flush 。 これらの API は、アプリのクラッシュを引き起すスレッドのスタービレーションの原因です。 3.0 では、AllowSynchronousIO は既定で無効になっています。 詳細については、記事の 「同期 I/O」セクションを参照 Kestrel してください

同期 I/O が必要な場合は、使用されているサーバーで オプションを構成することで有効にできます (たとえば、 を使用する場合は、 を呼び出 AllowSynchronousIO ConfigureKestrel す場合 Kestrel )。 サーバー ( 、HttpSys、TestServer など) には、他のサーバーには影響しない独自の Kestrel AllowSynchronousIO オプションがあります。 同期 I/O は、 オプションを使用して、要求ごとにすべてのサーバーに対して有効 IHttpBodyControlFeature.AllowSynchronousIO にできます。

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();

if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

Dispose で同期 API を呼び出す実装または他のストリームで問題が発生した場合は、代わりに新しい TextWriter API DisposeAsync を呼び出します。

詳細については、「[アナウンス] すべてのサーバーで AllowSynchronousIO が無効になっている (dotnet/AspNetCore #7644) を参照してください

出力書式指定子のバッファリング

Newtonsoft.Jsベースの出力 XmlSerializer 書式指定子では、同期 DataContractSerializer シリアル化だけがサポートされます。 これらのフォーマットターがサーバーの AllowSynchronousIO 制限を使用するために、MVC はディスクに書き込む前に、これらの書式指定子の出力をバッファーします。 バッファー処理の結果、MVC には、これらの書式指定子を使用して応答するときに Content-Length ヘッダーが含まれます。

System.Text.Json は非同期シリアル化をサポートし、その System.Text.Json 結果、ベースの書式指定子はバッファーしません。 パフォーマンスを向上するには、このフォーマットを使用してください。

バッファリングを無効にするには、起動時にアプリケーション SuppressOutputFormatterBuffering を構成できます。

services.AddControllers(options => options.SuppressOutputFormatterBuffering = true)

構成されていない場合は、アプリケーションがランタイム例外をスロー AllowSynchronousIO する可能性があります。

Microsoft.AspNetCore.Server。 KestrelHttps アセンブリが削除されました

Core 2.1 ASP.NET では 、Microsoft.AspNetCore.Server. Kestrel.Https.dll の内容が Microsoft.AspNetCore.Server. Kestrel.Core.dllに移動されました。 これは、属性を使用した非壊れ的な更新 TypeForwardedTo でした。 3.0 の場合、空の Microsoft.AspNetCore.Server. Kestrel.Https.dllNuGet パッケージが削除されました。

Microsoft.AspNetCore.Server を参照するライブラリ Kestrel 。Httpsは、ASP.NET Core の依存関係を 2.1 以降に更新する必要があります。

Core 2.1 以降 ASP.NET をターゲットとするアプリとライブラリでは 、Microsoft.AspNetCore.Server への直接参照を削除する必要があります Kestrel 。Https パッケージ。

Newtonsoft.Js(Json.NET) のサポート

ASP.NET Core共有フレームワーク を改善するための作業の一環として、Newtonsoft.Json (Json.NET)が ASP.NET Core 共有フレームワークから削除されました。

ASP.NET Core の既定の JSON シリアライザーは System.Text.Json 、.NET Core 3.0 の新機能である です。 可能な場合は、 System.Text.Json の使用を検討してください。 パフォーマンスが高く、ライブラリの依存関係を追加する必要はない。 ただし、 System.Text.Json は新しいので、現在、アプリに必要な機能が不足している可能性があります。 詳細については、「 から に 移行する方法」をNewtonsoft.JsをSystem.Text.Jsしてください

ASP.NET Core 3.0 プロジェクトで Newtonsoft.Jsを使用 SignalR する

  • Microsoft.AspNetCore をインストールします SignalR 。Protocols.NewtonsoftJson NuGet パッケージ。

  • クライアントで、 インスタンスへのメソッド AddNewtonsoftJsonProtocol 呼び出しをチェーン HubConnectionBuilder します。

    new HubConnectionBuilder()
        .WithUrl("/chathub")
        .AddNewtonsoftJsonProtocol(...)
        .Build();
    
  • サーバーで、 のメソッド呼 AddNewtonsoftJsonProtocol び出しにメソッド呼び AddSignalR 出しをチェーンします Startup.ConfigureServices

    services.AddSignalR()
        .AddNewtonsoftJsonProtocol(...);
    

Core 3.0 MVC Newtonsoft.Jsで ASP.NET を使用する

  • パッケージをインストール Microsoft.AspNetCore.Mvc.NewtonsoftJson します。

  • を呼 Startup.ConfigureServices び出す場合は AddNewtonsoftJson を更新します。

    services.AddMvc()
        .AddNewtonsoftJson();
    

    AddNewtonsoftJson は、新しい MVC サービス登録メソッドと互換性があります。

    • AddRazorPages
    • AddControllersWithViews
    • AddControllers
    services.AddControllers()
        .AddNewtonsoftJson();
    

    Newtonsoft.Json 設定は、 の呼び出しで設定できます AddNewtonsoftJson

    services.AddMvc()
        .AddNewtonsoftJson(options =>
               options.SerializerSettings.ContractResolver =
                  new CamelCasePropertyNamesContractResolver());
    

    注: メソッドが AddNewtonsoftJson 使用できない場合は、パッケージがインストールされていることを確認 Microsoft.AspNetCore.Mvc.NewtonsoftJson します。 一般的なエラーは、パッケージではなくNewtonsoft.Js パッケージをインストール Microsoft.AspNetCore.Mvc.NewtonsoftJson する場合です。

詳細については、「ベースの JSON 形式 Newtonsoft.Jsを追加する」を参照してください

MVC サービスの登録

ASP.NET Core 3.0 では、 内に MVC シナリオを登録するための新しいオプションが追加されています Startup.ConfigureServices

の MVC シナリオに関連する 3 つの新しいトップ レベル拡張メソッド IServiceCollection を使用できます。 テンプレートでは、 の代わりにこれらの新しいメソッドが使用されます AddMvc 。 ただし、 AddMvc は以前のリリースと同様に動作し続ける。

次の例では、コントローラーと API 関連の機能のサポートが追加されますが、ビューやページは追加されていません。 API テンプレートでは、次のコードが使用されます。

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
}

次の例では、コントローラー、API 関連の機能、ビューのサポートが追加されますが、ページは追加されていません。 Web アプリケーション (MVC) テンプレートでは、次のコードを使用します。

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
}

次の例では、Pages のサポートと Razor 最小コントローラーのサポートを追加します。 Web アプリケーション テンプレートでは、次のコードを使用します。

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();
}

新しいメソッドを組み合わせて使用できます。 次の例は、Core AddMvc 2.2 の ASP.NET に相当します。

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();
    services.AddRazorPages();
}

スタートアップ コードのルーティング

アプリが または を呼び UseMvcUseSignalR す場合は、可能であれば、アプリ をエンドポイント ルーティングに 移行します。 以前のバージョンの MVC とのエンドポイント ルーティングの互換性を向上させるために、ASP.NET Core 2.2 で導入された URL 生成の変更の一部を元に戻しました。 2.2 でエンドポイント ルーティングを使用する際に問題が発生した場合は、次の例外を除き、ASP.NET Core 3.0 の機能強化を期待してください。

  • アプリで を実装または継承する場合は、 IRouter Route 代替として DynamicRouteValuesTransformer を使用します。
  • アプリが MVC 内で直接アクセスして URL を解析する場合は、 RouteData.Routers これを LinkParser.ParsePathByEndpointNameの使用に置き換できます。
    • ルート名を使用してルートを定義します。
    • LinkParser.ParsePathByEndpointName 使用し、目的のルート名を渡します。

エンドポイント ルーティングでは、 と同じルート パターン構文とルート パターン作成機能がサポートされています IRouter 。 エンドポイント ルーティングでは、 がサポートされます IRouteConstraint 。 エンドポイント ルーティング [Route] では [HttpGet] 、、、および他の MVC ルーティング属性がサポートされます。

ほとんどのアプリケーションでは、変更だけが Startup 必要です。

ure Startup.Config移行する

一般的なアドバイス:

  • UseRoutingを追加します。

  • アプリが を呼び出す UseStaticFiles 場合は、 の前に UseStaticFiles を配置します UseRouting

  • アプリで や などの認証/承認機能を使用する場合は、 と の呼び出しを、 の後、および AuthorizePage [Authorize] の前 UseAuthentication UseAuthorization UseRouting UseCors に配置します UseEndpoints

    public void Configure(IApplicationBuilder app)
    {
      ...
    
      app.UseStaticFiles();
    
      app.UseRouting();
      app.UseCors();
    
      app.UseAuthentication();
      app.UseAuthorization();
    
      app.UseEndpoints(endpoints => {
         endpoints.MapControllers();
      });
    
  • または UseMvc を に置き UseSignalR 換える UseEndpoints

  • アプリで などの CORS シナリオ を使用する場合は、 の呼び出しを [EnableCors] 、CORS を使用する他のミドルウェアの前に配置します (たとえば、および の前に配置 UseCors UseCors UseAuthentication UseAuthorization します UseEndpoints )。

  • IHostingEnvironment に置 IWebHostEnvironment き換え、 名前空間 using の ステートメントを追加 Microsoft.Extensions.Hosting します。

  • IApplicationLifetime IHostApplicationLifetime ( 名前空間) に Microsoft.Extensions.Hosting 置き換えてください。

  • EnvironmentName Environments ( 名前空間) に Microsoft.Extensions.Hosting 置き換えてください。

次のコードは、Core Startup.Configure 2.2 アプリの ASP.NET の例です。

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseStaticFiles();

    app.UseAuthentication();

    app.UseSignalR(hubs =>
    {
        hubs.MapHub<ChatHub>("/chat");
    });

    app.UseMvc(routes =>
    {
        routes.MapRoute("default", "{controller=Home}/{action=Index}/{id?}");
    });
}

前のコードを更新した Startup.Configure 後:

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseStaticFiles();

    app.UseRouting();

    app.UseCors();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<ChatHub>("/chat");
        endpoints.MapControllerRoute("default", "{controller=Home}/{action=Index}/{id?}");
    });
}

警告

ほとんどのアプリでは、 と の呼び出しが有効になるには、 と の呼び出しの UseAuthentication UseAuthorization UseCors UseRouting 間に を呼び UseEndpoints 出す必要があります。

正常性チェック

正常性チェックでは、汎用ホストとのエンドポイント ルーティングを使用します。 Startup.Configure で、エンドポイントの URL または相対パスを使用して、エンドポイント ビルダーで MapHealthChecks を呼び出します。

app.UseEndpoints(endpoints =>
{
    endpoints.MapHealthChecks("/health");
});

正常性チェックのエンドポイントは以下を行うことができます。

  • 1 つまたは複数の許可されたホスト/ポートを指定する。
  • 承認を必要とする。
  • CORS を必要とする。

詳細については、「ASP.NET Core の正常性チェック」を参照してください。

セキュリティ ミドルウェアのガイダンス

承認と CORS のサポートは、ミドルウェアアプローチを中心に 統合 されています。 これにより、これらのシナリオ全体で同じミドルウェアと機能を使用できます。 このリリースでは、更新された承認ミドルウェアが提供され、MVC コントローラーで使用される属性を理解できるよう CORS ミドルウェアが強化されています。

CORS

以前は、CORS を構成するのが難しい場合があります。 ミドルウェアは、一部の用途で使用するために提供されたが、MVC フィルターは、他の使用例ではミドルウェアなしで使用することを意図していた。 ASP.NET Core 3.0 では、CORS を必要としているすべてのアプリで、エンドポイント ルーティングと並行して CORS ミドルウェアを使用することをお勧めします。 UseCors は既定のポリシーで指定できます。また、属性を使用して、必要に応じて既定 [EnableCors] [DisableCors] のポリシーをオーバーライドできます。

次に例を示します。

  • CORS は、名前付きポリシーを持つすべてのエンドポイントに default 対して有効になっています。
  • クラス MyController は、 属性を使用して CORS を無効 [DisableCors] にします。
public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseCors("default");

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
    });
}

[DisableCors]
public class MyController : ControllerBase
{
    ...
}

承認

以前のバージョンの ASP.NET Core では、 属性を使用して承認のサポートが提供 [Authorize] されました。 承認ミドルウェアを使用できません。 Core 3.0 ASP.NET では、承認ミドルウェアが必要です。 Core Authorization Middleware ( ) ASP.NET を の直後 UseAuthorization に配置することをお勧めします UseAuthentication 。 承認ミドルウェアは、オーバーライドできる既定のポリシーを使用して構成することもできます。

この ASP.NET Core 3.0 以降では、 が で呼び出され、次の場合 UseAuthorization Startup.Configure HomeController はサインインユーザーが必要です。

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
    });
}

public class HomeController : Controller
{
    [Authorize]
    public IActionResult BuyWidgets()
    {
        ...
    }
}

エンドポイント ルーティングを使用する場合は、承認ミドルウェアを構成し、代わりに に AuthorizeFilter 依存することを推奨します。 アプリで MVC でグローバル フィルターとして を使用する場合は、 の呼び出しでポリシーを提供するコードをリファクタ AuthorizeFilter リングすることをお勧めします AddAuthorization

DefaultPolicy 認証を要求するように最初に構成されます。そのため、追加の構成は必要ありません。 次の例では、MVC エンドポイントは としてマークされ、 に基づいてすべての要求を RequireAuthorization 承認する必要があります DefaultPolicy 。 ただし、 では HomeController 、 により、ユーザーがアプリにサインインせずにアクセスできます [AllowAnonymous]

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute().RequireAuthorization();
    });
}

[AllowAnonymous]
public class HomeController : Controller
{
    ...
}

特定のエンドポイントの承認

承認は、エンドポイントの特定のクラスに対して構成することもできます。 次のコードは、グローバルを構成した MVC アプリを、承認を必要とする特定のポリシーを持つアプリ AuthorizeFilter に変換する例です。

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    static readonly string _RequireAuthenticatedUserPolicy = 
                            "RequireAuthenticatedUserPolicy";
    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddDbContext<ApplicationDbContext>(options =>
            options.UseSqlServer(
                Configuration.GetConnectionString("DefaultConnection")));
        services.AddDefaultIdentity<IdentityUser>(
                 options => options.SignIn.RequireConfirmedAccount = true)
            .AddEntityFrameworkStores<ApplicationDbContext>();

        // Pre 3.0:
        // services.AddMvc(options => options.Filters.Add(new AuthorizeFilter(...));

        services.AddControllersWithViews();
        services.AddRazorPages();
        services.AddAuthorization(o => o.AddPolicy(_RequireAuthenticatedUserPolicy,
                        builder => builder.RequireAuthenticatedUser()));

    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
            app.UseDatabaseErrorPage();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");
            app.UseHsts();
        }
        app.UseHttpsRedirection();
        app.UseStaticFiles();

        app.UseRouting();

        app.UseAuthentication();
        app.UseAuthorization();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapDefaultControllerRoute()
                .RequireAuthorization(_RequireAuthenticatedUserPolicy);
            endpoints.MapRazorPages();
        });
    }
}

ポリシーをカスタマイズできます。 は DefaultPolicy 、認証を要求するように構成されています。

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddDbContext<ApplicationDbContext>(options =>
            options.UseSqlServer(
                Configuration.GetConnectionString("DefaultConnection")));
        services.AddDefaultIdentity<IdentityUser>(
                 options => options.SignIn.RequireConfirmedAccount = true)
            .AddEntityFrameworkStores<ApplicationDbContext>();

        services.AddControllersWithViews();
        services.AddRazorPages();
        services.AddAuthorization(options =>
        {
            options.DefaultPolicy = new AuthorizationPolicyBuilder()
              .RequireAuthenticatedUser()
              .Build();
        });

    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
            app.UseDatabaseErrorPage();
        }
        else
        {
            app.UseExceptionHandler("/Home/Error");
            app.UseHsts();
        }
        app.UseHttpsRedirection();
        app.UseStaticFiles();

        app.UseRouting();

        app.UseAuthentication();
        app.UseAuthorization();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapDefaultControllerRoute().RequireAuthorization();
            endpoints.MapRazorPages();
        });
    }
}
[AllowAnonymous]
public class HomeController : Controller
{

または、 を構成せずに、または を構成することで、承認を要求するように [Authorize] すべてのエンドポイント RequireAuthorization を構成できます FallbackPolicy 。 は FallbackPolicy と異なります DefaultPolicy 。 は または によってトリガーされ、 は他のポリシーが設定されている場合 DefaultPolicy [Authorize] RequireAuthorization FallbackPolicy にトリガーされます。 FallbackPolicy は、承認なしで要求を許可するように最初に構成されます。

次の例は前の例と同じですが、 を使用して、 が指定されている場合を除くすべてのエンドポイントで常に認証 DefaultPolicy FallbackPolicy[AllowAnonymous] 要求します。

public void ConfigureServices(IServiceCollection services)
{
    ...

    services.AddAuthorization(options =>
    {
        options.FallbackPolicy = new AuthorizationPolicyBuilder()
          .RequireAuthenticatedUser()
          .Build();
    });
}

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapDefaultControllerRoute();
    });
}

[AllowAnonymous]
public class HomeController : Controller
{
    ...
}

ミドルウェアによる承認は、フレームワークが承認に関する特定の知識を持たなくても機能します。 たとえば、正常性 チェックには 承認に関する特定の知識はありません。ただし、正常性チェックでは、ミドルウェアによって構成可能な承認ポリシーを適用できます。

さらに、各エンドポイントで承認要件をカスタマイズできます。 次の例では、 で UseAuthorization 承認を処理 DefaultPolicy しますが、正常性チェック エンドポイントには /healthz ユーザーが必要 admin です。

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints
            .MapHealthChecks("/healthz")
            .RequireAuthorization(new AuthorizeAttribute(){ Roles = "admin", });
    });
}

保護は、一部のシナリオで実装されます。 エンドポイント ミドルウェアが見つからない原因で承認または CORS ポリシーがスキップされた場合、エンドポイント ミドルウェアは例外をスローします。 構成ミスに関する追加のフィードバックを提供するアナライザーのサポートが進行中です。

カスタム承認ハンドラー

アプリでカスタム承認ハンドラー を使用する場合、エンドポイント ルーティングは MVC とは異なるリソースの種類をハンドラーに渡します。 承認ハンドラー コンテキスト リソースの型 (MVC フィルターによって提供されるリソースの種類) を期待するハンドラーは、型のリソース (エンドポイント ルーティングによって承認ハンドラーに与えられるリソースの種類) を処理するために更新する AuthorizationFilterContext 必要があります RouteEndpoint

MVC では引き続きリソースが使用されます。そのため、アプリでエンドポイント ルーティング承認と共に MVC 承認フィルターを使用する場合は、両方の種類のリソースを処理 AuthorizationFilterContext する必要がある場合があります。

SignalR

ハブの SignalR マッピングは、 内で行うことになります UseEndpoints

各ハブを でマップします MapHub 。 以前のバージョンと同様に、各ハブは明示的に一覧表示されます。

次の例では、ハブの ChatHub SignalR サポートが追加されています。

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHub<ChatHub>();
    });
}

クライアントからのメッセージ サイズ制限を制御するための新しいオプションがあります。 たとえば、Startup.ConfigureServices では次のようにします。

services.AddSignalR(hubOptions =>
{
    hubOptions.MaximumReceiveMessageSize = 32768;
});

Core 2.2 ASP.NET では、 と を設定して、メッセージの最大サイズ TransportMaxBufferSize を効果的に制御できます。 Core 3.0 ASP.NET では、このオプションによって、バックプレキュアが観察される前の最大サイズだけが制御されます。

MVC コントローラー

コントローラーのマッピングは、 内で行うことになります UseEndpoints

アプリ MapControllers が属性ルーティングを使用する場合は、 を追加します。 ルーティングには、ASP.NET Core 3.0 以降の多くのフレームワークのサポートが含まれるので、属性ルーティング コントローラーの追加はオプトインです。

次の部分を探します。

  • MapControllerRoute を含む MapRoute
  • MapAreaControllerRoute を含む MapAreaRoute

ルーティングには MVC 以外のサポートが含まれるので、これらのメソッドが実行内容を明確に示す用語が変更されました。 などの従来のルート MapControllerRoute / MapAreaControllerRoute / MapDefaultControllerRoute は、追加された順序で適用されます。 より具体的なルート (エリアのルートなど) を最初に配置します。

次に例を示します。

  • MapControllers では、属性ルーティング コントローラーのサポートが追加されます。
  • MapAreaControllerRoute は、エリア内のコントローラーの従来のルートを追加します。
  • MapControllerRoute では、コントローラーの従来のルートが追加されます。
public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllers();
        endpoints.MapAreaControllerRoute(
            "admin",
            "admin",
            "Admin/{controller=Home}/{action=Index}/{id?}");
        endpoints.MapControllerRoute(
            "default", "{controller=Home}/{action=Index}/{id?}");
    });
}

コントローラー アクション名からの非同期サフィックスの削除

Core 3.0 ASP.NET Core MVC では、ASP.NET アクション名からサフィックス Async が削除されます。 ルーティングとリンクの生成の両方が、この新しい既定値の影響を受け取る。 次に例を示します。

public class ProductsController : Controller
{
    public async Task<IActionResult> ListAsync()
    {
        var model = await _dbContext.Products.ToListAsync();
        return View(model);
    }
}

Core 3.0 ASP.NET 以前:

  • 前のアクションには 、Products/ListAsync ルートでアクセス できます。

  • サフィックスを指定してリンクの生成が Async 必要です。 次に例を示します。

    <a asp-controller="Products" asp-action="ListAsync">List</a>
    

[ASP.NET Core 3.0:

  • 前のアクションには、Products/List ルート でアクセス できます。

  • リンクの生成では、サフィックスを指定する必要 Async はありません。 次に例を示します。

    <a asp-controller="Products" asp-action="List">List</a>
    

この変更は、 属性を使用して指定された名前には影響 [ActionName] を与え "されません"。 の次のコードを使用して、既定の動作を無効にすることができます Startup.ConfigureServices

services.AddMvc(options =>
    options.SuppressAsyncSuffixInActionNames = false);

以前のバージョンのルーティングとの違いに関するドキュメントで説明したように、リンクの生成にはいくつかの違いがあります (たとえば、 と同様の Url.Link API を使用します)。 次に例を示します。

  • 既定では、エンドポイント ルーティングを使用する場合、生成された URI でのルート パラメーターの大文字と小文字の区別は必ずしも保持されません。 この動作は、 インターフェイスを使用して制御 IOutboundParameterTransformer できます。
  • 無効なルート (コントローラー/アクションまたは存在しないページ) の URI を生成すると、無効な URI を生成する代わりに、エンドポイント ルーティングの下に空の文字列が生成されます。
  • アンビエント値 (現在のコンテキストからのルート パラメーター) は、エンドポイント ルーティングを使用したリンク生成では自動的には使用されません。 以前は、別のアクション (またはページ) へのリンクを生成するときに、指定されていないルート値が現在のルートアンビエント 値から推論 されました。 エンドポイント ルーティングを使用する場合は、リンクの生成中に、すべてのルート パラメーターを明示的に指定する必要があります。

Razor Pages

マッピング Razor ページが 内で実行される。 UseEndpoints

アプリ MapRazorPages で Pages を使用する場合は、 を Razor 追加します。 エンドポイント ルーティングには多くのフレームワークのサポートが含まれるので Razor 、Pages の追加がオプトインされます。

次のメソッドでは Startup.Configure 、 によって Pages MapRazorPages のサポートが Razor 追加されます。

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

エンドポイント ルーティングなしで MVC を使用する

Core 3.0 ASP.NET または で MVC を使用するには UseMvc UseMvcWithDefaultRoute 、 内で明示的なオプトインが必要です Startup.ConfigureServices 。 これは、MVC が初期化中に承認と CORS ミドルウェアに依存できるかどうかを知る必要があるからである必要があります。 アプリがサポートされていない構成を使用しようとした場合に警告するアナライザーが提供されます。

アプリでレガシ サポートが IRouter 必要な場合は、 EnableEndpointRouting で次の方法を使用して無効にします Startup.ConfigureServices

services.AddMvc(options => options.EnableEndpointRouting = false);
services.AddControllers(options => options.EnableEndpointRouting = false);
services.AddControllersWithViews(options => options.EnableEndpointRouting = false);
services.AddRazorPages().AddMvcOptions(options => options.EnableEndpointRouting = false);

正常性チェック

正常性チェックは、エンドポイント ルーティング を使用したルーターウェア として使用できます。

エンドポイント ルーティング MapHealthChecks で正常性チェックを使用するには、 を追加します。 メソッド MapHealthChecks は、 のような引数を受け取ります UseHealthChecks 。 Over を使用 MapHealthChecks する利点 UseHealthChecks は、承認を適用し、照合ポリシーをより詳細に制御できるようにすることです。

次の例で MapHealthChecks は、正常性チェックのエンドポイントに対してが呼び出され /healthz ます。

public void Configure(IApplicationBuilder app)
{
    ...

    app.UseRouting();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapHealthChecks("/healthz", new HealthCheckOptions() { });
    });
}

HostBuilder が WebHostBuilder を置き換える

ASP.NET Core 3.0 テンプレートでは、 汎用ホストを使用します。 以前のバージョンの Web ホストが使用されていました。 次のコードは、ASP.NET Core 3.0 テンプレートによって生成されたクラスを示してい Program ます。

// requires using Microsoft.AspNetCore.Hosting;
// requires using Microsoft.Extensions.Hosting;

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

次のコードは、ASP.NET Core 2.2 テンプレートで生成されたクラスを示してい Program ます。

public class Program
{
    public static void Main(string[] args)
    {
        CreateWebHostBuilder(args).Build().Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>();
}

IWebHostBuilder は3.0 に残り、は webBuilder 前のコードサンプルで見たの型です。 WebHostBuilder 今後のリリースで非推奨となり、に置き換えられ HostBuilder ます。

からへの最も重要 WebHostBuilder HostBuilder な変更は、 依存関係の挿入 (DI)です。 を使用する場合は、次のような HostBuilder のコンストラクターのみを挿入でき Startup ます。

HostBuilderDI 制約:

  • DI コンテナーを1回だけビルドできるようにします。
  • シングルトンの複数のインスタンスを解決するなど、結果として得られるオブジェクトの有効期間の問題を回避します。

詳細については、「 ASP.NET Core 3 でのスタートアップサービスインジェクションの回避」を参照してください。

AddAuthorization が別のアセンブリに移動されました

Microsoft.AspNetCore.Authorization.dll内の ASP.NET Core 2.2 およびそれより小さい AddAuthorization メソッドは次のとおりです **。

  • の名前が変更されました AddAuthorizationCore
  • Microsoft.AspNetCore.Authorization.Policy.dll に移動されました。

Microsoft.AspNetCore.Authorization.dllMicrosoft.AspNetCore.Authorization.Policy.dll の両方を使用しているアプリは影響を受けません。

Microsoft.AspNetCore.Authorization.Policy.dll を使用していないアプリは、次のいずれかの操作を行う必要があります。

  • Microsoft.AspNetCore.Authorization.Policy.dll への参照を追加します。 この方法は、ほとんどのアプリで機能しますが、すべて必要です。
  • 使用するに切り替え AddAuthorizationCore

詳細については、「の重大な変更」を参照してください AddAuthorization(o => ) #386 別のアセンブリに存在します。

Identity の UI

Identity ASP.NET Core 3.0 の UI の更新:

  • AspNetCore へのパッケージ参照を追加 します Identity 。UI
  • ページを使用しないアプリ Razor は、を呼び出す必要があり MapRazorPages ます。 このドキュメントの Razor ページを参照してください。
  • ブートストラップ4は、既定の UI フレームワークです。 IdentityUIFrameworkVersion既定値を変更するには、プロジェクトプロパティを設定します。 詳細については、 この GitHub の発表を参照してください。

SignalR

SignalRJavaScript クライアントがからに変更されました @aspnet/signalr @microsoft/signalr 。 この変更に対応するには、ファイル、ステートメント、および ECMAScript ステートメント でpackage.js の参照を変更し require import ます。

既定のプロトコルは System.Text.Json です。

System.Text.Json は、クライアントとサーバーの両方で使用される既定のハブプロトコルになりました。

Startup.ConfigureServices 、を呼び出して、 AddJsonProtocol シリアライザーオプションを設定します。

Server

services.AddSignalR(...)
        .AddJsonProtocol(options =>
        {
            options.PayloadSerializerOptions.WriteIndented = false;
        })

クライアント:

new HubConnectionBuilder()
    .WithUrl("/chathub")
    .AddJsonProtocol(options =>
    {
        options.PayloadSerializerOptions.WriteIndented = false;
    })
    .Build();

Newtonsoft.Jsに切り替えます

System.Text.Jsでサポートされていない Newtonsoft.Jsの機能を使用している場合は、に戻ることができ Newtonsoft.Json ます。 この記事の「 ASP.NET Core 3.0 SignalR プロジェクトの Newtonsoft.Jsの使用 」を参照してください。

Redis 分散キャッシュ

ASP.NET Core 3.0 以降のアプリで は、この パッケージは使用できません。 パッケージ参照を StackExchangeRedisに置き換えます。 詳細については、「分散キャッシュの ASP.NET Core」を参照してください。

ランタイムコンパイルをオプトインする

ASP.NET Core 3.0 より前では、ビューのランタイムコンパイルはフレームワークの暗黙的な機能でした。 ランタイムコンパイルは、ビューのビルド時のコンパイルを補足します。 これにより、フレームワークは、 Razor ファイルが変更されたときに、アプリ全体を再構築しなくても、ビューとページ (cshtml ファイル) をコンパイルできます。 この機能は、IDE でクイック編集を行い、ブラウザーを更新して変更を表示するシナリオをサポートしています。

ASP.NET Core 3.0 では、ランタイムコンパイルはオプトインシナリオです。 ビルド時のコンパイルは、既定で有効になっているビューのコンパイルの唯一のメカニズムです。 ランタイムは Visual Studio Code の Visual Studio または dotnet に依存して、cshtml ファイルに対する変更が検出されたときにプロジェクトをリビルドし ます 。 Visual Studio では、実行中のプロジェクト (Ctrl + F5) で .cscshtml、または razor ファイルに変更を加えた場合 (f5キー)、プロジェクトの再コンパイルがトリガーされます。

ASP.NET Core 3.0 プロジェクトでランタイムコンパイルを有効にするには:

  1. AspNetCore をインストールします。 RazorRuntimeCompilation NuGet パッケージ。

  2. Startup.ConfigureServices呼び出しのための更新 AddRazorRuntimeCompilation :

    ASP.NET Core MVC では、次のコードを使用します。

    services.AddControllersWithViews()
        .AddRazorRuntimeCompilation(...);
    

    ASP.NET Core の Razor ページでは、次のコードを使用します。

    services.AddRazorPages()
        .AddRazorRuntimeCompilation(...);
    

のサンプルでは、 https://github.com/aspnet/samples/tree/main/samples/aspnetcore/mvc/runtimecompilation 開発環境で条件付きコンパイルを有効にする例を示しています。

ファイルのコンパイルの詳細につい Razor ては、「」を参照してください Razor ASP.NET Core でのファイルのコンパイル

複数のターゲットを使用してライブラリを移行する

ライブラリは、多くの場合、複数のバージョンの ASP.NET Core をサポートする必要があります。 以前のバージョンの ASP.NET Core に対してコンパイルされたライブラリのほとんどは、問題なく動作します。 次の条件では、アプリをクロスコンパイルする必要があります。

  • ライブラリは、バイナリの 互換性に影響する変更がある機能に依存しています。
  • このライブラリでは、ASP.NET Core 3.0 の新機能を利用したいと考えています。

次に例を示します。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFrameworks>netcoreapp3.0;netstandard2.0</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp3.0'">
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
  </ItemGroup>

  <ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
    <PackageReference Include="Microsoft.AspNetCore" Version="2.1.0" />
  </ItemGroup>
</Project>

#ifdefsASP.NET Core 3.0 固有の api を有効にするには、次のように使用します。

var webRootFileProvider =
#if NETCOREAPP3_0
    GetRequiredService<IWebHostEnvironment>().WebRootFileProvider;
#elif NETSTANDARD2_0
    GetRequiredService<IHostingEnvironment>().WebRootFileProvider;
#else
#error unknown target framework
#endif

クラスライブラリで ASP.NET Core Api を使用する方法の詳細については、「」を参照してください クラス ライブラリで ASP.NET Core API を使用する

その他の変更

.NET Core 3.0 以降の検証システムでは null 非許容型のパラメーターまたはバインド プロパティは [Required] 属性を持つものとして処理されます。 詳細については、「 [Required] 属性」を参照してください。

公開

プロジェクトディレクトリの bin フォルダーと obj フォルダーを削除します。

TestServer

TestServer汎用ホストで直接使用するアプリの場合、でを作成し TestServer IWebHostBuilder ConfigureWebHost ます。

[Fact]
public async Task GenericCreateAndStartHost_GetTestServer()
{
    using var host = await new HostBuilder()
        .ConfigureWebHost(webBuilder =>
        {
            webBuilder
                .UseTestServer()
                .Configure(app => { });
        })
    .StartAsync();

    var response = await host.GetTestServer().CreateClient().GetAsync("/");

    Assert.Equal(HttpStatusCode.NotFound, response.StatusCode);
}

互換性に影響する API の変更

重大な変更の確認:

キャッチオールパラメーターを使用したエンドポイントルーティング

警告

ルーティングで バグが原因で、キャッチオール パラメーターがルートと正しく一致しない可能性があります。 このバグの影響を受けるアプリには、次の特性があります。

  • キャッチオール ルート (たとえば、{**slug}")
  • キャッチオール ルートが、一致すべき要求と一致しません。
  • 他のルートを削除すると、キャッチオール ルートが機能し始めます。

このバグが発生するケースの例については、GitHub のバグ 18677 および 16579 を参照してください。

このバグのオプトイン修正は .NET Core 3.1.301 SDK 以降に含まれています。 次のコードにより、このバグを修正する内部スイッチが設定されます。

public static void Main(string[] args)
{
   AppContext.SetSwitch("Microsoft.AspNetCore.Routing.UseCorrectCatchAllBehavior", 
                         true);
   CreateHostBuilder(args).Build().Run();
}
// Remaining code removed for brevity.

Azure App Service の .NET Core 3.0

Azure App Service への .NET Core のロールアウトが完了しました。 .NET Core 3.0 は、すべての Azure App Service データセンターで利用できます。