ASP.NET Core バージョン 3.0 および 3.1 における破壊的変更

  • [アーティクル]

ASP.NET Core からは、.NET Core で使用される Web アプリ開発機能が提供されます。

特定のバージョンの破壊的変更については、次のリンクのいずれかを選択します。

このページでは、ASP.NET Core 3.0 および 3.1 の次の破壊的変更について説明します。

ASP.NET Core 3.1

HTTP:ブラウザー SameSite の変更による認証への影響

Chrome や Firefox などの一部のブラウザーでは、Cookie の SameSite の実装に破壊的変更が加えられました。 この変更は、OpenID Connect や WS-Federation などのリモート認証シナリオに影響します。これをオプトアウトするには、SameSite=None を送信します。 ただし、iOS 12 および一部の古いバージョンの他のブラウザーでは SameSite=None は中断します。 アプリはこれらのバージョンをスニッフィングし、SameSite を省略する必要があります。

この問題に関するディスカッションについては、dotnet/aspnetcore#14996 を参照してください。

導入されたバージョン

3.1 Preview 1

以前の動作

SameSite は、HTTP Cookie の 2016 ドラフト標準の拡張機能です。 これは、クロスサイト リクエスト フォージェリ (CSRF) を軽減することを目的としています。 もともと、これは、新しいパラメーターを追加することでサーバーでオプトインされる機能として設計されました。 ASP.NET Core 2.0 で SameSite の初期サポートが追加されました。

新しい動作

Google から、は下位互換性のない新しいドラフト標準が提案されました この標準では、既定のモードが Lax に変更され、オプトアウト対象の新しいエントリ None が追加されています。Lax はほとんどのアプリの Cookie に十分です。ただし、OpenID Connect や WS-Federation ログインなどのクロスサイト シナリオは中断されます。 ほとんどの OAuth ログインは、要求フローの違いによって影響を受けません。 新しい None パラメーターを使うと、以前のドラフト標準 (iOS 12 など) を実装したクライアントとの互換性の問題が発生します。 Chrome 80 にこの変更が含まれます。 Chrome 製品の発売タイムラインについては、「SameSite Updates」(SameSite の更新) を参照してください。

ASP.NET Core 3.1 は、新しい SameSite 動作を実装するように更新されました。 この更新により、SameSite=None が出力され、SameSite 属性を省略する新しい値 SameSiteMode.Unspecified が追加されるように SameSiteMode.None の動作が再定義されました。 すべての Cookie API の既定は Unspecified になりましたが、Cookie を使用する一部のコンポーネントでは、OpenID Connect の相関関係や nonce Cookie など、シナリオに固有の値を設定します。

この分野の最近の変更については、「HTTP:SameSite の cookie オプションの既定値が一部、None に変更されました」を参照してください。 ASP.NET Core 3.0 では、ほとんどの既定値が SameSiteMode.Lax から SameSiteMode.None に変更されました (ただし、以前の標準を使用しています)。

変更理由

既に概要を説明したように、ブラウザーと仕様が変わっています。

サードパーティ ログインなどを介してリモート サイトとやり取りするアプリは、以下を行う必要があります。

  • 複数のブラウザー上でこのようなシナリオをテストする。
  • 「以前のブラウザーをサポートする」で説明されている Cookie ポリシー ブラウザー スニッフィングの軽減策を適用します。

テストとブラウザー スニッフィングの手順については、次のセクションを参照してください。

影響を受けているかどうかを判断する

新しい動作をオプトインできるクライアント バージョンを使用して、Web アプリをテストします。 Chrome、Firefox、Microsoft Edge Chromium のいずれにも、テストに使用できる新しいオプトイン機能フラグがあります。 パッチを適用した後、アプリが古いクライアント バージョンと互換性があることを確認します (特に Safari)。 詳細については、「以前のブラウザーをサポートする」を参照してください。

Chrome

Chrome 78 以降では、誤解を招くテスト結果が生成されます。 これらのバージョンには一時的な軽減策が適用されており、2 分前よりも短い Cookie が許可されます。 適切なテスト フラグを有効にすると、Chrome 76 および 77 からはより正確な結果が生成されます。 新しい動作をテストするには、chrome://flags/#same-site-by-default-cookies を有効に切り替えます。 Chrome 75 以前は、新しい None 設定を使うと失敗すると報告されています。 詳細については、「以前のブラウザーをサポートする」を参照してください。

Google は、以前のバージョンの Chrome を提供していません。 ただし、以前のバージョンの Chromium をダウンロードすることはできますが、テスト目的には十分です。 Chromium のダウンロードに関する記事の手順に従ってください。

Safari

Safari 12 では以前のドラフトが厳密に実装されており、Cookie に新しい None 値が存在すると失敗します。 これは、「以前のブラウザーをサポートする」に示されているブラウザー スニッフィング コードを使って防ぐ必要があります。 Microsoft Authentication Library (MSAL)、Active Directory 認証ライブラリ (ADAL)、または使用している任意のライブラリを使って、Safari 12 および 13 と WebKit ベースの OS スタイルのログインをテストしてください。 この問題は、基盤の OS バージョンによって変わります。 OSX Mojave 10.14 および iOS 12 には、新しい動作との互換性の問題があることがわかっています。 OSX Catalina 10.15 または iOS 13 にアップグレードすると、問題が解決します。 現在、Safari には新しい仕様の動作をテストするためのオプトイン フラグがありません。

Firefox

Firefox の新しい標準のサポートは、バージョン 68 以降で、機能フラグ network.cookie.sameSite.laxByDefault を指定して about:config ページで選択することでオプトインできます。 以前のバージョンの Firefox では、互換性の問題は報告されていません。

Microsoft Edge

Microsoft Edge では古い SameSite 標準がサポートされていますが、バージョン 44 の時点では、新しい標準との互換性の問題はありませんでした。

Microsoft Edge Chromium

機能フラグは edge://flags/#same-site-by-default-cookies です。 Microsoft Edge Chromium 78 を使ってテストした際には、互換性の問題は検出されませんでした。

Electron

Electron の複数のバージョンには、Chromium の古いバージョンが含まれています。 たとえば、Microsoft Teams で使用されている Electron のバージョンは Chromium 66 であり、以前の動作を示しています。 お使いの製品に使用されている Electron のバージョンを使って、ご自分で互換性テストを実行してください。 詳細については、「以前のブラウザーをサポートする」を参照してください。

以前のブラウザーをサポートする

2016 SameSite 標準では、不明な値を SameSite=Strict 値として扱うことが義務付けられていました。 そのため、元の標準をサポートする以前のブラウザーがある場合、値が None の SameSite プロパティが表示されたときに、中断される可能性があります。 このような以前のブラウザーをサポートする場合、Web アプリではブラウザー スニッフィングを実装する必要があります。 User-Agent 要求ヘッダー値は非常に不安定であり、週単位で変わるため、ASP.NET Core ではブラウザー スニッフィングを実装していません。 代わりに、Cookie ポリシーの拡張ポイントを使って、User-Agent 固有のロジックを追加できます。

Startup.cs で、次のコードを追加します。

private void CheckSameSite(HttpContext httpContext, CookieOptions options)
{
    if (options.SameSite == SameSiteMode.None)
    {
        var userAgent = httpContext.Request.Headers["User-Agent"].ToString();
        // TODO: Use your User Agent library of choice here.
        if (/* UserAgent doesn't support new behavior */)
        {
            options.SameSite = SameSiteMode.Unspecified;
        }
    }
}

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<CookiePolicyOptions>(options =>
    {
        options.MinimumSameSitePolicy = SameSiteMode.Unspecified;
        options.OnAppendCookie = cookieContext =>
            CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
        options.OnDeleteCookie = cookieContext =>
            CheckSameSite(cookieContext.Context, cookieContext.CookieOptions);
    });
}

public void Configure(IApplicationBuilder app)
{
    // Before UseAuthentication or anything else that writes cookies.
    app.UseCookiePolicy();

    app.UseAuthentication();
    // code omitted for brevity
}
オプトアウト スイッチ

Microsoft.AspNetCore.SuppressSameSiteNone 互換性スイッチを使用すると、新しい ASP.NET Core Cookie の動作を一時的にオプトアウトできます。 プロジェクトの runtimeconfig.template.json ファイルに次の JSON を追加します。

{
  "configProperties": {
    "Microsoft.AspNetCore.SuppressSameSiteNone": "true"
  }
}
その他のバージョン

関連する SameSite パッチは以下に対して適用されます。

  • ASP.NET Core 2.1、2.2、および 3.0
  • Microsoft.Owin 4.1
  • System.Web (.NET Framework 4.7.2 以降の場合)

カテゴリ

ASP.NET

影響を受ける API

ASP.NET Core 3.0

Antiforgery、CORS、Diagnostics、MVC、Routing の古い API が削除された

ASP.NET Core 2.2 の古いメンバーと互換性スイッチが削除されました。

導入されたバージョン

3.0

変更理由

時間経過による API サーフェイスの向上。

.NET Core 2.2 がターゲットの間は、古いビルド メッセージのガイダンスに従って新しい API を採用します。

カテゴリ

ASP.NET Core

影響を受ける API

以下の型とメンバーは、ASP.NET Core 2.1 および 2.2 では古いものとしてマークされています。

型

  • Microsoft.AspNetCore.Diagnostics.Views.WelcomePage
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.AttributeValue
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.BaseView
  • Microsoft.AspNetCore.DiagnosticsViewPage.Views.HelperResult
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.ProblemDetails21Wrapper
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.ValidationProblemDetails21Wrapper
  • Microsoft.AspNetCore.Mvc.Razor.Compilation.ViewsFeatureProvider
  • Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageArgumentBinder
  • Microsoft.AspNetCore.Routing.IRouteValuesAddressMetadata
  • Microsoft.AspNetCore.Routing.RouteValuesAddressMetadata

コンストラクター

  • Microsoft.AspNetCore.Cors.Infrastructure.CorsService(IOptions{CorsOptions})
  • Microsoft.AspNetCore.Routing.Tree.TreeRouteBuilder(ILoggerFactory,UrlEncoder,ObjectPool{UriBuildingContext},IInlineConstraintResolver)
  • Microsoft.AspNetCore.Mvc.Formatters.OutputFormatterCanWriteContext
  • Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider)
  • Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider(IOptions{MvcOptions},IInlineConstraintResolver,IModelMetadataProvider,IActionResultTypeMapper)
  • Microsoft.AspNetCore.Mvc.Formatters.FormatFilter(IOptions{MvcOptions})
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ArrayModelBinder`1(IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ByteArrayModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.CollectionModelBinder`1(IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder(IDictionary`2)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DictionaryModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DoubleModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FloatModelBinder(System.Globalization.NumberStyles)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormCollectionModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormFileModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.HeaderModelBinder
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.KeyValuePairModelBinder`2(IModelBinder,IModelBinder)
  • Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder(System.Type)
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object},IEnumerable{System.Object})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ModelBinderFactory(IModelMetadataProvider,IOptions{MvcOptions})
  • Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder(IModelMetadataProvider,IModelBinderFactory,IObjectModelValidator)
  • Microsoft.AspNetCore.Mvc.Routing.KnownRouteValueConstraint()
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(System.Boolean)
  • Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(MvcOptions)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ImageTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.LinkTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.TagHelpers.ScriptTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
  • Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.RazorPageAdapter(RazorPageBase)

