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

この記事では、ASP.NET Core 3.0 の最も大きな変更点について説明します。また、その変更点のドキュメントへのリンクも示します。This article highlights the most significant changes in ASP.NET Core 3.0 with links to relevant documentation.

Blazor

Blazor は、.NET を使って対話型のクライアント側 Web UI を構築するための ASP.NET Core の新しいフレームワークです。Blazor is a new framework in ASP.NET Core for building interactive client-side web UI with .NET:

  • JavaScript の代わりに C# を使って、優れた対話型 UI を作成します。Create rich interactive UIs using C# instead of JavaScript.
  • .NET で記述された、サーバー側とクライアント側のアプリのロジックを共有します。Share server-side and client-side app logic written in .NET.
  • モバイル ブラウザーを含めた広範なブラウザーのサポートのために、HTML および CSS として UI をレンダリングします。Render the UI as HTML and CSS for wide browser support, including mobile browsers.

Blazor フレームワークでサポートされるシナリオ:Blazor framework supported scenarios:

  • 再利用可能な UI コンポーネント (Razor コンポーネント)Reusable UI components (Razor components)
  • クライアント側のルーティングClient-side routing
  • コンポーネントのレイアウトComponent layouts
  • 依存関係の挿入のサポートSupport for dependency injection
  • フォームと検証Forms and validation
  • Razor クラス ライブラリを使用したコンポーネント ライブラリの構築Build component libraries with Razor class libraries
  • JavaScript 相互運用JavaScript interop

詳細については、「ASP.NET Core Blazor の概要」を参照してください。For more information, see ASP.NET Core Blazor の概要.

Blazor Server

Blazor では、UI の更新プログラムを適用する方法からコンポーネントのレンダリング ロジックが分離されます。Blazor decouples component rendering logic from how UI updates are applied. Blazor Server では、ASP.NET Core アプリでサーバー上の Razor コンポーネントをホストするためのサポートが提供されます。Blazor Server provides support for hosting Razor components on the server in an ASP.NET Core app. UI の更新は SignalR 接続を介して処理されます。UI updates are handled over a SignalR connection. Blazor Server は ASP.NET Core 3.0 でサポートされています。Blazor Server is supported in ASP.NET Core 3.0.

Blazor WebAssembly (プレビュー)Blazor WebAssembly (Preview)

Blazor アプリは、WebAssembly ベースの .NET ランタイムを使用してブラウザーで直接実行することもできます。Blazor apps can also be run directly in the browser using a WebAssembly-based .NET runtime. Blazor WebAssembly はプレビュー段階であり、ASP.NET Core 3.0 ではサポートされて "いません"。Blazor WebAssembly is in preview and not supported in ASP.NET Core 3.0. Blazor WebAssembly は、ASP.NET Core の今後のリリースでサポートされる予定です。Blazor WebAssembly will be supported in a future release of ASP.NET Core.

Razor のコンポーネントRazor components

Blazor アプリはコンポーネントから構築されています。Blazor apps are built from components. コンポーネントは、ページ、ダイアログ、フォームなどのユーザー インターフェイス (UI) の自己完結型チャンクです。Components are self-contained chunks of user interface (UI), such as a page, dialog, or form. コンポーネントは、UI レンダリング ロジックとクライアント側のイベント ハンドラーを定義する通常の .NET クラスです。Components are normal .NET classes that define UI rendering logic and client-side event handlers. JavaScript を使用せずに、機能豊富な対話型 Web アプリを作成できます。You can create rich interactive web apps without JavaScript.

通常、Blazor のコンポーネントは、HTML と C# が自然に融合している Razor 構文を使用して作成されます。Components in Blazor are typically authored using Razor syntax, a natural blend of HTML and C#. Razor コンポーネントは、両方とも Razor を使用するという点で Razor Pages および MVC ビューに似ています。Razor components are similar to Razor Pages and MVC views in that they both use Razor. 要求 - 応答モデルに基づくページやビューとは異なり、コンポーネントは特に UI コンポジションを処理するために使われます。Unlike pages and views, which are based on a request-response model, components are used specifically for handling UI composition.

gRPCgRPC

gRPC:gRPC:

  • 広く普及している高パフォーマンス RPC (リモート プロシージャ コール) フレームワークです。Is a popular, high-performance RPC (remote procedure call) framework.

  • API 開発に対して独特のコントラクト優先のアプローチを提供します。Offers an opinionated contract-first approach to API development.

  • 次のような最新テクノロジを使用します。Uses modern technologies such as:

    • HTTP/2 (転送用)。HTTP/2 for transport.
    • プロトコル バッファー (インターフェイス記述言語として)。Protocol Buffers as the interface description language.
    • バイナリ シリアル化形式。Binary serialization format.
  • 次のような機能があります。Provides features such as:

    • 認証Authentication
    • 双方向のストリーミングおよびフロー制御。Bidirectional streaming and flow control.
    • キャンセルおよびタイムアウト。Cancellation and timeouts.

ASP.NET Core 3.0 の gRPC 機能には次のものが含まれます。gRPC functionality in ASP.NET Core 3.0 includes:

  • Grpc.AspNetCore:gRPC サービスをホストするための ASP.NET Core フレームワーク。Grpc.AspNetCore: An ASP.NET Core framework for hosting gRPC services. ASP.NET Core 上の gRPC は、ログ記録、依存関係の挿入 (DI)、認証、承認など、標準の ASP.NET Core 機能と完全に統合されています。gRPC on ASP.NET Core integrates with standard ASP.NET Core features like logging, dependency injection (DI), authentication, and authorization.
  • Grpc.Net.Client:使い慣れた HttpClient に基づいて構築される .NET Core 用の gRPC クライアント。Grpc.Net.Client: A gRPC client for .NET Core that builds upon the familiar HttpClient.
  • Grpc.Net.ClientFactory: HttpClientFactory と gRPC クライアントの統合。Grpc.Net.ClientFactory: gRPC client integration with HttpClientFactory.

詳細については、「.NET Core の gRPC の概要」を参照してください。For more information, see .NET Core の gRPC の概要.

SignalR

移行の手順については、SignalR コードの更新に関するページを参照してください。See Update SignalR code for migration instructions. 現在、SignalR は System.Text.Json を使用して JSON メッセージのシリアル化および逆シリアル化を行います。SignalR now uses System.Text.Json to serialize/deserialize JSON messages. Newtonsoft.Json ベースのシリアライザーを復元する手順については、「Newtonsoft.Json に切り替える」を参照してください。See Switch to Newtonsoft.Json for instructions to restore the Newtonsoft.Json-based serializer.

SignalR 対応の JavaScript および .NET クライアントには、自動再接続のサポートが追加されました。In the JavaScript and .NET Clients for SignalR, support was added for automatic reconnection. 既定では、クライアントはすぐに再接続を試行し、必要に応じて 2 秒後、10 秒後、30 秒後に再試行します。By default, the client tries to reconnect immediately and retry after 2, 10, and 30 seconds if necessary. クライアントが正常に再接続すると、新しい接続 ID を受け取ります。If the client successfully reconnects, it receives a new connection ID. 自動再接続はオプトインです。Automatic reconnect is opt-in:

const connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub")
    .withAutomaticReconnect()
    .build();

再接続の間隔は、ミリ秒単位の間隔を配列で渡すことによって指定できます。The reconnection intervals can be specified by passing an array of millisecond-based durations:

.withAutomaticReconnect([0, 3000, 5000, 10000, 15000, 30000])
//.withAutomaticReconnect([0, 2000, 10000, 30000]) The default intervals.

カスタム実装を渡すと、再接続間隔を完全に制御することができます。A custom implementation can be passed in for full control of the reconnection intervals.

最後の再接続間隔の後で再接続に失敗した場合:If the reconnection fails after the last reconnect interval:

  • クライアントは接続がオフラインであると見なします。The client considers the connection is offline.
  • クライアントは再接続の試行を停止します。The client stops trying to reconnect.

再接続の試行中に、再接続が試行されていることをユーザーに通知するようにアプリ UI を更新します。During reconnection attempts, update the app UI to notify the user that the reconnection is being attempted.

接続が中断されたときに UI にフィードバックを提供するため、次のイベント ハンドラーを含むように SignalR クライアント API が拡張されました。To provide UI feedback when the connection is interrupted, the SignalR client API has been expanded to include the following event handlers:

  • onreconnecting:これによって、開発者が UI を無効にしたり、アプリがオフラインであることをユーザーに知らせたりすることができます。onreconnecting: Gives developers an opportunity to disable UI or to let users know the app is offline.
  • onreconnected:これによって、接続が再確立したときに開発者が UI を更新できます。onreconnected: Gives developers an opportunity to update the UI once the connection is reestablished.

次のコードでは onreconnecting を使用して、接続の試行中に UI を更新します。The following code uses onreconnecting to update the UI while trying to connect:

connection.onreconnecting((error) => {
    const status = `Connection lost due to error "${error}". Reconnecting.`;
    document.getElementById("messageInput").disabled = true;
    document.getElementById("sendButton").disabled = true;
    document.getElementById("connectionStatus").innerText = status;
});

次のコードでは onreconnected を使用して、接続時に UI を更新します。The following code uses onreconnected to update the UI on connection:

connection.onreconnected((connectionId) => {
    const status = `Connection reestablished. Connected.`;
    document.getElementById("messageInput").disabled = false;
    document.getElementById("sendButton").disabled = false;
    document.getElementById("connectionStatus").innerText = status;
});

SignalR 3.0 以降では、ハブ メソッドが承認を必要とする場合に、承認ハンドラーにカスタム リソースが提供されます。SignalR 3.0 and later provides a custom resource to authorization handlers when a hub method requires authorization. リソースは HubInvocationContext のインスタンスです。The resource is an instance of HubInvocationContext. HubInvocationContext には次のものが含まれます。The HubInvocationContext includes the:

  • HubCallerContext
  • 呼び出されているハブ メソッドの名前。Name of the hub method being invoked.
  • ハブ メソッドに対する引数。Arguments to the hub method.

複数の組織が Azure Active Directory を使用してサインインできるチャット ルーム アプリの例について考えてみます。Consider the following example of a chat room app allowing multiple organization sign-in via Azure Active Directory. Microsoft アカウントを持つユーザーは誰でもサインインしてチャットできますが、ユーザーを利用禁止にしたりユーザーのチャット履歴を表示したりできるのは所有している組織のメンバーのみです。Anyone with a Microsoft account can sign in to chat, but only members of the owning organization can ban users or view users' chat histories. アプリを使用すると、特定のユーザーに対して特定の機能を制限することができます。The app could restrict certain functionality from specific users.

public class DomainRestrictedRequirement :
    AuthorizationHandler<DomainRestrictedRequirement, HubInvocationContext>,
    IAuthorizationRequirement
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
        DomainRestrictedRequirement requirement,
        HubInvocationContext resource)
    {
        if (context.User?.Identity?.Name == null)
        {
            return Task.CompletedTask;
        }

        if (IsUserAllowedToDoThis(resource.HubMethodName, context.User.Identity.Name))
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }

    private bool IsUserAllowedToDoThis(string hubMethodName, string currentUsername)
    {
        if (hubMethodName.Equals("banUser", StringComparison.OrdinalIgnoreCase))
        {
            return currentUsername.Equals("bob42@jabbr.net", StringComparison.OrdinalIgnoreCase);
        }

        return currentUsername.EndsWith("@jabbr.net", StringComparison.OrdinalIgnoreCase));
    }
}

上記のコードでは、DomainRestrictedRequirement がカスタムの IAuthorizationRequirement として機能します。In the preceding code, DomainRestrictedRequirement serves as a custom IAuthorizationRequirement. HubInvocationContext リソース パラメーターが渡されているため、内部ロジックで以下を行うことができます。Because the HubInvocationContext resource parameter is being passed in, the internal logic can:

  • ハブが呼び出されているコンテキストを調べます。Inspect the context in which the Hub is being called.
  • 個々のハブ メソッドの実行をユーザーに許可するかどうかを決定します。Make decisions on allowing the user to execute individual Hub methods.

個々のハブ メソッドは、コードが実行時にチェックするポリシーの名前でマークできます。Individual Hub methods can be marked with the name of the policy the code checks at run-time. クライアントが個々のハブ メソッドを呼び出そうとすると、DomainRestrictedRequirement ハンドラーが実行され、メソッドへのアクセスを制御します。As clients attempt to call individual Hub methods, the DomainRestrictedRequirement handler runs and controls access to the methods. この方法に基づいて、DomainRestrictedRequirement が次のようにアクセスを制御します。Based on the way the DomainRestrictedRequirement controls access:

  • ログインしているすべてのユーザーが SendMessage メソッドを呼び出すことができます。All logged-in users can call the SendMessage method.
  • @jabbr.net 電子メール アドレスを使用してログインしたユーザーのみが、ユーザーの履歴を表示できます。Only users who have logged in with a @jabbr.net email address can view users' histories.
  • bob42@jabbr.net のみが、ユーザーをチャット ルーム利用禁止にすることができます。Only bob42@jabbr.net can ban users from the chat room.
[Authorize]
public class ChatHub : Hub
{
    public void SendMessage(string message)
    {
    }

    [Authorize("DomainRestricted")]
    public void BanUser(string username)
    {
    }

    [Authorize("DomainRestricted")]
    public void ViewUserHistory(string username)
    {
    }
}

DomainRestricted ポリシーの作成には以下が含まれる場合があります。Creating the DomainRestricted policy might involve:

  • Startup.cs に新しいポリシーを追加します。In Startup.cs, adding the new policy.
  • カスタムの DomainRestrictedRequirement 要件をパラメーターとして指定します。Provide the custom DomainRestrictedRequirement requirement as a parameter.
  • 承認ミドルウェアを使用して DomainRestricted を登録します。Registering DomainRestricted with the authorization middleware.