プロパティ

  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieDomain
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookieName
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.CookiePath
  • Microsoft.AspNetCore.Antiforgery.AntiforgeryOptions.RequireSsl
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.AllowInferringBindingSourceForCollectionTypesAsFromQuery
  • Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.SuppressUseValidationProblemDetailsForInvalidModelStateResponses
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.CookieName
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Domain
  • Microsoft.AspNetCore.Mvc.CookieTempDataProviderOptions.Path
  • Microsoft.AspNetCore.Mvc.DataAnnotations.MvcDataAnnotationsLocalizationOptions.AllowDataAnnotationsLocalizationForEnumDisplayAttributes
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.MvcXmlOptions.AllowRfc7807CompliantProblemDetailsFormat
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowBindingHeaderValuesToNonStringModelTypes
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowCombiningAuthorizeFilters
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowShortCircuitingValidationWhenNoValidatorsArePresent
  • Microsoft.AspNetCore.Mvc.MvcOptions.AllowValidatingTopLevelNodes
  • Microsoft.AspNetCore.Mvc.MvcOptions.InputFormatterExceptionPolicy
  • Microsoft.AspNetCore.Mvc.MvcOptions.SuppressBindingUndefinedValueToEnumType
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.AllowRenderingMaxLengthAttribute
  • Microsoft.AspNetCore.Mvc.MvcViewOptions.SuppressTempDataAttributePrefix
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowAreas
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowDefaultHandlingForOptionsRequests
  • Microsoft.AspNetCore.Mvc.RazorPages.RazorPagesOptions.AllowMappingHeadRequestsToGetHandler

メソッド

認証: Google+ が非推奨になり、置き換えられました

Google では、早ければ 2019 年 1 月 28 日をもってアプリ向け Google+ Sign-in のサービスが終了します。

変更の説明

ASP.NET 4.x と ASP.NET Core では、Google+ Sign-in API を使用して、Web アプリで Google アカウント ユーザーを認証しています。 影響を受ける NuGet パッケージは、ASP.NET Core の場合は Microsoft.AspNetCore.Authentication.Google、ASP.NET Web Forms および MVC での Microsoft.Owin の場合は Microsoft.Owin.Security.Google です。

代わりとなる Google の API では、別のデータ ソースと形式が使用されています。 構造的な変更については、以下に示す軽減策と解決策を参照してください。 データ自体が要件を満たしているかどうかをアプリで確認する必要があります。 たとえば、名前、電子メール アドレス、プロファイル リンク、プロファイル写真では、以前とは微妙に異なる値が提供される場合があります。

導入されたバージョン

すべてのバージョン。 この変更は、ASP.NET Core の外部での変更です。

ASP.NET Web Forms および MVC での Owin

Microsoft.Owin 3.1.0 以降については、一時的な軽減策の概要がこちらにあります。 アプリでは、データ形式の変更を確認するために、軽減策を使用してテストを完了する必要があります。 Microsoft.Owin 4.0.1 と修正プログラムをリリースする計画があります。 以前のバージョンを使用しているアプリは、バージョン 4.0.1 に更新する必要があります。

ASP.NET Core 1.x

ASP.NET Web Forms および MVC での Owin の軽減策は、ASP.NET Core 1.x に適応できます。 1.x は有効期間の終了状態に達したため、NuGet パッケージの修正プログラムは計画されていません。

ASP.NET Core 2.x

Microsoft.AspNetCore.Authentication.Google バージョン 2.x の場合は、Startup.ConfigureServices での AddGoogle の既存の呼び出しを次のコードに置き換えます。

.AddGoogle(o =>
{
    o.ClientId = Configuration["Authentication:Google:ClientId"];
    o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
    o.UserInformationEndpoint = "https://www.googleapis.com/oauth2/v2/userinfo";
    o.ClaimActions.Clear();
    o.ClaimActions.MapJsonKey(ClaimTypes.NameIdentifier, "id");
    o.ClaimActions.MapJsonKey(ClaimTypes.Name, "name");
    o.ClaimActions.MapJsonKey(ClaimTypes.GivenName, "given_name");
    o.ClaimActions.MapJsonKey(ClaimTypes.Surname, "family_name");
    o.ClaimActions.MapJsonKey("urn:google:profile", "link");
    o.ClaimActions.MapJsonKey(ClaimTypes.Email, "email");
});

2 月の 2.1 と 2.2 の修正プログラムには、先行の再構成が新しい既定値として組み込まれています。 ASP.NET Core 2.0 は有効期間の終了に達したため、修正プログラムは計画されていません。

ASP.NET Core 3.0

ASP.NET Core 2.x 用に提供されている軽減策は、ASP.NET Core 3.0 にも使用できます。 今後の 3.0 のプレビューにおいて、Microsoft.AspNetCore.Authentication.Google パッケージが削除される可能性があります。 ユーザーは、代わりに Microsoft.AspNetCore.Authentication.OpenIdConnect に誘導されます。 Startup.ConfigureServices 内の AddGoogle を AddOpenIdConnect に置き換える方法を次のコードに示します。 この置き換えは ASP.NET Core 2.0 以降で使用でき、必要に応じて ASP.NET Core 1.x にも適応できます。