services
    .AddAuthorization(options =>
    {
        options.AddPolicy("DomainRestricted", policy =>
        {
            policy.Requirements.Add(new DomainRestrictedRequirement());
        });
    });

SignalR ハブではエンドポイント ルーティングが使用されます。SignalR hubs use Endpoint Routing. SignalR ハブ接続は以前は明示的に実行されました。SignalR hub connection was previously done explicitly:

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

以前のバージョンでは、開発者はさまざまな場所でコントローラー、Razor ページ、ハブを関連付ける必要がありました。In the previous version, developers needed to wire up controllers, Razor pages, and hubs in a variety of places. 明示的な接続によって、ほぼ同一のルーティング セグメントがいくつも生成されます。Explicit connection results in a series of nearly-identical routing segments:

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

app.UseRouting(routes =>
{
    routes.MapRazorPages();
});

SignalR 3.0 ハブは、エンドポイント ルーティングを介してルーティングできます。SignalR 3.0 hubs can be routed via endpoint routing. エンドポイント ルーティングでは、通常、すべてのルーティングを UseRouting に構成できます。With endpoint routing, typically all routing can be configured in UseRouting:

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

ASP.NET Core 3.0 SignalR で追加されたもの:ASP.NET Core 3.0 SignalR added:

クライアントとサーバー間のストリーミング。Client-to-server streaming. クライアントとサーバー間のストリーミングでは、サーバー側メソッドが IAsyncEnumerable<T> または ChannelReader<T> のインスタンスを受け取ることができます。With client-to-server streaming, server-side methods can take instances of either an IAsyncEnumerable<T> or ChannelReader<T>. 次 C# の例では、ハブの UploadStream メソッドがクライアントから文字列のストリームを受け取ります。In the following C# sample, the UploadStream method on the Hub will receive a stream of strings from the client:

public async Task UploadStream(IAsyncEnumerable<string> stream)
{
    await foreach (var item in stream)
    {
        // process content
    }
}

.NET クライアント アプリは、IAsyncEnumerable<T> または ChannelReader<T> インスタンスを、上記の UploadStream Hub メソッドの stream 引数として渡すことができます。.NET client apps can pass either an IAsyncEnumerable<T> or ChannelReader<T> instance as the stream argument of the UploadStream Hub method above.

for ループが完了し、ローカル関数が終了した後で、ストリームの完了が送信されます。After the for loop has completed and the local function exits, the stream completion is sent:

async IAsyncEnumerable<string> clientStreamData()
{
    for (var i = 0; i < 5; i++)
    {
        var data = await FetchSomeData();
        yield return data;
    }
}

await connection.SendAsync("UploadStream", clientStreamData());

JavaScript クライアント アプリは、上記の UploadStream ハブ メソッドの stream 引数のために SignalR Subject (または RxJS Subject) を使用します。JavaScript client apps use the SignalR Subject (or an RxJS Subject) for the stream argument of the UploadStream Hub method above.

let subject = new signalR.Subject();
await connection.send("StartStream", "MyAsciiArtStream", subject);

JavaScript コードで subject.next メソッドを使用すると、文字列がキャプチャされてからサーバーへの送信準備が整うように文字列を処理できます。The JavaScript code could use the subject.next method to handle strings as they are captured and ready to be sent to the server.

subject.next("example");
subject.complete();

直前の 2 つのスニペットのようなコードを使用して、リアルタイム ストリーミング エクスペリエンスを作成できます。Using code like the two preceding snippets, real-time streaming experiences can be created.

新しい JSON シリアル化New JSON serialization

現在、ASP.NET Core 3.0 では、JSON シリアル化のために既定で System.Text.Json が使用されます。ASP.NET Core 3.0 now uses System.Text.Json by default for JSON serialization:

  • 非同期で JSON の読み取りと書き込みを行います。Reads and writes JSON asynchronously.
  • UTF-8 テキスト用に最適化されています。Is optimized for UTF-8 text.
  • 通常、Newtonsoft.Json よりパフォーマンスが向上します。Typically higher performance than Newtonsoft.Json.

Json.NET を ASP.NET Core 3.0 に追加するには、「Newtonsoft.Json ベースの JSON 形式のサポートを追加する」を参照してください。To add Json.NET to ASP.NET Core 3.0, see Add Newtonsoft.Json-based JSON format support.

新しい Razor ディレクティブNew Razor directives

次の一覧には、新しい Razor ディレクティブが含まれます。The following list contains new Razor directives:

  • @attribute:@attribute ディレクティブでは、指定された属性が生成されたページまたはビューのクラスに適用されます。@attribute: The @attribute directive applies the given attribute to the class of the generated page or view. たとえば、@attribute [Authorize] のようにします。For example, @attribute [Authorize].
  • @implements:@implements ディレクティブでは、生成されたクラスのインターフェイスが実装されます。@implements: The @implements directive implements an interface for the generated class. たとえば、@implements IDisposable のようにします。For example, @implements IDisposable.