.AddOpenIdConnect("Google", o =>
{
    o.ClientId = Configuration["Authentication:Google:ClientId"];
    o.ClientSecret = Configuration["Authentication:Google:ClientSecret"];
    o.Authority = "https://accounts.google.com";
    o.ResponseType = OpenIdConnectResponseType.Code;
    o.CallbackPath = "/signin-google"; // Or register the default "/signin-oidc"
    o.Scope.Add("email");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.AspNetCore.Authentication.Google

認証:HttpContext.Authentication プロパティの削除

HttpContext の非推奨の Authentication プロパティが削除されました。

変更の説明

dotnet/aspnetcore#6504 の一部として、HttpContext の非推奨の Authentication プロパティが削除されました。 2.0 以降、Authentication プロパティは非推奨になりました。 この非推奨のプロパティを使用して新しい置換 API にコードを移行するために、移行ガイドが発行されました。 古い ASP.NET Core 1.x 認証スタックに関連する残りの未使用のクラス/API が、コミット dotnet/aspnetcore@d7a7c65 で削除されました。

ディスカッションについては、dotnet/aspnetcore#6533 を参照してください。

導入されたバージョン

3.0

変更理由

ASP.NET Core 1.0 API が Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions の拡張メソッドに置き換えられました。

移行ガイドを参照してください。

カテゴリ

ASP.NET Core

影響を受ける API

認証:Newtonsoft.Json 型の置き換え

ASP.NET Core 3.0 では、Authentication API で使用される Newtonsoft.Json 型が System.Text.Json 型に置き換えられました。 次の場合を除き、Authentication パッケージの基本的な使用方法は影響を受けません。

  • aspnet-contrib のプロバイダーなど、OAuth プロバイダーから派生したクラス。
  • 高度な要求操作の実装。

詳細については、dotnet/aspnetcore#7105 を参照してください。 ディスカッションについては、dotnet/aspnetcore#7289 を参照してください。

導入されたバージョン

3.0

派生 OAuth 実装の場合、最も一般的な変更は、こちらで示すように、CreateTicketAsync オーバーライドで JObject.Parse を JsonDocument.Parse に置き換えることです。 JsonDocument は、IDisposable を実装します。

既知の変更の概要を以下に示します。

カテゴリ

ASP.NET Core

影響を受ける API

認証:OAuthHandler ExchangeCodeAsync 署名の変更

ASP.NET Core 3.0 では、OAuthHandler.ExchangeCodeAsync の署名が次のように変更されました。

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(string code, string redirectUri) { throw null; }

移動先:

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse> ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }

導入されたバージョン

3.0

以前の動作

code と redirectUri の文字列が個別の引数として渡されました。

新しい動作

Code と RedirectUri は、OAuthCodeExchangeContext コンストラクターを使用して設定できる OAuthCodeExchangeContext のプロパティです。 新しい OAuthCodeExchangeContext 型は、OAuthHandler.ExchangeCodeAsync に渡される唯一の引数です。

変更理由

この変更により、追加のパラメーターを中断することなく提供できます。 新しい ExchangeCodeAsync オーバーロードを作成する必要はありません。

適切な code と redirectUri の値を使用して、OAuthCodeExchangeContext を作成します。 AuthenticationProperties インスタンスを指定する必要があります。 この 1 つの OAuthCodeExchangeContext インスタンスは、複数の引数ではなく、OAuthHandler.ExchangeCodeAsync に渡すことができます。

カテゴリ

ASP.NET Core

影響を受ける API

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

承認:AddAuthorization のオーバーロードを別のアセンブリに移動

Microsoft.AspNetCore.Authorization に以前あったコア AddAuthorization メソッドが AddAuthorizationCore に名前変更されました。 古い AddAuthorization メソッドはまだありますが、代わりに Microsoft.AspNetCore.Authorization.Policy アセンブリに含まれています。 両方のメソッドを使用するアプリには影響はありません。 Microsoft.AspNetCore.Authorization.Policy は、「共有フレームワーク: Microsoft.AspNetCore.App から削除されたアセンブリ」に説明されているスタンドアロン パッケージではなく共有フレームワークで出荷されるようになりました。

導入されたバージョン

3.0

以前の動作

AddAuthorization メソッドは Microsoft.AspNetCore.Authorization にありました。

新しい動作

AddAuthorization メソッドは Microsoft.AspNetCore.Authorization.Policy にあります。 AddAuthorizationCore は、古いメソッドの新しい名前です。

変更理由

AddAuthorization は、承認に必要な一般的なすべてのサービスを追加するのにより適切なメソッド名です。

Microsoft.AspNetCore.Authorization.Policy に参照を追加するか、代わりに AddAuthorizationCore を使用します。

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.Extensions.DependencyInjection.AuthorizationServiceCollectionExtensions.AddAuthorization(IServiceCollection, Action<AuthorizationOptions>)

承認:AuthorizationFilterContext.Filters から IAllowAnonymous を削除

ASP.NET Core 3.0 時点で、MVC は、コントローラーとアクション メソッドで検出された [AllowAnonymous] 属性に対して AllowAnonymousFilters を追加しません。 この変更は、AuthorizeAttribute の派生物についてはローカルに対処されますが、IAsyncAuthorizationFilter と IAuthorizationFilter の実装では破壊的変更です。 [TypeFilter] 属性でラップするこのような実装は、構成と依存関係の挿入の両方が必要な場合に、厳密に型指定された属性ベースの承認を実現するための一般的でサポートされる方法です。

導入されたバージョン

3.0

以前の動作

IAllowAnonymous が AuthorizationFilterContext.Filters コレクションに表示されました。 このインターフェイスの存在をテストすることは、個々のコントローラー メソッドでフィルターをオーバーライドまたは無効にするための有効なアプローチでした。

新しい動作

IAllowAnonymous は AuthorizationFilterContext.Filters コレクションに表示されなくなりました。 以前の動作に依存する IAsyncAuthorizationFilter の実装では、通常、HTTP 401 権限なしまたは HTTP 403 禁止応答が断続的に発生します。

変更理由

新しいエンドポイント ルーティング戦略が ASP.NET Core 3.0 で導入されました。

エンドポイント メタデータで IAllowAnonymousを検索します。 次に例を示します。

var endpoint = context.HttpContext.GetEndpoint();
if (endpoint?.Metadata?.GetMetadata<IAllowAnonymous>() != null)
{
}

この手法の例については、こちらの HasAllowAnonymous メソッドを参照してください。

カテゴリ

ASP.NET Core

影響を受ける API

なし

承認:IAuthorizationPolicyProvider の実装に新しいメソッドが必要

ASP.NET Core 3.0 では、IAuthorizationPolicyProvider に新しい GetFallbackPolicyAsync メソッドが追加されました。 このフォールバック ポリシーは、ポリシーが指定されていない場合に、承認ミドルウェアによって使用されます。

詳細については、dotnet/aspnetcore#9759 を参照してください。

導入されたバージョン

3.0

以前の動作

IAuthorizationPolicyProvider の実装には、GetFallbackPolicyAsync メソッドは必要ありませんでした。

新しい動作

IAuthorizationPolicyProvider の実装には、GetFallbackPolicyAsync メソッドが必要です。

変更理由

ポリシーが指定されていない場合に新しい AuthorizationMiddleware を使用にするには、新しいメソッドが必要でした。

IAuthorizationPolicyProvider の実装に GetFallbackPolicyAsync メソッドを追加します。

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

キャッシュ:CompactOnMemoryPressure プロパティの削除

ASP.NET Core 3.0 のリリースでは、古い MemoryCacheOptions API が削除されました。

変更の説明

この変更は、aspnet/Caching#221 に対するフォローアップです。 ディスカッションについては、dotnet/extensions#1062 を参照してください。

導入されたバージョン

3.0

以前の動作

MemoryCacheOptions.CompactOnMemoryPressure プロパティを使用できました。

新しい動作

MemoryCacheOptions.CompactOnMemoryPressure プロパティは削除されました。

変更理由

キャッシュを自動的に圧縮すると、問題が発生しました。 予期しない動作を避けるため、キャッシュは必要なときにのみ圧縮する必要があります。

キャッシュを圧縮するには、MemoryCache にダウンキャストし、必要に応じて Compact を呼び出します。

カテゴリ

ASP.NET Core

影響を受ける API

MemoryCacheOptions.CompactOnMemoryPressure

キャッシュ:Microsoft.Extensions.Caching.SqlServer で新しい SqlClient パッケージを使用

Microsoft.Extensions.Caching.SqlServer パッケージでは、System.Data.SqlClient パッケージの代わりに、新しい Microsoft.Data.SqlClient パッケージが使用されます。 この変更により、動作のわずかな破壊的変更が発生する可能性があります。 詳細については、「Introducing the new Microsoft.Data.SqlClient (新しい Microsoft.Data.SqlClient の導入)」をご覧ください。

導入されたバージョン

3.0

以前の動作

Microsoft.Extensions.Caching.SqlServer パッケージで、System.Data.SqlClient パッケージが使用されていました。

新しい動作

Microsoft.Extensions.Caching.SqlServer で、Microsoft.Data.SqlClient パッケージが使用されるようになりました。

変更理由

Microsoft.Data.SqlClient は、System.Data.SqlClient から構築された新しいパッケージです。 今後、機能の新しい動作はすべてこのパッケージで実行されます。

Microsoft.Extensions.Caching.SqlServer パッケージによって返される型を使用し、それらを System.Data.SqlClient の型にキャストしている場合を除き、この破壊的変更について気にする必要はありません。 たとえば、DbConnection を以前の SqlConnection 型にキャストしている場合は、キャストを新しい Microsoft.Data.SqlClient.SqlConnection 型に変更する必要があります。

カテゴリ

ASP.NET Core

影響を受ける API

なし

キャッシュ:ResponseCaching の "pubternal" 型を internal に変更

ASP.NET Core 3.0 では、ResponseCaching の "pubternal" 型が internal に変更されました。

また、IResponseCachingPolicyProvider と IResponseCachingKeyProvider の既定の実装は、AddResponseCaching メソッドの一部としてサービスに追加されなくなりました。

変更の説明

ASP.NET Core では、"pubternal" 型は public として宣言されますが、.Internal サフィックスが付加された名前空間に存在します。 これらの型は public ですが、サポート ポリシーがなく、破壊的変更の対象となります。 残念ながら、これらの型が誤って使用されることが多かったため、これらのプロジェクトに破壊的変更が加えられ、フレームワークを維持する機能が制限されることになりました。

導入されたバージョン

3.0

以前の動作

これらの型は公開されていましたが、サポートされていませんでした。

新しい動作

これらの型は internal になりました。

変更理由

internal スコープでは、サポートされていないポリシーが適切に反映されます。

アプリまたはライブラリで使用される型をコピーします。

カテゴリ

ASP.NET Core

影響を受ける API

データの保護: DataProtection.Blobs では新しい Azure Storage API が使用されます

Azure.Extensions.AspNetCore.DataProtection.Blobs は Azure Storage ライブラリに依存します。 これらのライブラリで、アセンブリ、パッケージ、名前空間の名前が変更されました。 ASP.NET Core 3.0 以降、Azure.Extensions.AspNetCore.DataProtection.Blobs では Azure.Storage. というプレフィックスが付いた新しい API およびパッケージが使用されます。

Azure Storage API に関する質問については、https://github.com/Azure/azure-storage-net を使用してください。 この問題に関するディスカッションについては、dotnet/aspnetcore#19570 を参照してください。

導入されたバージョン

3.0

以前の動作

パッケージでは WindowsAzure.Storage NuGet パッケージが参照されていました。 パッケージでは Microsoft.Azure.Storage.Blob NuGet パッケージが参照されています。

新しい動作

パッケージでは Azure.Storage.Blob NuGet パッケージが参照されています。

変更理由

この変更により、Azure.Extensions.AspNetCore.DataProtection.Blobs は推奨される Azure Storage パッケージに移行できるようになります。

ASP.NET Core 3.0 で古い Azure Storage API をまだ使用する必要がある場合は、パッケージ WindowsAzure.Storage または Microsoft.Azure.Storage に対する直接的な依存関係を追加してください。 このパッケージは、新しい Azure.Storage API と共にインストールできます。

多くの場合、アップグレードで必要なのは、新しい名前空間を使用するように using ステートメントを変更することだけです。

- using Microsoft.WindowsAzure.Storage;
- using Microsoft.WindowsAzure.Storage.Blob;
- using Microsoft.Azure.Storage;
- using Microsoft.Azure.Storage.Blob;
+ using Azure.Storage;
+ using Azure.Storage.Blobs;

カテゴリ

ASP.NET Core

影響を受ける API

なし

ホスティング:Windows ホスティング バンドルから AspNetCoreModule V1 を削除

ASP.NET Core 3.0 以降では、Windows ホスティング バンドルに AspNetCoreModule (ANCM) V1 が含まれません。

ANCM V2 は、ANCM OutOfProcess との下位互換性があり、ASP.NET Core 3.0 アプリでの使用をお勧めします。

ディスカッションについては、dotnet/aspnetcore#7095 を参照してください。

導入されたバージョン

3.0

以前の動作

Windows ホスティング バンドルに ANCM V1 が含まれています。

新しい動作

Windows ホスティング バンドルに ANCM V1 が含まれていません。

変更理由

ANCM V2 は、ANCM OutOfProcess との下位互換性があり、ASP.NET Core 3.0 アプリでの使用をお勧めします。

ASP.NET Core 3.0 アプリでお使いの ANCM V2 を使用します。

ANCM V1 が必要な場合は、ASP.NET Core 2.1 または 2.2 の Windows ホスティング バンドルを使用してインストールできます。

この変更によって、次のような ASP.NET Core 3.0 アプリが中断されます。

  • <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName> での ANCM V1 の使用が明示的に選択されている。
  • カスタム web.config ファイルに <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" /> が設定されている。

カテゴリ

ASP.NET Core

影響を受ける API

なし

ホスティング:汎用ホストによる Startup コンストラクター挿入の制限

汎用ホストが Startup クラスのコンストラクター挿入でサポートする型は、IHostEnvironment、IWebHostEnvironment、IConfiguration だけです。 WebHost を使用しているアプリは影響を受けません。

変更の説明

ASP.NET Core 3.0 より前では、コンストラクター挿入は Startup クラスのコンストラクターの任意の型に使用できました。 ASP.NET Core 3.0 では、Web スタックが汎用ホスト ライブラリに再プラットフォーム化されました。 この変更は、テンプレートの Program.cs ファイルで確認できます。

ASP.NET Core 2.x:

https://github.com/dotnet/aspnetcore/blob/5cb615fcbe8559e49042e93394008077e30454c0/src/Templating/src/Microsoft.DotNet.Web.ProjectTemplates/content/EmptyWeb-CSharp/Program.cs#L20-L22

ASP.NET Core 3.0:

https://github.com/dotnet/aspnetcore/blob/b1ca2c1155da3920f0df5108b9fedbe82efaa11c/src/ProjectTemplates/Web.ProjectTemplates/content/EmptyWeb-CSharp/Program.cs#L19-L24

Host では、1 つの依存関係挿入 (DI) コンテナーを使用してアプリをビルドします。 WebHost ホストでは 2 つのコンテナーを使用します。1 つがホスト用、もう 1 つがアプリ用です。 これにより、Startup コンストラクターでは、カスタム サービス挿入がサポートされなくなりました。 挿入できるのは、IHostEnvironment、IWebHostEnvironment、IConfiguration だけです。 この変更により、シングルトン サービスの重複作成などの DI の問題を防ぐことができます。

導入されたバージョン

3.0

変更理由

この変更は、汎用ホスト ライブラリへの Web スタックの再プラットフォーム化の結果です。

サービスを Startup.Configure メソッド シグネチャに挿入します。 次に例を示します。

public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)

カテゴリ

ASP.NET Core

影響を受ける API

なし

ホスティング:IIS アウトプロセス アプリ用に HTTPS リダイレクトを有効化

IIS アウトプロセスでホストするための ASP.NET Core モジュール (ANCM) のバージョン 13.0.19218.0 により、ASP.NET Core 3.0 および 2.2 アプリに既存の HTTPS リダイレクト機能が有効になります。

ディスカッションについては、dotnet/AspNetCore#15243 を参照してください。

導入されたバージョン

3.0

以前の動作

ASP.NET Core 2.1 プロジェクト テンプレートで、UseHttpsRedirection や UseHsts などの HTTPS ミドルウェア メソッドのサポートが初めて導入されました。 開発中のアプリでは既定のポート 443 が使用されないため、HTTPS リダイレクトを有効にするには構成を追加する必要がありました。 HTTP Strict Transport Security (HSTS) は、要求で既に HTTPS が使用されている場合にのみアクティブになります。 localhost は既定ではスキップされます。

新しい動作

ASP.NET Core 3.0 では、IIS HTTPS シナリオが強化されました。 この強化により、アプリがサーバーの HTTPS ポートを検出し、既定で UseHttpsRedirection を動作させることができました。 インプロセス コンポーネントでは、IServerAddresses 機能を使用してポート検出が行われていました。この機能は、インプロセス ライブラリがフレームワークでバージョン管理されているため、ASP.NET Core 3.0 アプリにのみ影響します。 アウトプロセス コンポーネントが、ASPNETCORE_HTTPS_PORT 環境変数を自動的に追加するように変更されました。 アプトプロセス コンポーネントはグローバルに共有されるため、この変更によって ASP.NET Core 2.2 と 3.0 の両方のアプリが影響を受けました。 ASP.NET Core 2.1 アプリは、既定で以前のバージョンの ANCM を使用しているため、響を受けません。

上記の動作は、ASP.NET Core 2.x での動作の変更を元に戻すために ASP.NET Core 3.0.1 および 3.1.0 Preview 3 で変更されました。 これらの変更は、IIS アウトプロセス アプリにのみ影響します。

前に説明したように、ASP.NET Core 3.0.0 をインストールすると、ASP.NET Core 2.x アプリで UseHttpsRedirection ミドルウェアもアクティブになるという副作用がありました。 ASP.NET Core 3.0.1 と 3.1.0 Preview 3 では、インストールによって ASP.NET Core 2.x アプリに影響を及ぼさないよう、ANCM に変更が加えられました。 ANCM が ASP.NET Core 3.0.0 で設定した ASPNETCORE_HTTPS_PORT 環境変数は、ASP.NET Core 3.0.1 および 3.1.0 Preview 3 で ASPNETCORE_ANCM_HTTPS_PORT に変更されました。 これらのリリースでは、新しい変数と古い変数の両方を理解するように UseHttpsRedirection も更新されました。 ASP.NET Core 2.x は更新されません。 その結果、既定で無効になっている前の動作に戻ります。

変更理由

ASP.NET Core 3.0 の機能を向上するため。

すべてのクライアントで HTTPS を使用する場合は、アクションは必要ありません。 一部のクライアントに HTTP の使用を許可するには、次のいずれかの手順を行います。

  • プロジェクトの Startup.Configure メソッドから UseHttpsRedirection と UseHsts への呼び出しを削除し、アプリを再デプロイします。

  • web.config ファイルで、ASPNETCORE_HTTPS_PORT 環境変数を空の文字列に設定します。 この変更は、アプリを再デプロイしなくても、サーバー上で直接行うことができます。 次に例を示します。

    <aspNetCore processPath="dotnet" arguments=".\WebApplication3.dll" stdoutLogEnabled="false" stdoutLogFile="\\?\%home%\LogFiles\stdout" >
    <environmentVariables>
    <environmentVariable name="ASPNETCORE_HTTPS_PORT" value="" />
    </environmentVariables>
</aspNetCore>

UseHttpsRedirection は引き続き次のことができます。

  • ASPNETCORE_HTTPS_PORT 環境変数を適切なポート番号 (ほとんどの運用シナリオでは 443) に設定することによって ASP.NET Core 2.x で手動でアクティブ化する。
  • 空の文字列値を使用して ASPNETCORE_ANCM_HTTPS_PORT を定義することで、ASP.NET Core 3.x で非アクティブ化する。 この値は、前の ASPNETCORE_HTTPS_PORT の例と同じ方法で設定されます。

ASP.NET Core 3.0.0 アプリを実行しているマシンでは、ASP.NET Core 3.1.0 Preview 3 ANCM をインストールする前に、ASP.NET Core 3.0.1 ランタイムをインストールする必要があります。 これにより、ASP.NET Core 3.0 アプリで引き続き UseHttpsRedirection を期待どおりに動作させることができます。

Azure App Service では、ANCM はそのグローバルな性質のため、ランタイムとは別のスケジュールでデプロイされます。 ANCM は、ASP.NET Core3.0.1 と 3.1.0 がデプロイされた後に、これらの変更とともに Azure にデプロイされました。

カテゴリ

ASP.NET Core

影響を受ける API

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

ホスティング: IHostingEnvironment と IApplicationLifetime の型が不使用とマークされ、置き換えられました

既存の IHostingEnvironment と IApplicationLifetime の型を置き換えるために新しい型が導入されました。

導入されたバージョン

3.0

以前の動作

Microsoft.Extensions.Hosting および Microsoft.AspNetCore.Hosting の 2 つの IHostingEnvironment および IApplicationLifetime という型がありました。

新しい動作

古い型は不使用とマークされ、新しい型に置き換えられています。

変更理由

Microsoft.Extensions.Hosting が ASP.NET Core 2.1 で導入されたときに、IHostingEnvironment や IApplicationLifetime などの一部の型が Microsoft.AspNetCore.Hosting からコピーされました。 ASP.NET Core 3.0 の一部の変更により、アプリに Microsoft.Extensions.Hosting と Microsoft.AspNetCore.Hosting の両方の名前空間が含まれるようになります。 これらの重複する型を使用すると、両方の名前空間が参照されるときに "あいまいな参照" コンパイラ エラーが発生します。

次のように、古い型の使用を新しく導入された型に置き換えます。

古い型 (警告):

新しい型:

新しい IHostEnvironment、IsDevelopment および IsProduction 拡張メソッドは、Microsoft.Extensions.Hosting 名前空間にあります。 その名前空間は、プロジェクトに追加する必要がある場合があります。

カテゴリ

ASP.NET Core

影響を受ける API

ホスティング:WebHostBuilder 依存関係から ObjectPoolProvider を削除

ASP.NET Core の定額課金を増やすために、ObjectPoolProvider が主な依存関係のセットから削除されました。 ObjectPoolProvider に依存する特定のコンポーネント自体で、それが追加されるようになりました。

ディスカッションについては、dotnet/aspnetcore#5944 を参照してください。

導入されたバージョン

3.0

以前の動作

WebHostBuilder によって、DI コンテナーに既定で ObjectPoolProvider が提供されます。

新しい動作

WebHostBuilder によって、DI コンテナーに既定で ObjectPoolProvider が提供されなくなりました。

変更理由

この変更は、ASP.NET Core の定額課金を増やすために行われました。

コンポーネントに ObjectPoolProvider が必要な場合は、IServiceCollection を介して依存関係に追加する必要があります。

カテゴリ

ASP.NET Core

影響を受ける API

なし

HTTP:DefaultHttpContext の機能拡張の削除

ASP.NET Core 3.0 のパフォーマンスの改善の一環として、DefaultHttpContext の機能拡張が削除されました。 クラスは sealed になりました。 詳細については、dotnet/aspnetcore#6504 を参照してください。

単体テストで Mock<DefaultHttpContext> を使用する場合は、代わりに Mock<HttpContext> または new DefaultHttpContext() を使用してください。

ディスカッションについては、dotnet/aspnetcore#6534 を参照してください。

導入されたバージョン

3.0

以前の動作

クラスは DefaultHttpContext から派生できます。

新しい動作

クラスは DefaultHttpContext から派生できません。

変更理由

機能拡張は HttpContext のプーリングを可能にするために当初提供されていましたが、不要な複雑さをもたらし、他の最適化の妨げとなっていました。

単体テストで Mock<DefaultHttpContext> を使用する場合、今後は代わりに Mock<HttpContext> を使用してください。

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.AspNetCore.Http.DefaultHttpContext

HTTP: HeaderNames の定数を静的読み取り専用に変更

ASP.NET Core 3.0 Preview 5 以降、Microsoft.Net.Http.Headers.HeaderNames のフィールドが const から static readonly に変更されました。

ディスカッションについては、dotnet/aspnetcore#9514 を参照してください。

導入されたバージョン

3.0

以前の動作

これらのフィールドは以前は const でした。

新しい動作

これらのフィールドは static readonly になりました。

変更理由

変更:

  • アセンブリ境界を越えて値が埋め込まれるのを防ぎ、必要に応じて値を修正できるようにします。
  • 参照の等価性チェックの高速化を可能にします。

3.0 に対して再コンパイルします。 これらのフィールドを次の方法で使用しているソース コードはそれを実行できなくなりました。

  • 属性引数として使用
  • switch ステートメントで case として使用
  • 別の const を定義するときに使用

この破壊的変更を回避するには、ヘッダー名の自己定義型の定数または文字列リテラルの使用に切り替えます。

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.Net.Http.Headers.HeaderNames

HTTP:応答本文のインフラストラクチャの変更

HTTP 応答本文を支えるインフラストラクチャが変更されました。 HttpResponse を直接使用する場合は、コードを変更する必要はありません。 HttpResponse.Body をラップまたは置換する場合や HttpContext.Features にアクセスする場合は、以下をお読みください。

導入されたバージョン

3.0

以前の動作

HTTP 応答本文に関連付けられた次の 3 つの API がありました。

  • IHttpResponseFeature.Body
  • IHttpSendFileFeature.SendFileAsync
  • IHttpBufferingFeature.DisableResponseBuffering

新しい動作

HttpResponse.Body を置き換えると、IHttpResponseBodyFeature 全体が、StreamResponseBodyFeature を使用して予想されるすべての API の既定の実装を提供する特定のストリームのラッパーに置き換えられます。 元のストリームに戻すと、この変更が元に戻されます。

変更理由

目的は、応答本文の API を単一の新しい機能インターフェイスに結合することです。

IHttpResponseFeature.Body、IHttpSendFileFeature、または IHttpBufferingFeature を以前に使用していた場所で IHttpResponseBodyFeature を使用します。

カテゴリ

ASP.NET Core

影響を受ける API

SameSite は、一部のクロスサイト リクエスト フォージェリ (CSRF) 攻撃の軽減に貢献する cookie のオプションです。 このオプションが初めて導入されたとき、さまざまな ASP.NET Core API で使用されていた既定値に整合性がありませんでした。 整合性がないことで、結果は混乱を招きました。 ASP.NET Core 3.0 より、この既定値の整合性が改善されました。 この機能はコンポーネントごとに選択する必要があります。

導入されたバージョン

3.0

以前の動作

同様の ASP.NET Core API で異なる既定 SameSiteMode 値が使用されました。 不整合の例は HttpResponse.Cookies.Append(String, String) と HttpResponse.Cookies.Append(String, String, CookieOptions) で確認できます。それぞれ、既定値は SameSiteMode.None と SameSiteMode.Lax でした。