IdentityServer4 では、Web API と SPA の認証と承認がサポートされていますIdentityServer4 supports authentication and authorization for web APIs and SPAs

ASP.NET Core 3.0 では、Web API 認証のサポートの使用により、シングルページ アプリ (SPA) での認証が提供されます。ASP.NET Core 3.0 offers authentication in Single Page Apps (SPAs) using the support for web API authorization. ユーザーを認証および格納するための ASP.NET Core Identity が IdentityServer4 と組み合わされ、OpenID Connect が実装されます。ASP.NET Core Identity for authenticating and storing users is combined with IdentityServer4 for implementing OpenID Connect.

IdentityServer4 は、ASP.NET Core 3.0 用の OpenID Connect および OAuth 2.0 フレームワークです。IdentityServer4 is an OpenID Connect and OAuth 2.0 framework for ASP.NET Core 3.0. これにより、次のセキュリティ機能が有効になります。It enables the following security features:

  • サービスとしての認証 (AaaS)Authentication as a Service (AaaS)
  • 複数のアプリケーションの種類でのシングル サインオン/オフ (SSO)Single sign-on/off (SSO) over multiple application types
  • API のアクセス制御Access control for APIs
  • Federation GatewayFederation Gateway

詳細については、IdentityServer4 のドキュメントまたは「SPAs の認証と承認」を参照してください。For more information, see the IdentityServer4 documentation or Authentication and authorization for SPAs.

証明書および Kerberos 認証Certificate and Kerberos authentication

証明書認証には以下が必要です。Certificate authentication requires:

  • 証明書を受け入れるようにサーバーを構成します。Configuring the server to accept certificates.
  • Startup.Configure に認証ミドルウェアを追加します。Adding the authentication middleware in Startup.Configure.
  • Startup.ConfigureServices に証明書認証サービスを追加します。Adding the certificate authentication service in Startup.ConfigureServices.
public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(
        CertificateAuthenticationDefaults.AuthenticationScheme)
            .AddCertificate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

証明書認証のオプションには次の機能が含まれます。Options for certificate authentication include the ability to:

  • 自己署名された証明書を受け入れる。Accept self-signed certificates.
  • 証明書の失効を確認する。Check for certificate revocation.
  • 提供された証明書に適切な使用フラグが含まれていることを確認する。Check that the proffered certificate has the right usage flags in it.

既定のユーザー プリンシパルは、証明書のプロパティで構成されます。A default user principal is constructed from the certificate properties. ユーザー プリンシパルには、プリンシパルの補完または置換を可能にするイベントが含まれています。The user principal contains an event that enables supplementing or replacing the principal. 詳細については、「ASP.NET Core で証明書認証を構成する」を参照してください。For more information, see ASP.NET Core で証明書認証を構成する.

Windows 認証は、Linux および macOS に拡張されています。Windows Authentication has been extended onto Linux and macOS. 以前のバージョンでは、Windows 認証は IISHttpSys に限定されていました。In previous versions, Windows Authentication was limited to IIS and HttpSys. ASP.NET Core 3.0 では、Kestrel は、Windows、Linux、および macOS 上で、Windows ドメインに参加しているホストに対して Negotiate、Kerberos、および NTLM を使用できます。In ASP.NET Core 3.0, Kestrel has the ability to use Negotiate, Kerberos, and NTLM on Windows, Linux, and macOS for Windows domain-joined hosts. これらの認証スキームの Kestrel サポートは、Microsoft.AspNetCore.Authentication.Negotiate NuGet パッケージによって提供されます。Kestrel support of these authentication schemes is provided by the Microsoft.AspNetCore.Authentication.Negotiate NuGet package. 他の認証サービスと同様に、認証アプリ全体を構成してからサービスを構成します。As with the other authentication services, configure authentication app wide, then configure the service:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

ホストの要件:Host requirements:

  • Windows ホストでは、アプリをホストするユーザー アカウントにサービス プリンシパル名 (SPN) を追加する必要があります。Windows hosts must have Service Principal Names (SPNs) added to the user account hosting the app.
  • Linux および macOS マシンは、ドメインに参加している必要があります。Linux and macOS machines must be joined to the domain.
    • Web プロセス用に SPN を作成する必要があります。SPNs must be created for the web process.
    • キータブ ファイルをホスト マシン上で生成して構成する必要があります。Keytab files must be generated and configured on the host machine.

詳細については、「ASP.NET Core で Windows 認証を構成する」を参照してください。For more information, see ASP.NET Core で Windows 認証を構成する.

テンプレートの変更Template changes

Web UI テンプレート (Razor Pages、コントローラーとビューを含む MVC) では、以下が削除されています。The web UI templates (Razor Pages, MVC with controller and views) have the following removed:

Angular テンプレートは、Angular 8 を使用するように更新されました。The Angular template updated to use Angular 8.

Razor クラス ライブラリ (RCL) テンプレートは Razor コンポーネント開発での既定です。The Razor class library (RCL) template defaults to Razor component development by default. Visual Studio の新しいテンプレート オプションによって、ページとビューのテンプレート サポートが提供されます。A new template option in Visual Studio provides template support for pages and views. コマンド シェルでテンプレートから RCL を作成するときは、--support-pages-and-views オプション (dotnet new razorclasslib --support-pages-and-views) を渡します。When creating an RCL from the template in a command shell, pass the --support-pages-and-views option (dotnet new razorclasslib --support-pages-and-views).

汎用ホストGeneric Host

ASP.NET Core 3.0 テンプレートでは ASP.NET Core の .NET 汎用ホスト が使用されます。The ASP.NET Core 3.0 templates use ASP.NET Core の .NET 汎用ホスト. 以前のバージョンでは WebHostBuilder が使用されていました。Previous versions used WebHostBuilder. .NET Core 汎用ホスト (HostBuilder) を使用すると、ASP.NET Core アプリと、Web 固有ではない他のサーバー シナリオの統合が強化されます。Using the .NET Core Generic Host (HostBuilder) provides better integration of ASP.NET Core apps with other server scenarios that aren't web-specific. 詳細については、「HostBuilder による WebHostBuilder の置き換え」を参照してください。For more information, see HostBuilder replaces WebHostBuilder.

ホストの構成Host configuration

ASP.NET Core 3.0 リリースよりも前には、ASPNETCORE_ というプレフィックスが付いた環境変数が Web ホストのホスト構成用に読み込まれました。Prior to the release of ASP.NET Core 3.0, environment variables prefixed with ASPNETCORE_ were loaded for host configuration of the Web Host. 3.0 では、AddEnvironmentVariables が使用され、DOTNET_ というプレフィックスが付いた環境変数が CreateDefaultBuilder でのホスト構成用に読み込まれます。In 3.0, AddEnvironmentVariables is used to load environment variables prefixed with DOTNET_ for host configuration with CreateDefaultBuilder.

Startup コンストラクター挿入の変更Changes to Startup constructor injection

汎用ホストでは、Startup コンストラクター挿入で次の型しかサポートされません。The Generic Host only supports the following types for Startup constructor injection:

すべてのサービスを Startup.Configure メソッドへの引数として直接挿入することは引き続きできます。All services can still be injected directly as arguments to the Startup.Configure method. 詳細については、「汎用ホストによる Startup コンストラクター挿入の制限 (aspnet/Announcements #353)」を参照してください。For more information, see Generic Host restricts Startup constructor injection (aspnet/Announcements #353).

KestrelKestrel

  • Kestrel 構成は、汎用ホストへの移行に対応するように更新されました。Kestrel configuration has been updated for the migration to the Generic Host. 3.0 では、Kestrel は ConfigureWebHostDefaults によって提供される Web ホスト ビルダー上で構成されます。In 3.0, Kestrel is configured on the web host builder provided by ConfigureWebHostDefaults.
  • 接続アダプターは Kestrel から削除され、接続ミドルウェアで置き換えられました。これは ASP.NET Core パイプラインの HTTP ミドルウェアに似ていますが下位レベルの接続用です。Connection Adapters have been removed from Kestrel and replaced with Connection Middleware, which is similar to HTTP Middleware in the ASP.NET Core pipeline but for lower-level connections.
  • Kestrel トランスポート層は、Connections.Abstractions のパブリック インターフェイスとして公開されています。The Kestrel transport layer has been exposed as a public interface in Connections.Abstractions.
  • ヘッダーとトレーラーのあいまいさは、末尾のヘッダーを新しいコレクションに移動することによって解決されました。Ambiguity between headers and trailers has been resolved by moving trailing headers to a new collection.
  • 同期 I/O の API (HttpRequest.Body.Read など) は、アプリのクラッシュにつながるスレッドの不足の一般的な原因です。Synchronous I/O APIs, such as HttpRequest.Body.Read, are a common source of thread starvation leading to app crashes. 3.0 では、AllowSynchronousIO は既定で無効になっています。In 3.0, AllowSynchronousIO is disabled by default.

詳細については、「ASP.NET Core 2.2 から3.0 への移行」を参照してください。For more information, see ASP.NET Core 2.2 から3.0 への移行.

既定で有効な HTTP/2HTTP/2 enabled by default

HTTP/2 は、Kestrel では HTTPS エンドポイントに対して既定で有効です。HTTP/2 is enabled by default in Kestrel for HTTPS endpoints. IIS または HTTP.sys での HTTP/2 サポートは、オペレーティング システムでサポートされる場合に有効です。HTTP/2 support for IIS or HTTP.sys is enabled when supported by the operating system.

要求時の EventCounterEventCounters on request

ホスティング EventSource Microsoft.AspNetCore.Hosting は、受信要求に関連する次の新しい種類の EventCounter を出力します。The Hosting EventSource, Microsoft.AspNetCore.Hosting, emits the following new EventCounter types related to incoming requests:

  • requests-per-second
  • total-requests
  • current-requests
  • failed-requests

エンドポイント ルーティングEndpoint routing

エンドポイント ルーティングによってフレームワーク (MVC など) がミドルウェアとうまく連携できるようになりますが、これが次のように強化されています。Endpoint Routing, which allows frameworks (for example, MVC) to work well with middleware, is enhanced:

  • ミドルウェアとエンドポイントの順序を Startup.Configure の要求処理パイプラインで構成できます。The order of middleware and endpoints is configurable in the request processing pipeline of Startup.Configure.
  • エンドポイントとミドルウェアは、正常性チェックなどの他の ASP.NET Core ベースのテクノロジに対して適切に構成できます。Endpoints and middleware compose well with other ASP.NET Core-based technologies, such as Health Checks.
  • エンドポイントは、ミドルウェアと MVC の両方に、CORS や承認などのポリシーを実装できます。Endpoints can implement a policy, such as CORS or authorization, in both middleware and MVC.
  • フィルターおよび属性をコントローラーのメソッドに設定できます。Filters and attributes can be placed on methods in controllers.

詳細については、「ASP.NET Core のルーティング」を参照してください。For more information, see ASP.NET Core のルーティング.

正常性チェックHealth Checks

正常性チェックでは、汎用ホストとのエンドポイント ルーティングを使用します。Health Checks use endpoint routing with the Generic Host. Startup.Configure で、エンドポイントの URL または相対パスを使用して、エンドポイント ビルダーで MapHealthChecks を呼び出します。In Startup.Configure, call MapHealthChecks on the endpoint builder with the endpoint URL or relative path:

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

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

  • 1 つまたは複数の許可されたホスト/ポートを指定する。Specify one or more permitted hosts/ports.
  • 承認を必要とする。Require authorization.
  • CORS を必要とする。Require CORS.

詳細については、次の記事を参照してください。For more information, see the following articles:

HttpContext のパイプPipes on HttpContext

現在、System.IO.Pipelines API を使用して、要求本文の読み取りと応答本文の書き込みを行うことができます。It's now possible to read the request body and write the response body using the System.IO.Pipelines API. 次に、The HttpRequest.BodyReader プロパティは、要求本文を読み取るために使用できる PipeReader を提供します。HttpRequest.BodyReader property provides a PipeReader that can be used to read the request body. 次に、The HttpResponse.BodyWriter プロパティは、応答本文を書き込むために使用できる PipeWriter を提供します。HttpResponse.BodyWriter property provides a PipeWriter that can be used to write the response body. HttpRequest.BodyReader は、HttpRequest.Body ストリームに類似しています。HttpRequest.BodyReader is an analogue of the HttpRequest.Body stream. HttpResponse.BodyWriterHttpResponse.Body ストリームに類似しています。HttpResponse.BodyWriter is an analogue of the HttpResponse.Body stream.

IIS でのエラー報告の向上Improved error reporting in IIS

IIS で ASP.NET Core アプリをホストする際の起動エラーで生成される診断データが豊富になりました。Startup errors when hosting ASP.NET Core apps in IIS now produce richer diagnostic data. これらのエラーは、該当する場合は常にスタック トレースと共に Windows イベント ログに報告されます。These errors are reported to the Windows Event Log with stack traces wherever applicable. さらに、すべての警告、エラー、および未処理の例外が、Windows イベント ログに記録されます。In addition, all warnings, errors, and unhandled exceptions are logged to the Windows Event Log.

ワーカー サービスとワーカー SDKWorker Service and Worker SDK

.NET Core 3.0 では、新しいワーカー サービス アプリ テンプレートが導入されました。.NET Core 3.0 introduces the new Worker Service app template. このテンプレートは、.NET Core で長期サービスを作成する場合の出発点として利用できます。This template provides a starting point for writing long running services in .NET Core.

詳細については次を参照してください:For more information, see:

Forwarded Headers Middleware の機能強化Forwarded Headers Middleware improvements

ASP.NET Core の以前のバージョンでは、Azure Linux にデプロイした場合、または IIS 以外のリバース プロキシの背後にデプロイした場合に、UseHstsUseHttpsRedirection の呼び出しで問題が発生していました。In previous versions of ASP.NET Core, calling UseHsts and UseHttpsRedirection were problematic when deployed to an Azure Linux or behind any reverse proxy other than IIS. 以前のバージョンの修正方法は、「Linux および非 IIS のリバース プロキシのスキームを転送する」に記載されてます。The fix for previous versions is documented in Forward the scheme for Linux and non-IIS reverse proxies.

このシナリオは ASP.NET Core 3.0 では修正されています。This scenario is fixed in ASP.NET Core 3.0. ホストによって Forwarded Headers Middleware が有効化されるのは、ASPNETCORE_FORWARDEDHEADERS_ENABLED 環境変数が true に設定されているときです。The host enables the Forwarded Headers Middleware when the ASPNETCORE_FORWARDEDHEADERS_ENABLED environment variable is set to true. ASPNETCORE_FORWARDEDHEADERS_ENABLED はコンテナー イメージで true に設定されています。ASPNETCORE_FORWARDEDHEADERS_ENABLED is set to true in our container images.

パフォーマンスの向上Performance improvements

ASP.NET Core 3.0 には、メモリ使用量を減らしてスループットを向上させる多くの機能強化が含まれています。ASP.NET Core 3.0 includes many improvements that reduce memory usage and improve throughput:

  • スコープ サービスで組み込み依存関係挿入コンテナーを使用する場合のメモリ使用量の削減。Reduction in memory usage when using the built-in dependency injection container for scoped services.
  • ミドルウェアのシナリオやルーティングを含む、フレームワーク全体での割り当ての削減。Reduction in allocations across the framework, including middleware scenarios and routing.
  • WebSocket 接続のメモリ使用量の削減。Reduction in memory usage for WebSocket connections.
  • HTTPS 接続でのメモリの削減とスループットの向上。Memory reduction and throughput improvements for HTTPS connections.
  • 最適化された完全非同期の新 JSON シリアライザー。New optimized and fully asynchronous JSON serializer.
  • フォーム解析でのメモリ使用量の削減とスループットの向上。Reduction in memory usage and throughput improvements in form parsing.

.NET Core 3.0 のみで実行する ASP.NET Core 3.0ASP.NET Core 3.0 only runs on .NET Core 3.0

ASP.NET Core 3.0 以降、.NET Framework はサポートされるターゲット フレームワークではなくなりました。As of ASP.NET Core 3.0, .NET Framework is no longer a supported target framework. .NET Framework をターゲットとするプロジェクトは、.NET Core 2.1 LTS リリースを使用して完全にサポートされた状態で続行できます。Projects targeting .NET Framework can continue in a fully supported fashion using the .NET Core 2.1 LTS release. ほとんどの ASP.NET Core 2.1.x 関連パッケージは、.NET Core 2.1 の 3 年の LTS 期間が終わっても無期限にサポートされます。Most ASP.NET Core 2.1.x related packages will be supported indefinitely, beyond the three-year LTS period for .NET Core 2.1.

移行の詳細については、「.NET Framework から .NET Core にコードを移植する」を参照してください。For migration information, see Port your code from .NET Framework to .NET Core.

ASP.NET Core 共有フレームワークの使用Use the ASP.NET Core shared framework

Microsoft.AspNetCore.App メタパッケージに含まれる ASP.NET Core 3.0 共有フレームワークでは、プロジェクト ファイル内の明示的な <PackageReference /> 要素を必要としなくなりました。The ASP.NET Core 3.0 shared framework, contained in the Microsoft.AspNetCore.App metapackage, no longer requires an explicit <PackageReference /> element in the project file. プロジェクト ファイル内で Microsoft.NET.Sdk.Web SDK を使用すると、共有フレームワークが自動的に参照されます。The shared framework is automatically referenced when using the Microsoft.NET.Sdk.Web SDK in the project file:

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

ASP.NET Core 共有フレームワークから削除されたアセンブリAssemblies removed from the ASP.NET Core shared framework

ASP.NET Core 3.0 共有フレームワークから削除された重要なアセンブリは次のとおりです。The most notable assemblies removed from the ASP.NET Core 3.0 shared framework are:

共有フレームワークから削除されたすべてのアセンブリの一覧については、「Microsoft.AspNetCore.App 3.0 から削除されるアセンブリ」を参照してください。For a complete list of assemblies removed from the shared framework, see Assemblies being removed from Microsoft.AspNetCore.App 3.0. この変更の動機については、「Microsoft.AspNetCore.App 3.0 に対する重大な変更」および「ASP.NET Core 3.0 の変更点を初めて見て」を参照してください。For more information on the motivation for this change, see Breaking changes to Microsoft.AspNetCore.App in 3.0 and A first look at changes coming in ASP.NET Core 3.0.