新しい動作

影響を受ける API の既定値はすべて SameSiteMode.None になります。

変更理由

既定値が変更され、SameSite がオプトイン機能になりました。

cookie を出す各コンポーネントでは、そのシナリオに SameSite が適切かどうかを決定する必要があります。 影響を受ける API の使用状況を確認し、必要に応じて SameSite を再構成します。

カテゴリ

ASP.NET Core

影響を受ける API

HTTP: すべてのサーバーで同期 IO が無効になっています

ASP.NET Core 3.0 以降では、同期サーバー操作は既定で無効になっています。

変更の説明

AllowSynchronousIO は、HttpRequest.Body.Read、HttpResponse.Body.Write、Stream.Flush などの同期 IO API を有効または無効にする各サーバーのオプションです。 これらの API は長い間、スレッドの枯渇とアプリのハングの原因になっていました。 ASP.NET Core 3.0 Preview 3 以降では、これらの同期操作は既定で無効になっています。

影響を受けるサーバー:

  • Kestrel
  • HttpSys
  • IIS インプロセス
  • TestServer

次のようなエラーが発生する可能性があります。

  • Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

各サーバーには、この動作を制御する AllowSynchronousIO オプションがあり、そのすべての既定値は現在、false です。

この動作は、一時的な軽減策として、要求ごとにオーバーライドすることもできます。 次に例を示します。

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

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

ディスカッションについては、dotnet/aspnetcore#7644 を参照してください。

導入されたバージョン

3.0

以前の動作

HttpRequest.Body.Read、HttpResponse.Body.Write、および Stream.Flush が既定で許可されていました。

新しい動作

これらの同期 API は、既定では許可されません。

次のようなエラーが発生する可能性があります。

  • Synchronous operations are disallowed. Call ReadAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
  • Synchronous operations are disallowed. Call FlushAsync or set AllowSynchronousIO to true instead.

変更理由

これらの同期 API は長い間、スレッドの枯渇とアプリのハングの原因になっていました。 ASP.NET Core 3.0 Preview 3 以降では、同期操作は既定で無効になっています。

非同期バージョンのメソッドを使用します。 この動作は、一時的な軽減策として、要求ごとにオーバーライドすることもできます。

var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();
if (syncIOFeature != null)
{
    syncIOFeature.AllowSynchronousIO = true;
}

カテゴリ

ASP.NET Core

影響を受ける API

ID:AddDefaultUI メソッド オーバーロードが削除されました

ASP.NET Core 3.0 以降では、IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) メソッド オーバーロードはなくなりました。

導入されたバージョン

3.0

変更理由

この変更は、静的 Web アセット機能が導入された結果でした。

2 つの引数を取るオーバーロードの代わりに IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) を呼び出します。 ブートストラップ 3 を使用している場合、プロジェクト ファイルの <PropertyGroup> 要素に次の行も追加します。

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

カテゴリ

ASP.NET Core

影響を受ける API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

ID: UI の既定の Bootstrap のバージョンが変更された

ASP.NET Core 3.0 以降、ID UI では既定で Bootstrap のバージョン 4 が使用されています。

導入されたバージョン

3.0

以前の動作

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); メソッドの呼び出しは services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3); と同じでした

新しい動作

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); メソッドの呼び出しは services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4); と同じです

変更理由

Bootstrap 4 は ASP.NET Core 3.0 の期間中にリリースされました。

既定の ID UI を使用し、次の例に示すように Startup.ConfigureServices にそれを追加している場合、この変更による影響を受けます。

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();

次のいずれかのアクションを実行します。

  • 移行ガイドを使用して、Bootstrap 4 を使用するようにアプリを移行します。

  • Bootstrap 3 の使用を強制するように、Startup.ConfigureServices を更新します。 次に例を示します。

    services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);

カテゴリ

ASP.NET Core

影響を受ける API

なし

ID:SignInAsync が認証されていない ID に対して例外をスロー

既定では、SignInAsync は、IsAuthenticated が false であるプリンシパル/ID に対して例外をスローします。

導入されたバージョン

3.0

以前の動作

SignInAsync は、IsAuthenticated が false である ID も含め、すべてのプリンシパル/ID を受け入れます。

新しい動作

既定では、SignInAsync は、IsAuthenticated が false であるプリンシパル/ID に対して例外をスローします。 この動作を抑制する新しいフラグがありますが、既定の動作が変更されました。

変更理由

既定では、これらのプリンシパルは [Authorize] / RequireAuthenticatedUser() によって拒否されていたため、以前の動作には問題がありました。

ASP.NET Core 3.0 Preview 6 では、AuthenticationOptions の RequireAuthenticatedSignIn フラグが既定で true に設定されています。 以前の動作を復元するには、このフラグを false に設定します。

カテゴリ

ASP.NET Core

影響を受ける API

なし

ID:SignInManager コンストラクターで新しいパラメーターの受け入れ

ASP.NET Core 3.0 以降、SignInManager コンストラクターに新しい IUserConfirmation<TUser> パラメーターが追加されました。 詳細については、dotnet/aspnetcore#8356 を参照してください。

導入されたバージョン

3.0

変更理由

変更の動機は、ID での新しいメール/確認フローのサポートを追加するためでした。

手動で SignInManager を構築している場合は、IUserConfirmation の実装を提供するか、依存関係の挿入から 1 つを取得して提供します。

カテゴリ

ASP.NET Core

影響を受ける API

SignInManager<TUser>

ID:UI で静的な Web 資産機能を使用

ASP.NET Core 3.0 では静的な Web 資産機能が導入され、ID UI でこれが導入されました。

変更の説明

ID UI で静的な Web 資産機能が導入された結果として、次のようになります。

  • フレームワークの選択は、プロジェクト ファイルで IdentityUIFrameworkVersion プロパティを使用して行います。
  • Bootstrap 4 が、ID UI の既定の UI フレームワークです。 Bootstrap 3 はサポートが終了したので、サポートされているバージョンへの移行を検討する必要があります。

導入されたバージョン

3.0

以前の動作

ID UI の既定の UI フレームワークは Bootstrap 3 でした。 UI フレームワークは、Startup.ConfigureServices で AddDefaultUI メソッド呼び出しのパラメーターを使用して構成できました。

新しい動作

ID UI の既定の UI フレームワークは Bootstrap 4 です。 UI フレームワークは、AddDefaultUI メソッド呼び出し内ではなく、プロジェクト ファイル内で構成する必要があります。

変更理由

静的な Web 資産機能を導入するには、UI フレームワークの構成を MSBuild に移行する必要がありました。 埋め込むフレームワークは、実行時に決定されるのではなく、ビルド時に決定されます。

サイトの UI を見直して、新しい Bootstrap 4 コンポーネントに互換性があることを確認します。 必要に応じて、IdentityUIFrameworkVersion MSBuild プロパティを使用して Bootstrap 3 に戻します。 このプロパティを、プロジェクト ファイルの <PropertyGroup> 要素に追加します。

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

カテゴリ

ASP.NET Core

影響を受ける API

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Kestrel:接続アダプターを削除

"pubternal" API を public に移すための移行の一環として、IConnectionAdapter の概念が Kestrel から削除されました。 接続アダプターは、接続ミドルウェア (ASP.NET Core パイプラインの HTTP ミドルウェアに似ていますが、下位レベルの接続用) で置き換えられつつあります。 HTTPS および接続のログ記録は接続アダプターから接続ミドルウェアに移されました。 それらの拡張メソッドは引き続きシームレスに動作しますが、実装の詳細が変更されています。

詳細については、dotnet/aspnetcore#11412 を参照してください。 ディスカッションについては、dotnet/aspnetcore#11475 を参照してください。

導入されたバージョン

3.0

以前の動作

Kestrel 拡張コンポーネントは IConnectionAdapter を使用して作成されていました。

新しい動作

Kestrel 拡張コンポーネントは、ミドルウェアとして作成されます。

変更理由

この変更は、より柔軟な拡張性アーキテクチャを提供することを目的としています。

ここに示すように、IConnectionAdapter のすべての実装を、新しいミドルウェア パターンを使用するように変換します。

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter

Kestrel:空の HTTPS アセンブリを削除

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

導入されたバージョン

3.0

変更理由

ASP.NET Core 2.1 では、Microsoft.AspNetCore.Server.Kestrel.Https のコンテンツが Microsoft.AspNetCore.Server.Kestrel.Core に移動されました。 この変更は、[TypeForwardedTo] 属性を使用して非破壊的な方法で行われました。

  • Microsoft.AspNetCore.Server.Kestrel.Https 2.0 を参照するライブラリでは、ASP.NET Core のすべての依存関係を 2.1 以降に更新する必要があります。 そうしないと、ASP.NET Core 3.0 アプリに読み込んだときに破損する可能性があります。
  • ASP.NET Core 2.1 以降をターゲットとするアプリとライブラリでは、Microsoft.AspNetCore.Server.Kestrel.Https NuGet パッケージへの直接参照をすべて削除する必要があります。

カテゴリ

ASP.NET Core

影響を受ける API

なし

Kestrel:要求トレーラー ヘッダーを新しいコレクションに移動

以前のバージョンでは、要求本文が最後まで読み取られると、Kestrel によって HTTP/1.1 チャンク トレーラー ヘッダーが要求ヘッダー コレクションに追加されていました。 この動作により、ヘッダーとトレーラー間のあいまいさに関する懸念が生じていました。 トレーラーを新しいコレクションに移動することが決定されました。

HTTP/2 要求トレーラーは ASP.NET Core 2.2 では使用できませんでしたが、ASP.NET Core 3.0 ではこの新しいコレクションでも使用できるようになりました。

これらのトレーラーにアクセスするために、新しい要求拡張メソッドが追加されました。

HTTP/1.1 トレーラーは、要求本文全体が読み取られると利用可能になります。

HTTP/2 トレーラーは、クライアントから受信すると利用可能になります。 クライアントは、要求本文全体がサーバーによって少なくともバッファーされるまで、トレーラーを送信しません。 バッファー領域を解放するために、要求本文を読み取ることが必要な場合があります。 要求本文を最後まで読み取ると、トレーラーをいつでも使用できます。 トレーラーは本文の終わりをマークします。

導入されたバージョン

3.0

以前の動作

要求トレーラー ヘッダーは、HttpRequest.Headers コレクションに追加されます。

新しい動作

要求トレーラー ヘッダーは、HttpRequest.Headers コレクションには存在しません。 トレーラー ヘッダーにアクセスするには、HttpRequest で次の拡張メソッドを使用します。

  • GetDeclaredTrailers() - 本文の後に予想されるトレーラーを示す、要求の "Trailer" ヘッダーを取得します。
  • SupportsTrailers() - 要求でトレーラー ヘッダーの受信がサポートされているかどうかを示します。
  • CheckTrailersAvailable() - 要求でトレーラーがサポートされているかどうかと、それらを読み取りに使用できるかどうかを確認します。
  • GetTrailer(string trailerName) - 要求された末尾のヘッダーを応答から取得します。

変更理由

トレーラーは、gRPC などのシナリオにおける重要な機能です。 要求ヘッダーへのトレーラーのマージは、ユーザーの混乱を招いていました。

トレーラーにアクセスするには、HttpRequest でトレーラー関連の拡張メソッドを使用します。

カテゴリ

ASP.NET Core

影響を受ける API

HttpRequest.Headers

Kestrel: トランスポートの抽象化を削除して公開

"pubternal" API からの移行の一環として、Kestrel トランスポート層の API がパブリック インターフェイスとして Microsoft.AspNetCore.Connections.Abstractions ライブラリに公開されています。

導入されたバージョン

3.0

以前の動作

  • トランスポート関連の抽象化は、Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions ライブラリで提供されていました。
  • ListenOptions.NoDelay プロパティが使用可能でした。

新しい動作

  • ...Transport.Abstractions ライブラリの最も使用されている機能を公開するために、Microsoft.AspNetCore.Connections.Abstractions ライブラリに IConnectionListener インターフェイスが導入されました。
  • トランスポート オプション (LibuvTransportOptions および SocketTransportOptions) で、NoDelay が使用できるようになりました。
  • SchedulingMode は使用できなくなりました。

変更理由

ASP.NET Core 3.0 は、"pubternal" API から移行しました。

カテゴリ

ASP.NET Core

影響を受ける API

なし

ローカリゼーション:ResourceManagerWithCultureStringLocalizer と WithCulture を古い形式としてマーク

ResourceManagerWithCultureStringLocalizer クラスと WithCulture インターフェイス メンバーは、特に、ユーザーが独自の IStringLocalizer 実装を作成するときに、ローカライズでユーザーの混乱の原因になることがよくあります。 これらの項目は、IStringLocalizer インスタンスが "言語ごとで、リソースごと" であるという印象をユーザーに与えています。 実際には、インスタンスは "リソースごと" のみである必要があります。 検索対象の言語は、実行時に CultureInfo.CurrentUICulture によって決定されます。 混乱の原因を排除するために、ASP.NET Core 3.0 Preview 3 では、API が古い形式としてマークされました。 これらの API は、将来のリリースで削除される予定です。

コンテキストについては、dotnet/aspnetcore#3324 を参照してください。 ディスカッションについては、dotnet/aspnetcore#7756 を参照してください。

導入されたバージョン

3.0

以前の動作

メソッドは Obsolete としてマークされていませんでした。

新しい動作

メソッドは Obsolete としてマークされています。

変更理由

API が、推奨されていないユース ケースを表していました。 ローカライズの設計について混乱が生じていました。

代わりに ResourceManagerStringLocalizer を使用することをお勧めします。 カルチャは CurrentCulture によって設定できます。 これが適切でない場合は、ResourceManagerWithCultureStringLocalizer のコピーを作成して使用してください。

カテゴリ

ASP.NET Core

影響を受ける API

ログ:internal になった DebugLogger クラス

DebugLogger のアクセス修飾子は、ASP.NET Core 3.0 より前では public でした。 このアクセス修飾子は、ASP.NET Core 3.0 では、internal に変わっています。

導入されたバージョン

3.0

変更理由

次の理由により変更されています。

  • ConsoleLogger などの、その他のロガーの実装との整合性を確保します。
  • API サーフェイスを減らします。

AddDebugILoggingBuilder 拡張メソッドを使用して、デバッグ ログを有効にします。 サービスを手動で登録する必要がある場合、DebugLoggerProvider もまだ public です。

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.Extensions.Logging.Debug.DebugLogger

MVC: コントローラー アクション名から Async サフィックスを削除

dotnet/aspnetcore#4849 への対処の一環として、ASP.NET Core MVC では、アクション名から Async サフィックスが既定で削除されます。 ASP.NET Core 3.0 以降、この変更はルーティングとリンク生成の両方に影響します。

導入されたバージョン

3.0

以前の動作

次の ASP.NET Core MVC コントローラーについて考えてみましょう。

public class ProductController : Controller
{
    public async IActionResult ListAsync()
    {
        var model = await DbContext.Products.ToListAsync();
        return View(model);
    }
}

このアクションは、Product/ListAsync を介してルーティング可能です。 リンクの生成には、Async サフィックスを指定する必要があります。 次に例を示します。

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

新しい動作

ASP.NET Core 3.0 では、このアクションは Product/List を介してルーティング可能です。 リンク生成コードでは、Async サフィックスを省略する必要があります。 次に例を示します。

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

この変更は、[ActionName] 属性を使用して指定された名前には影響しません。 新しい動作は、Startup.ConfigureServices で MvcOptions.SuppressAsyncSuffixInActionNames を false に設定することによって無効にすることができます。

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

変更理由

規則に従い、非同期 .NET メソッドには Async サフィックスを付加します。 ただし、メソッドで MVC アクションを定義する場合、Async サフィックスを使用するのは望ましくありません。

アプリが、名前の Async サフィックスを保持する MVC アクションに依存している場合、次のいずれかの軽減策を選択します。

  • [ActionName] 属性を使用して、元の名前を保持します。
  • Startup.ConfigureServices で MvcOptions.SuppressAsyncSuffixInActionNames を false に設定して、名前の変更を完全に無効にします。
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

カテゴリ

ASP.NET Core

影響を受ける API

なし

MVC:JsonResult を Microsoft.AspNetCore.Mvc.Core に移動

JsonResult は Microsoft.AspNetCore.Mvc.Core アセンブリに移動されました。 この型は、Microsoft.AspNetCore.Mvc.Formatters.Json に定義されていました。 大多数のユーザーのこの問題に対処するために、アセンブリ レベルの [TypeForwardedTo] 属性が Microsoft.AspNetCore.Mvc.Formatters.Json に追加されました。 サードパーティのライブラリを使用するアプリでは問題が発生する可能性があります。

導入されたバージョン

3.0 Preview 6

以前の動作

2.2 ベースのライブラリを使用するアプリは正常にビルドされます。

新しい動作

2.2 ベースのライブラリを使用するアプリはコンパイルに失敗します。 次のテキストのバリエーションを含むエラーが表示されます。

The type 'JsonResult' exists in both 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' and 'Microsoft.AspNetCore.Mvc.Formatters.Json, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

このような問題の例については、dotnet/aspnetcore#7220 を参照してください。

変更理由

aspnet/Announcements#325 で説明されているように、ASP.NET Core の構成に対するプラットフォーム レベルの変更。

2.2 バージョンの Microsoft.AspNetCore.Mvc.Formatters.Json に対してコンパイルされたライブラリでは、すべてのコンシューマーの問題に対処するために再コンパイルが必要になる場合があります。 影響を受ける場合は、ライブラリの作成者にお問い合わせください。 ASP.NET Core 3.0 を対象とするライブラリの再コンパイルを要請してください。

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.AspNetCore.Mvc.JsonResult

MVC:プリコンパイル ツールを非推奨

ASP.NET Core 1.1 では、Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (MVC プリコンパイル ツール) パッケージが導入され、Razor ファイル (.cshtml ファイル) の発行時のコンパイルのサポートが追加されました。 ASP.NET Core 2.1 では、プリコンパイル ツールの機能を拡張するために Razor SDK が導入されました。 Razor SDK では、Razor ファイルのビルドおよび発行時のコンパイルのサポートが追加されました。 SDK では、アプリの起動時間を改善しながら、ビルド時に の ファイルの正確性を確認します。 Razor SDK は既定でオンになっており、その使用を開始するためにジェスチャは必要ありません。

ASP.NET Core 3.0 では、ASP.NET Core 1.1 世代の MVC のプリコンパイル ツールが削除されました。 以前のバージョンのパッケージでは、修正プログラムのリリースで重要なバグおよびセキュリティ修正プログラムを引き続き受け取ります。

導入されたバージョン

3.0

以前の動作

Microsoft.AspNetCore.Mvc.Razor.ViewCompilation パッケージは、MVC Razor ビューをプリコンパイルするために使用されました。

新しい動作

Razor SDK では、この機能がネイティブでサポートされます。 Microsoft.AspNetCore.Mvc.Razor.ViewCompilation パッケージが更新されなくなりました。

変更理由

Razor SDK によって、より多くの機能が提供され、ビルド時に .cshtml ファイルの正確性が確認されます。 また、SDK によってアプリの起動時間が改善されます。

ASP.NET Core 2.1 以降のユーザーの場合は、Razor SDK でのプリコンパイルのネイティブ サポートを使用するように更新します。 バグまたは不足している機能によって Razor SDK への移行が妨げられる場合は、dotnet/aspnetcore で問題を開きます。

カテゴリ

ASP.NET Core

影響を受ける API

なし

MVC: "pubternal" 型を internal に変更

ASP.NET Core 3.0 では、MVC のすべての "pubternal" 型が、サポートされている名前空間で public になるか、必要に応じて internal になるように更新されました。

変更の説明

ASP.NET Core では、"pubternal" 型は public として宣言されますが、.Internal サフィックスが付加された名前空間に存在します。 これらの型は public ですが、サポート ポリシーがなく、破壊的変更の対象となります。 残念ながら、これらの型が誤って使用されることが多かったため、これらのプロジェクトに破壊的変更が加えられ、フレームワークを維持する機能が制限されることになりました。

導入されたバージョン

3.0

以前の動作

MVC の一部の型は public でしたが、.Internal 名前空間に存在していました。 これらの型にはサポート ポリシーがなく、破壊的変更の対象となりました。

新しい動作

このような型はすべて、サポートされている名前空間で public になるか、internal としてマークされるように更新されます。

変更理由

"pubternal" 型が誤って使用されることが多かったため、これらのプロジェクトに破壊的変更が加えられ、フレームワークを維持する機能が制限されることになりました。

真に public になり、サポートされている新しい名前空間に移動された型を使用する場合は、新しい名前空間に一致するように参照を更新してください。

internal としてマークされるようになった型を使用する場合は、代替を見つける必要があります。 以前の "pubternal" 型は、一般的な使用ではサポートされていませんでした。 これらの名前空間に、アプリにとって重要な特定の型が存在する場合は、dotnet/aspnetcore で問題を報告してください。 要求された型を public にするために検討される可能性があります。

カテゴリ

ASP.NET Core

影響を受ける API

この変更には、次の名前空間の型が含まれます。

  • Microsoft.AspNetCore.Mvc.Cors.Internal
  • Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
  • Microsoft.AspNetCore.Mvc.Internal
  • Microsoft.AspNetCore.Mvc.ModelBinding.Internal
  • Microsoft.AspNetCore.Mvc.Razor.Internal
  • Microsoft.AspNetCore.Mvc.RazorPages.Internal
  • Microsoft.AspNetCore.Mvc.TagHelpers.Internal
  • Microsoft.AspNetCore.Mvc.ViewFeatures.Internal

MVC:Web API 互換性 shim を削除

ASP.NET Core 3.0 以降、Microsoft.AspNetCore.Mvc.WebApiCompatShim パッケージは使用できなくなりました。

変更の説明

Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) パッケージは、ASP.NET Core への既存の Web API 実装の移行を簡素化するために、ASP.NET Core と ASP.NET 4.x Web API 2 の部分的な互換性を提供します。 ただし、WebApiCompatShim を使用するアプリでは、ASP.NET Core の最近のリリースで提供される API 関連の機能の利点が得られません。 このような機能として、改善された Open API 仕様の生成、標準化されたエラー処理、クライアント コードの生成などがあります。 3.0 での API の取り組みに重点を置くために、WebApiCompatShim が削除されました。 WebApiCompatShim を使用する既存のアプリは、新しい [ApiController] モデルに移行する必要があります。

導入されたバージョン

3.0

変更理由

Web API 互換性 shim は移行ツールでした。 このツールにより、ASP.NET Core に追加された新しい機能へのユーザー アクセスが制限されます。

この shim の使用を削除し、ASP.NET Core 自体の同様の機能に直接移行します。

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: RazorTemplateEngine API が削除されました

RazorTemplateEngine API が削除され、Microsoft.AspNetCore.Razor.Language.RazorProjectEngine に置き換えられました。

ディスカッションについては、GitHub イシュー dotnet/aspnetcore#25215 を参照してください。

導入されたバージョン

3.0

以前の動作

Razor ファイルのコードを解析し、生成するためにテンプレート エンジンを作成し、使用できます。

新しい動作

Razor ファイルのコードを解析し、生成するために、RazorProjectEngine を作成し、RazorTemplateEngine と同じ種類の情報を提供できます。 RazorProjectEngine からは追加の構成レベルも与えられます。

変更理由

RazorTemplateEngine と既存の実装の結合密度が高すぎました。 Razor の解析および生成パイプラインを正しく構成しようとするとき、この密結合によって問題が増えました。

RazorTemplateEngine ではなく RazorProjectEngine を使用します。 次の例を考えてみます。

RazorProjectEngine の作成と構成
RazorProjectEngine projectEngine =
    RazorProjectEngine.Create(RazorConfiguration.Default,
        RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
        builder =>
        {
            builder.ConfigureClass((document, classNode) =>
            {
                classNode.ClassName = "MyClassName";

                // Can also configure other aspects of the class here.
            });

            // More configuration can go here
        });
Razor ファイルのコードを生成する
RazorProjectItem item = projectEngine.FileSystem.GetItem(
    @"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
    FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);

// Things available
RazorSyntaxTree syntaxTree = output.GetSyntaxTree();
DocumentIntermediateNode intermediateDocument =
    output.GetDocumentIntermediateNode();
RazorCSharpDocument csharpDocument = output.GetCSharpDocument();

カテゴリ

ASP.NET Core

影響を受ける API

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor:実行時コンパイルをパッケージに移動

Razor ビューおよび Razor Pages の実行時コンパイルのサポートが個別のパッケージに移動されました。

導入されたバージョン

3.0

以前の動作

追加のパッケージを必要とせずに、実行時コンパイルを利用できます。

新しい動作

この機能は Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation パッケージに移動されました。

次の API は、実行時コンパイルをサポートするために、以前は Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions で使用できました。 これらの API は、Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions を介して使用できるようになりました。

  • RazorViewEngineOptions.FileProviders は MvcRazorRuntimeCompilationOptions.FileProviders になりました
  • RazorViewEngineOptions.AdditionalCompilationReferences は MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths になりました

また、Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange が削除されました。 ファイルの変更時の再コンパイルは、Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation パッケージを参照することによって既定で有効になります。

変更理由

この変更は、ASP.NET Core 共有フレームワークの Roslyn への依存関係を削除するために必要でした。

Razor ファイルの実行時コンパイルまたは再コンパイルを必要とするアプリでは、次の手順を実行する必要があります。

  1. Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation パッケージへの参照を追加します。

  2. プロジェクトの Startup.ConfigureServices メソッドを更新して、AddRazorRuntimeCompilation の呼び出しを含めます。 次に例を示します。

    services.AddMvc()
    .AddRazorRuntimeCompilation();

カテゴリ

ASP.NET Core

影響を受ける API

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

セッション状態:古い API を削除

セッション Cookie を構成するための古い API が削除されました。 詳細については、aspnet/Announcements#257 を参照してください。

導入されたバージョン

3.0

変更理由

この変更により、Cookie を使用する機能を構成するための API 間の一貫性が適用されます。

削除された API の使用箇所を、置換された新しい API に移行します。 Startup.ConfigureServices での次の例を検討してください。

public void ConfigureServices(ServiceCollection services)
{
    services.AddSession(options =>
    {
        // Removed obsolete APIs
        options.CookieName = "SessionCookie";
        options.CookieDomain = "contoso.com";
        options.CookiePath = "/";
        options.CookieHttpOnly = true;
        options.CookieSecure = CookieSecurePolicy.Always;

        // new API
        options.Cookie.Name = "SessionCookie";
        options.Cookie.Domain = "contoso.com";
        options.Cookie.Path = "/";
        options.Cookie.HttpOnly = true;
        options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
    });
}

カテゴリ

ASP.NET Core

影響を受ける API

共有フレームワーク: Microsoft.AspNetCore.App から削除されたアセンブリ

ASP.NET Core 3.0 以降、ASP.NET Core 共有フレームワーク (Microsoft.AspNetCore.App) には、Microsoft が完全に開発、サポートし、処理可能なファースト パーティのアセンブリだけが含まれています。

変更の説明

この変更は、ASP.NET Core "プラットフォーム" の境界の再定義と考えてください。共有フレームワークは、GitHub を介して誰でもソース ビルドが可能になり、.NET Core 共有フレームワークの既存の利点をアプリに引き続き提供します。 利点として、デプロイのサイズの縮小、修正プログラムの適用の一元化、起動時間の短縮などがあります。

変更の一貫として、いくつかの注目すべき破壊的変更が Microsoft.AspNetCore.App に導入されました。

導入されたバージョン

3.0

以前の動作

プロジェクトでは、プロジェクト ファイル内の <PackageReference> 要素を介して Microsoft.AspNetCore.App を参照していました。

さらに、Microsoft.AspNetCore.App に次のサブコンポーネントが含まれていました。

  • Json.NET (Newtonsoft.Json)
  • Entity Framework Core (Microsoft.EntityFrameworkCore. がプレフィックスとして付加されたアセンブリ)
  • Roslyn (Microsoft.CodeAnalysis)

新しい動作

Microsoft.AspNetCore.App への参照に、プロジェクト ファイル内の <PackageReference> 要素は不要になりました。 .NET Core SDK では、<FrameworkReference> と呼ばれる新しい要素がサポートされています。これは、<PackageReference> に代わって使用されます。

詳細については、dotnet/aspnetcore#3612 を参照してください。

Entity Framework Core は NuGet パッケージとして配布されます。 この変更により、.NET 上の他のすべてのデータ アクセス ライブラリに合わせて配布モデルが調整されます。 さまざまな .NET プラットフォームをサポートしながらイノベーションを継続するための最も簡単なパスが Entity Framework Core に提供されます。 共有フレームワークからの Entity Framework Core の移動は、Microsoft が開発、サポートし、処理可能なライブラリとしての状態には影響しません。 .NET Core のサポート ポリシーは、引き続きこれに対応しています。

Json.NET と Entity Framework Core は、ASP.NET Core と引き続き連携します。 ただし、これらは共有フレームワークには含まれません。

詳細については、「The future of JSON in .NET Core 3.0 (.NET Core 3.0 での JSON の未来)」をご覧ください。 また、共有フレームワークから削除されたバイナリの一覧もご覧ください。

変更理由

この変更により、Microsoft.AspNetCore.App の使用が簡素化され、NuGet パッケージと共有フレームワーク間の重複が削減されます。

この変更の目的の詳細については、こちらのブログ記事をご覧ください。

ASP.NET Core 3.0 以降は、プロジェクトでは、Microsoft.AspNetCore.App のアセンブリを NuGet パッケージとして使用する必要はありません。 ASP.NET Core 共有フレームワークのターゲット設定と使用を簡素化するために、ASP.NET Core 1.0 以降に配布された多くの NuGet パッケージが生成されなくなりました。 これらのパッケージで提供される API は、Microsoft.AspNetCore.App への <FrameworkReference> を使用することで引き続きアプリで使用できます。 一般的な API の例として、Kestrel、MVC、Razor などがあります。

この変更は、ASP.NET Core 2.x の Microsoft.AspNetCore.App を介して参照されるすべてのバイナリに適用されるわけではありません。 重要な例外は次のとおりです。

  • .NET Standard を引き続きターゲットとする Microsoft.Extensions ライブラリは、NuGet パッケージとして利用できます (https://github.com/dotnet/extensions を参照してください)。
  • ASP.NET Core チームによって生成され、Microsoft.AspNetCore.App に含まれていない API。 たとえば、次のコンポーネントは NuGet パッケージとして利用できます。
  • Json.NET のサポートを維持する MVC の拡張機能。 API は、Json.NET と MVC の使用をサポートする NuGet パッケージとして提供されます。 詳細については、ASP.NET Core 移行ガイドを参照してください。
  • SignalR .NET クライアントは、.NET Standard を引き続きサポートし、NuGet パッケージとして配布されます。 これは、Xamarin や UWP など、多くの .NET ランタイムでの使用を目的としています。

詳細については、「Stop producing packages for shared framework assemblies in 3.0 (3.0 における共有フレームワークのアセンブリのパッケージ生成の停止)」をご覧ください。 ディスカッションについては、dotnet/aspnetcore#3757 を参照してください。

カテゴリ

ASP.NET Core

影響を受ける API

共有フレームワーク: Microsoft.AspNetCore.All を削除しました

ASP.NET Core 3.0 以降では、Microsoft.AspNetCore.All メタパッケージと、対応する Microsoft.AspNetCore.All 共有フレームワークが生成されなくなりました。 このパッケージは ASP.NET Core 2.2 で使用することができ、ASP.NET Core 2.1 でサービス更新プログラムを引き続き受け取ることができます。

導入されたバージョン

3.0

以前の動作

アプリでは Microsoft.AspNetCore.All メタパッケージを使用して、.NET Core 上の Microsoft.AspNetCore.All 共有フレームワークをターゲットにすることができました。

新しい動作

.NET Core 3.0 には、Microsoft.AspNetCore.All 共有フレームワークは含まれていません。

変更理由

Microsoft.AspNetCore.All メタパッケージには、多数の外部依存関係が含まれていました。

プロジェクトを移行して、Microsoft.AspNetCore.App フレームワークを使用します。 Microsoft.AspNetCore.All でこれまで提供されていたコンポーネントは、NuGet で引き続き利用できます。 これらのコンポーネントは、共有フレームワークに含まれるのではなく、アプリと共にデプロイされるようになりました。

カテゴリ

ASP.NET Core

影響を受ける API

なし

SignalR:HandshakeProtocol.SuccessHandshakeData を置き換え

HandshakeProtocol.SuccessHandshakeData フィールドが削除され、特定の IHubProtocol が指定された場合に適切なハンドシェイク応答を生成するヘルパー メソッドに置き換えられました。

導入されたバージョン

3.0

以前の動作

HandshakeProtocol.SuccessHandshakeData は、public static ReadOnlyMemory<byte> フィールドでした。

新しい動作

HandshakeProtocol.SuccessHandshakeData は、指定されたプロトコルに基づいて ReadOnlyMemory<byte> を返す staticGetSuccessfulHandshake(IHubProtocol protocol) メソッドに置き換えられました。

変更理由

ハンドシェイク応答に、選択したプロトコルによって変化する非定数の追加フィールドが加えられました。

なし。 この型は、ユーザー コードから使用するように設計されていません。 これは public であり、SignalR サーバーとクライアントの間で共有できます。 また、.NET で記述されたユーザーの SignalR クライアントによって使用されることもあります。 SignalR のユーザーは、この変更による影響を受けません。

カテゴリ

ASP.NET Core

影響を受ける API

HandshakeProtocol.SuccessHandshakeData

SignalR: HubConnection の ResetSendPing メソッドと ResetTimeout メソッドが削除された

ResetSendPing メソッドと ResetTimeout メソッドが、SignalR の HubConnection API から削除されました。 これらのメソッドはもともと内部使用のみを目的としていましたが、ASP.NET Core 2.2 で公開されました。 これらのメソッドは、ASP.NET Core 3.0 Preview 4 リリース以降では使用できません。 ディスカッションについては、dotnet/aspnetcore#8543 を参照してください。

導入されたバージョン

3.0

以前の動作

API を使用できました。

新しい動作

API は削除されています。

変更理由

これらのメソッドはもともと内部使用のみを目的としていましたが、ASP.NET Core 2.2 で公開されました。

これらのメソッドは使用しないでください。

カテゴリ

ASP.NET Core

影響を受ける API

SignalR:HubConnectionContext コンストラクターを変更

オプションの追加を将来においても利用できるように、SignalR の HubConnectionContext コンストラクターが複数のパラメーターではなく、1 つの options 型を受け取るように変更されました。 この変更により、2 つのコンストラクターが、options 型を受け取る 1 つのコンストラクターに置き換えられます。

導入されたバージョン

3.0

以前の動作

HubConnectionContext にはコンストラクターが 2 つあります。

public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);

新しい動作

2 つのコンストラクターが削除され、1 つのコンストラクターに置き換えられました。

public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)

変更理由

新しいコンストラクターでは、新しい options オブジェクトが使用されます。 結果的に、コンストラクターや破壊的変更を増やすことなく、将来にわたり HubConnectionContext の機能を拡張できます。

次のコンストラクターを使用する代わりに:

HubConnectionContext connectionContext = new HubConnectionContext(
    connectionContext,
    keepAliveInterval: TimeSpan.FromSeconds(15),
    loggerFactory,
    clientTimeoutInterval: TimeSpan.FromSeconds(15));

次のコンストラクターを使用します。

HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()
{
    KeepAliveInterval = TimeSpan.FromSeconds(15),
    ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);

カテゴリ

ASP.NET Core

影響を受ける API

SignalR: JavaScript クライアント パッケージ名が変更されました

ASP.NET Core 3.0 Preview 7 で、SignalR JavaScript クライアント パッケージの名前が @aspnet/signalr から @microsoft/signalr に変更されました。 この名前変更は、Azure SignalR Service のおかげで、ASP.NET Core アプリ以外でも SignalR が便利になっている事実を反映しています。

この変更に合わせるため、package.json ファイル、require ステートメント、ECMAScript import ステートメントで参照を変更してください。 この名前変更の一環として API が変更されることはありません。

ディスカッションについては、dotnet/aspnetcore#11637 を参照してください。

導入されたバージョン

3.0

以前の動作

クライアント パッケージの名前は @aspnet/signalr でした。

新しい動作

クライアント パッケージの名前は @microsoft/signalr です。

変更理由

この名前変更は、Azure SignalR Service のおかげで、ASP.NET Core アプリ以外でも SignalR が便利になっていることを表わしています。

新しいパッケージ @microsoft/signalr に切り替えます。

カテゴリ

ASP.NET Core

影響を受ける API

なし

SignalR: UseSignalR および UseConnections メソッドが古いものとしてマークされた

メソッド UseConnections と UseSignalR およびクラス ConnectionsRouteBuilder と HubRouteBuilder は、ASP.NET Core 3.0 では古いものとマークされています。

導入されたバージョン

3.0

以前の動作

SignalR ハブ ルーティングは、UseSignalR または UseConnections を使用して構成されました。

新しい動作

ルーティングを構成する従来の方法は古くなり、エンドポイント ルーティングに置き換えられています。

変更理由

ミドルウェアは、新しいエンドポイント ルーティング システムに移行されています。 ミドルウェアを追加する以前の方法は、古くなっています。

UseSignalR を UseEndpoints に置き換えます。

古いコード:

app.UseSignalR(routes =>
{
    routes.MapHub<SomeHub>("/path");
});

新しいコード:

app.UseEndpoints(endpoints =>
{
    endpoints.MapHub<SomeHub>("/path");
});

カテゴリ

ASP.NET Core

影響を受ける API

SPA:SpaServices および NodeServices を古いとしてマーク

以下の NuGet パッケージの内容は、ASP.NET Core 2.1 以降ではすべて不要になりました。 その結果、以下のパッケージは古いものとしてマークされています。

同じ理由から、以下の npm モジュールは非推奨としてマークされています。

上記のパッケージと npm モジュールは、今後 .NET 5 で削除される予定です。

導入されたバージョン

3.0

以前の動作

非推奨のパッケージと npm モジュールは、ASP.NET Core をさまざまなシングルページ アプリ (SPA) フレームワークと統合するためのものでした。 そのようなフレームワークとしては、Angular、React、React with Redux などがあります。

新しい動作

Microsoft.AspNetCore.SpaServices.Extensions NuGet パッケージには新しい統合メカニズムがあります。 そのパッケージは、ASP.NET Core 2.1 以降、Angular および React プロジェクト テンプレートの基礎になっています。

変更理由

ASP.NET Core では、Angular、React、React with Redux など、さまざまなシングルページ アプリ (SPA) フレームワークとの統合がサポートされています。 当初、これらのフレームワークとの統合は、サーバー側プリレンダリングや Webpack との統合などのシナリオを処理する ASP.NET Core 固有のコンポーネントを使用して行われていました。 時間と共に、業界標準は変化しました。 各 SPA フレームワークにおいて、独自の標準コマンドライン インターフェイスがリリースされました。 たとえば、Angular CLI や create-react-app などです。

2018 年 5 月に ASP.NET Core 2.1 がリリースされたとき、チームは標準の変更に対応しました。 SPA フレームワーク独自のツールチェーンと統合するための、より新しくて簡単な方法が提供されました。 その新しい統合メカニズムはパッケージ Microsoft.AspNetCore.SpaServices.Extensions に存在しており、ASP.NET Core 2.1 以降、Angular および React プロジェクト テンプレートの基礎になっています。

古い ASP.NET Core 固有のコンポーネントは不適切であり、推奨されないことを明確にするために、次のようにしました。

  • 2.1 より前の統合メカニズムは、旧式とマークされています。
  • npm パッケージのサポートは非推奨とマークされています。

これらのパッケージを使用している場合は、次の機能を使用するようにアプリを更新してください。

  • Microsoft.AspNetCore.SpaServices.Extensions パッケージ内のもの。
  • 使用している SPA フレームワークによって提供されるもの

サーバー側プリレンダリングやホット モジュール リロードなどの機能を有効にするには、対応する SPA フレームワークのドキュメントを参照してください。 Microsoft.AspNetCore.SpaServices.Extensions の機能は古くなって "おらず"、引き続きサポートされます。

カテゴリ

ASP.NET Core

影響を受ける API

SPA: SpaServices と NodeServices は今後、コンソール ロガーにフォールバックしません

ログ記録が構成されていない限り、Microsoft.AspNetCore.SpaServices と Microsoft.AspNetCore.NodeServices にはコンソール ログが表示されません。

導入されたバージョン

3.0

以前の動作

ログ記録が構成されていないとき、コンソール ロガーを自動作成する目的で Microsoft.AspNetCore.SpaServices と Microsoft.AspNetCore.NodeServices が使用されます。

新しい動作

ログ記録が構成されていない限り、Microsoft.AspNetCore.SpaServices と Microsoft.AspNetCore.NodeServices にはコンソール ログが表示されません。

変更理由

他の ASP.NET Core パッケージでのログ記録の実装方法に合わせる必要があります。

以前の動作が必要な場合、コンソール ログ記録を構成するために、services.AddLogging(builder => builder.AddConsole()) を Setup.ConfigureServices メソッドに追加します。

カテゴリ

ASP.NET Core

影響を受ける API

なし

ターゲット フレームワーク: .NET Framework のサポートが廃止されました

ASP.NET Core 3.0 以降、.NET Framework はサポート対象外のターゲット フレームワークになりました。

変更の説明

.NET Framework 4.8 は、.NET Framework の最後のメジャー バージョンです。 新しい ASP.NET Core アプリは .NET Core で構築する必要があります。 .NET Core 3.0 リリース以降、ASP.NET Core 3.0 は .NET Core の一部になっていると考えることができます。

.NET Framework で ASP.NET Core を使用しているお客様は、2.1 LTS リリースを使用して完全にサポートされた状態で続行できます。 2.1 のサポートとサービスは、2021 年 8 月 21 日まで継続されます。 .NET サポート ポリシーに従い、この日付は LTS リリースの宣言から 3 年後です。 .NET Framework での ASP.NET Core 2.1 パッケージのサポートは、他のパッケージ ベースの ASP.NET フレームワークのサービス ポリシーと同様に、無制限に延長されます。

.NET Framework から .NET Core への移植の詳細については、.NET Core への移植に関するページを参照してください。

Microsoft.Extensions パッケージ (ログ記録、依存関係の挿入、構成など) と Entity Framework Core は影響を受けません。 .NET Standard はそれらで引き続きサポートされます。

この変更の目的の詳細については、元のブログ記事をご覧ください。

導入されたバージョン

3.0

以前の動作

ASP.NET Core アプリは .NET Core または .NET Framework で実行できました。

新しい動作

ASP.NET Core アプリは .NET Core でのみ実行できます。

次のいずれかのアクションを実行します。

  • ASP.NET Core 2.1 でアプリを保持します。
  • アプリと依存関係を .NET Core に移行します。

カテゴリ

ASP.NET Core

影響を受ける API

なし