次の方法で共有

.NET Core 3.0 の破壊的変更

  • [アーティクル]

.NET Core、ASP.NET Core、または EF Core のバージョン 3.0 に移行する場合、この記事の一覧にある破壊的変更がお使いのアプリに影響する可能性があります。

ASP.NET Core

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

メソッド

"Pubternal" API の削除

ASP.NET Core のパブリック API サーフェイスを管理しやすくするため、*.Internal 名前空間のほとんどの型 ("pubternal" API と呼んでいたもの) が本当に internal になりました。 これらの名前空間のメンバーは、公開 API としてサポートされるべきものではありませんでした。 API の破壊的変更はマイナー リリースで発生する可能性があり、よく発生しています。 ASP.NET Core 3.0 に更新すると、これらの API に依存するコードは破壊的変更の影響を受けます。

詳細については、dotnet/aspnetcore#4932 および dotnet/aspnetcore#11312 を参照してください。

導入されたバージョン

3.0

以前の動作

影響を受ける API は public アクセス修飾子でマークされ、*.Internal 名前空間に存在します。

新しい動作

影響を受ける API は、internal アクセス修飾子でマークされ、そのアセンブリ外のコードでは使用できなくなります。

変更理由

これらの "pubternal" API のガイダンスでは以下が示されていました。

  • 予告なしに変更されることがあります。
  • 破壊的変更を防ぐために、.NET ポリシーの対象ではありません。

API を public (*.Internal 名前空間でも) にしておくことは、ユーザーにとって混乱を招きます。

これらの "pubternal" API の使用を停止します。 代わりの API について不明点がある場合は、dotnet/aspnetcore リポジトリで問題を提起します。

たとえば、ASP.NET Core 2.2 プロジェクトの次の HTTP 要求バッファーリング コードを考えてみます。 EnableRewind 拡張メソッドは、Microsoft.AspNetCore.Http.Internal 名前空間に存在します。

HttpContext.Request.EnableRewind();

ASP.NET Core 3.0 プロジェクトで、EnableRewind 呼び出しを EnableBuffering 拡張メソッドへの呼び出しで置き換えます。 要求バッファーリング機能は、以前と同様に機能します。 EnableBuffering は internal API を呼び出すようになりました。

HttpContext.Request.EnableBuffering();

カテゴリ

ASP.NET Core

影響を受ける API

名前空間名に Internal セグメントが含まれる、Microsoft.AspNetCore.* 名前空間と Microsoft.Extensions.* 名前空間のすべての API。 次に例を示します。

  • Microsoft.AspNetCore.Authentication.Internal
  • Microsoft.AspNetCore.Builder.Internal
  • Microsoft.AspNetCore.DataProtection.Cng.Internal
  • Microsoft.AspNetCore.DataProtection.Internal
  • Microsoft.AspNetCore.Hosting.Internal
  • Microsoft.AspNetCore.Http.Internal
  • Microsoft.AspNetCore.Mvc.Core.Infrastructure
  • Microsoft.AspNetCore.Mvc.Core.Internal
  • 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
  • Microsoft.AspNetCore.Rewrite.Internal
  • Microsoft.AspNetCore.Routing.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure
  • Microsoft.AspNetCore.Server.Kestrel.Https.Internal

認証: 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 では、API が古い形式としてマークされました。 これらの API は、将来のリリースで削除される予定です。

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

導入されたバージョン

3.0

以前の動作

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

新しい動作

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

変更理由

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

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

カテゴリ

ASP.NET Core

影響を受ける API

  • Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
  • Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture

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

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

導入されたバージョン

3.0

変更理由

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

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

AddDebug ILoggingBuilder 拡張メソッドを使用して、デバッグ ログを有効にします。 サービスを手動で登録する必要がある場合、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> を返す static GetSuccessfulHandshake(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

なし

Core .NET ライブラリ

バージョンをレポートする API が、ファイル バージョンではなく製品をレポートするようになりました

.NET Core のバージョンを返す API の多くは、ファイル バージョンではなく製品バージョンを返すようになりました。

変更の説明

.NET Core 2.2 およびそれ以前のバージョンでは、Environment.Version、RuntimeInformation.FrameworkDescription などのメソッドと、.NET Core アセンブリの [ファイルのプロパティ] ダイアログにファイルのバージョンが反映されています。 .NET Core 3.0 以降では、製品のバージョンが反映されています。

次の図は、.NET Core 2.2 (左側) と .NET Core 3.0 (右側) の System.Runtime.dll アセンブリのバージョン情報の違いを示しています。これは、Windows Explorer [ファイルのプロパティ] ダイアログに表示されます。

製品バージョン情報の相違点

導入されたバージョン

3.0

なし。 この変更により、機能性ではなく、バージョン検出を直感的に行う必要があります。

カテゴリ

Core .NET ライブラリ

影響を受ける API

カスタム EncoderFallbackBuffer インスタンスが再帰的にフォールバックしない

カスタム EncoderFallbackBuffer インスタンスが再帰的にフォールバックしません。 EncoderFallbackBuffer.GetNextChar() を実装した場合、文字のシーケンスが変換先のエンコードに変換されるようにする必要があります。 それ以外の場合は、例外が発生します。

変更の説明

文字をバイトに変換する操作中に、ランタイムによって不適切な形式または変換不能な UTF-16 のシーケンスが検出され、それらの文字は EncoderFallbackBuffer.Fallback メソッドに渡されます。 元の変換不能なデータの代わりに置き換える文字は、Fallback メソッドによって決定されますが、これらの文字は、EncoderFallbackBuffer.GetNextChar をループで呼び出すことによってドレインされます。

それからランタイムはこれらの置換文字を、ターゲットのエンコードに変換しようとします。 この操作が成功する場合、ランタイムによって、元の入力文字列の中断した箇所からコード変換が継続されます。

以前は、EncoderFallbackBuffer.GetNextChar() をカスタム実装することにより、変換先のエンコードに変換できなかった文字シーケンスが返されました。 置換文字がターゲットのエンコードにコード変換できない場合、EncoderFallbackBuffer.GetNextChar() メソッドによって新しい置換のシーケンスが返されることを期待し、ランタイムによって置換文字列が使用されて EncoderFallbackBuffer.Fallback メソッドが再度呼び出されます。 この処理は、結果的に、ランタイムによって正しい形式の、変換可能な代替が確認されるまで、または最大再帰数に到達するまで、継続します。

.NET Core 3.0 以降では、EncoderFallbackBuffer.GetNextChar() をカスタム実装した場合、変換先のエンコードに変換できる文字シーケンスが返される必要があります。 置換文字がターゲットのエンコードにコード変換できない場合、ArgumentException がスローされます。 ランタイムは、それ以上 EncoderFallbackBuffer インスタンスに対し、再帰呼び出しを実行しなくなります。

この動作は、次の 3 つの条件がすべて満たされている場合にのみ行われます。

  • ランタイムによって、不正な形式の UTF-16 シーケンスまたはターゲットのエンコードに変換できない UTF-16 シーケンスが検出される。
  • カスタム EncoderFallback が指定された。
  • カスタム EncoderFallback によって、新しい不正な形式の、または変換不能な URT-16 シーケンスへの置換を試行される。

導入されたバージョン

3.0

ほとんどの開発者は、何も措置を講じる必要はありません。

アプリケーションでカスタム EncoderFallback および EncoderFallbackBuffer クラスを使用している場合、Fallback メソッドがランタイムによって最初に呼び出されたときに、EncoderFallbackBuffer.Fallback を実装することで、ターゲットのエンコードに直接変換できる正しい形式の UTF-16 で、データがフォールバック バッファーに入力されるようにします。

カテゴリ

Core .NET ライブラリ

影響を受ける API

浮動小数点の書式設定と解析の動作が変更されました

(Double および Single 型による) 浮動小数点の解析と書式設定の動作が IEEE に準拠するようになりました。 これにより、.NET での浮動小数点型の動作が、他の IEEE 準拠言語の動作と一致するようになります。 たとえば、double.Parse("SomeLiteral") は、double x = SomeLiteral に対して C# で生成される内容と常に一致する必要があります。

変更の説明

.NET Core 2.2 以前のバージョンでは、Double.ToString および Single.ToString を使用した書式設定と Double.Parse、Double.TryParse、Single.Parse、および Single.TryParse を使用した解析は IEEE に準拠していません。 その結果、任意のサポートされている標準またはカスタムの書式設定文字列について、値がラウンドトリップすることを保証できません。 一部の入力では、書式設定された値を解析しようとして失敗する場合や、解析された値は元の値と同じではない場合があります。

.NET Core 3.0 以降、浮動小数点の解析および書式設定操作は IEEE 754 に準拠しています。

次の表は、2 つのコード スニペットと、.NET Core 2.2 と .NET Core 3.1 の間では出力がどのように変化するかを示しています。

コード スニペット .NET Core 2.2 での出力 .NET Core 3.1 での出力
Console.WriteLine((-0.0).ToString()); 0 -0
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

詳細については、「Floating-point parsing and formatting improvements in .NET Core 3.0」(.NET Core 3.0 での浮動小数点の解析と書式設定の強化) に関するブログ記事を参照してください。

導入されたバージョン

3.0

「Floating-point parsing and formatting improvements in .NET Core 3.0」 (.NET Core 3.0 での浮動小数点の解析と書式設定の強化) に関するブログ記事の「Potential impact to existing code」 (既存のコードに対して考えられる影響) セクションでは、以前の動作を維持する必要がある場合にコードに対して加えることができる変更をいくつか提案しています。

  • 書式設定の違いの一部については、別の書式設定文字列を指定することで、以前の動作と同等の動作を得ることができます。
  • 解析の違いについては、以前の動作にフォールバックするためのメカニズムはありません。

カテゴリ

Core .NET ライブラリ

影響を受ける API

浮動小数点の解析操作が失敗したり OverflowException がスローされたりすることがなくなった

浮動小数点の解析メソッドが、Single または Double 浮動小数点の型の範囲外の数値を持つ文字列を解析する場合に、OverflowException をスローしたり、false を返したりすることがなくなりました。

変更の説明

.NET Core 2.2 以前のバージョンでは、Double.Parse および Single.Parse メソッドは、それぞれの型の範囲外の値に対して、OverflowException をスローします。 Double.TryParse および Single.TryParse メソッドは、範囲外の数値を持つ文字列表現に対して false を返します。

.NET Core 3.0 以降、範囲外の数値文字列を解析するときに、Double.Parse、Double.TryParse、Single.Parse、および Single.TryParse の各メソッドが失敗しなくなりました。 代わりに、Double の解析メソッドが、Double.MaxValue を超過する値に対して Double.PositiveInfinity を返し、また Double.MinValue 未満の値に対して Double.NegativeInfinity を返すようになりました。 同様に、Single の解析メソッドが、Single.MaxValue を超過する値に対して Single.PositiveInfinity を返し、また Single.MinValue 未満の値に対して Single.NegativeInfinity を返すようになりました。

この変更は、IEEE 754:2008 に対する準拠の改善のために行われました。

導入されたバージョン

3.0

この変更は、次の 2 つのいずれかの方法でコードに影響を与える可能性があります。

  • コードは、オーバーフローが発生したときに実行される OverflowException のハンドラーに依存します。 この場合、catch ステートメントを削除し、Double.IsInfinity または Single.IsInfinity が true であるかをテストする任意のコードを If ステートメントに含める必要があります。

  • コードは、浮動小数点値が Infinity ではないことを前提としています。 この場合は、必要な PositiveInfinity および NegativeInfinity の浮動小数点値を確認するコードを追加する必要があります。

カテゴリ

Core .NET ライブラリ

影響を受ける API

InvalidAsynchronousStateException が別のアセンブリに移動された

InvalidAsynchronousStateException クラスは移動されました。

変更の説明

.NET Core 2.2 およびそれ以前のバージョンでは、InvalidAsynchronousStateException クラスは System.ComponentModel.TypeConverter アセンブリにあります。

.NET Core 3.0 以降では、System.ComponentModel.Primitives アセンブリに含まれています。

導入されたバージョン

3.0

この変更によって影響を受けるのは、リフレクションを使用し、Assembly.GetType などのメソッドや、型が特定のアセンブリにあることを想定している Activator.CreateInstance のオーバーロードを呼び出すことによって、InvalidAsynchronousStateException を読み込んでいるアプリケーションのみです。 これに該当する場合は、メソッドの呼び出しで参照されているアセンブリを、型の新しいアセンブリの場所を反映するように更新します。

カテゴリ

Core .NET ライブラリ

影響を受ける API

なし。

Unicode のガイドラインに従って不適切な形式の UTF-8 バイト シーケンスを置き換える

UTF8Encoding クラスで、バイトから文字へのコード変換中に不適切な形式の UTF-8 バイト シーケンスが検出された場合、そのシーケンスは出力文字列内で "�" (U+FFFD REPLACEMENT CHARACTER) 文字に置き換えられます。 .NET Core 3.0 では、コード変換の操作中にこの置換を実行するための Unicode ベスト プラクティスに従うことで、以前のバージョンの .NET Core と .NET Framework との差別化が行われています。

これは、新しい System.Text.Unicode.Utf8 型および System.Text.Rune 型の使用を含め、.NET 全体での UTF-8 の処理を向上させようとする、より大きな取り組みの一環です。 UTF8Encoding 型では、新しく導入された型と一致する出力が生成されるよう、エラー処理のメカニズムが向上しています。

変更の説明

.NET Core 3.0 からは、バイトの文字列へのコード変換は、Unicode のベスト プラクティスに基づいて UTF8Encoding クラスによって文字列が置換されます。 使用される置換メカニズムについては、Unicode 標準のバージョン 12.0 のセクション 3.9 (PDF) の「U+FFFD Substitution of Maximal Subparts」 (最大サブパーツの U+FFFD 置換) という見出しを参照してください。

この動作は、入力バイト シーケンスに不正な形式の UTF-8 データが含まれている場合のみ該当します。 また、UTF8Encoding インスタンスが throwOnInvalidBytes: true を使用して構築されている場合、UTF8Encoding インスタンスは U+FFFD 置換を実行せずに無効な入力のスローを続けます。 UTF8Encoding コンストラクターについて詳しくは、「UTF8Encoding(Boolean, Boolean)」をご覧ください。

次の表では、不正な 3 バイトの入力でのこの変更の影響を示します。

不正形式の 3 バイトの入力 .NET Core 3.0 以前の出力 .NET Core 3.0 以降の出力
[ ED A0 90 ] [ FFFD FFFD ] (2 文字の出力) [ FFFD FFFD FFFD ] (3 文字の出力)

3 文字の出力は、前にリンクした Unicode 標準の PDF の "表 3-9" に従って、優先される出力となります。

導入されたバージョン

3.0

開発者側では、何も行う必要はありません。

カテゴリ

Core .NET ライブラリ

影響を受ける API

TypeDescriptionProviderAttribute は別のアセンブリに移動されました

TypeDescriptionProviderAttribute クラスは移動されました。

変更の説明

.NET Core 2.2 およびそれ以前のバージョンでは、TypeDescriptionProviderAttribute クラスは System.ComponentModel.TypeConverter アセンブリにあります。

.NET Core 3.0 以降では、System.ObjectModel アセンブリに含まれています。

導入されたバージョン

3.0

この変更によって影響を受けるのは、リフレクションを使用し、Assembly.GetType などのメソッドや、型が特定のアセンブリにあることを想定している Activator.CreateInstance のオーバーロードを呼び出すことによって、TypeDescriptionProviderAttribute 型を読み込んでいるアプリケーションのみです。 これに該当する場合は、メソッドの呼び出しで参照されているアセンブリを、型の新しいアセンブリの場所を反映するように更新する必要があります。

カテゴリ

Windows フォーム

影響を受ける API

なし。

ZipArchiveEntry による、エントリ サイズに一貫性のないアーカイブ処理の中止

Zip アーカイブは、圧縮されているサイズと圧縮されていないサイズの両方を、中央ディレクトリとローカル ヘッダーに一覧表示します。 また、エントリ データ自体のサイズも示されます。 .NET Core 2.2 以前のバージョンでは、これらの値の一貫性はチェックされませんでした。 .NET Core 3.0 より、これが開始します。

変更の説明

.NET Core 2.2 以前のバージョンでは、ZipArchiveEntry.Open() はローカル ヘッダーが zip ファイルの中央ヘッダーと一致しない場合でも成功します。 圧縮されたストリームの末尾に達するまで、データは圧縮解除されます。これは、その長さが、中央ディレクトリ/ローカル ヘッダーに示されている圧縮されていないファイル サイズを超えている場合も同様です。

.NET Core 3.0 以降では、ZipArchiveEntry.Open() メソッドによって、エントリの圧縮されたサイズと圧縮されていないサイズがローカル ヘッダーと中央ヘッダーで一致することが確認されます。 そうでない場合、アーカイブのローカル ヘッダーやデータ記述子に zip ファイルの中央ディレクトリと一致しないサイズが一覧表示されている場合、メソッドによって InvalidDataException がスローされます。 エントリを読み取るときに、圧縮解除されたデータは、ヘッダーに一覧表示されている圧縮されていないファイル サイズにまで切り詰められます。

この変更は、ZipArchiveEntry がそのデータのサイズを正しく表し、そのデータ量だけが読み取られるようにするために行われました。

導入されたバージョン

3.0

この問題が発生している zip アーカイブをすべて再パッケージ化します。

カテゴリ

Core .NET ライブラリ

影響を受ける API

FieldInfo.SetValue で、静的な初期化専用フィールドに対する例外がスローされる

.NET Core 3.0 以降、System.Reflection.FieldInfo.SetValue を呼び出して静的な InitOnly フィールドに値を設定しようとすると、例外がスローされます。

変更の説明

.NET Framework と、3.0 より前のバージョンの .NET Core では、定数である静的フィールドの初期化 (C# では読み取り専用に) した後、System.Reflection.FieldInfo.SetValue を呼び出すことで値を設定できました。 ただし、この方法でこのようなフィールドを設定すると、ターゲット フレームワークと最適化の設定に基づく動作を予測できなくなります。

.NET Core 3.0 以降のバージョンでは、静的な InitOnly フィールドに対して SetValue を呼び出すと、System.FieldAccessException 例外がスローされます。

ヒント

InitOnly フィールドは、その宣言時またはそれを含んでいるクラスのコンストラクター内にのみ設定可能なフィールドです。 つまり、それは初期化された後は定数になります。

導入されたバージョン

3.0

静的コンストラクター内の静的な InitOnly フィールドを初期化します。 これは、動的な型と非動的な型の両方に適用されます。

または、フィールドから FieldAttributes.InitOnly 属性を削除した後、FieldInfo.SetValue を呼び出すこともできます。

カテゴリ

Core .NET ライブラリ

影響を受ける API

IEnumerable<T> を受け取る拡張メソッドに GroupCollection を渡すにはあいまいさが必要

GroupCollection で IEnumerable<T> を受け取る拡張メソッドを呼び出す場合は、キャストを使用して型を明確にする必要があります。

変更内容

.NET Core 3.0 以降では、System.Text.RegularExpressions.GroupCollection によって IEnumerable<KeyValuePair<String,Group>> が実装され、それによって他の型 (IEnumerable<Group> など) も加えて実装されます。 これは、IEnumerable<T> を受け取る拡張メソッドを呼び出す場合には、あいまいな結果となります。 たとえば、Enumerable.Count などの GroupCollection インスタンスでこのような拡張メソッドを呼び出すと、次のコンパイラ エラーが表示されます。

CS1061: 'GroupCollection' に 'Count' の定義が含まれておらず、型 'GroupCollection' の最初の引数を受け付ける拡張メソッド 'Count' が見つかりませんでした (using ディレクティブまたはアセンブリ参照が不足しています。)

以前のバージョンの .NET では、あいまいさはなく、コンパイラ エラーもありませんでした。

導入されたバージョン

3.0

変更理由

これは意図しない破壊的変更でした。 しばらくの間このようになっているため、元に戻す予定はありません。 また、このような変更自体が中断されます。

GroupCollection インスタンスの場合は、キャストで IEnumerable<T> を受け入れる拡張メソッドの呼び出しを明確にします。

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

カテゴリ

Core .NET ライブラリ

影響を受ける API

IEnumerable<T> を受け入れるすべての拡張メソッドが影響を受けます。 次に例を示します。

暗号

Linux のルート証明書に対して "BEGIN TRUSTED CERTIFICATE" 構文がサポートされなくなった

Linux およびその他の Unix 類似システム (macOS 以外) のルート証明書は、標準の BEGIN CERTIFICATE PEM ヘッダーと、OpenSSL 固有の BEGIN TRUSTED CERTIFICATE PEM ヘッダーの 2 つの形式で提示できます。 後者の構文では、.NET Core の System.Security.Cryptography.X509Certificates.X509Chain クラスとの互換性の問題の原因となる追加の構成が可能です。 BEGIN TRUSTED CERTIFICATE ルート証明書の内容は、.NET Core 3.0 以降のチェーン エンジンでは読み込まれなくなりました。

変更の説明

以前は、ルート信頼リストを設定するために、BEGIN CERTIFICATE と BEGIN TRUSTED CERTIFICATE 両方の構文が使用されていました。 BEGIN TRUSTED CERTIFICATE 構文を使用し、ファイルで追加のオプションを指定した場合、信頼チェーンが明示的に禁止されたことが、X509Chain によって報告される場合があります (X509ChainStatusFlags.ExplicitDistrust)。 ただし、その証明書が、それより前に読み込まれたファイルの BEGIN CERTIFICATE 構文でも指定されていた場合は、信頼チェーンは許可されました。

.NET Core 3.0 以降、BEGIN TRUSTED CERTIFICATE の内容は読み取られなくなりました。 証明書が標準の BEGIN CERTIFICATE 構文でも指定されていない場合、X509Chain ではルートが信頼されていないと報告されます (X509ChainStatusFlags.UntrustedRoot)。

導入されたバージョン

3.0

ほとんどのアプリケーションはこの変更の影響を受けませんが、アクセス許可の問題のために両方のルート証明書ソースを確認できないアプリケーションでは、アップグレード後に予期しない UntrustedRoot エラーが発生する可能性があります。

多くの Linux ディストリビューションでは、ルート証明書はファイルごとに 1 証明書のディレクトリと、1 ファイル連結の 2 つの場所に書き込まれます。 一部のディストリビューションでは、ファイルごとに 1 証明書のディレクトリには BEGIN TRUSTED CERTIFICATE 構文が使用され、ファイル連結には標準の BEGIN CERTIFICATE 構文が使用されています。 これらの場所の少なくとも 1 つにすべてのカスタム ルート証明書が BEGIN CERTIFICATE として追加されていること、およびアプリケーションで両方の場所を読み取ることができることを確認してください。

一般的なディレクトリは /etc/ssl/certs/ であり、一般的な連結されたファイルは /etc/ssl/cert.pem です。 プラットフォーム固有のルートを確認するには、openssl version -d コマンドを使用します。これは、 /etc/ssl/ と異なる場合があります。 たとえば、Ubuntu 18.04 では、ディレクトリは /usr/lib/ssl/certs/ であり、ファイルは /usr/lib/ssl/cert.pem です。 ただし、 /usr/lib/ssl/certs/ は /etc/ssl/certs/ へのシンボリック リンクであり、 /usr/lib/ssl/cert.pem は存在しません。

$ openssl version -d
OPENSSLDIR: "/usr/lib/ssl"
$ ls -al /usr/lib/ssl
total 12
drwxr-xr-x  3 root root 4096 Dec 12 17:10 .
drwxr-xr-x 73 root root 4096 Feb 20 15:18 ..
lrwxrwxrwx  1 root root   14 Mar 27  2018 certs -> /etc/ssl/certs
drwxr-xr-x  2 root root 4096 Dec 12 17:10 misc
lrwxrwxrwx  1 root root   20 Nov 12 16:58 openssl.cnf -> /etc/ssl/openssl.cnf
lrwxrwxrwx  1 root root   16 Mar 27  2018 private -> /etc/ssl/private

カテゴリ

暗号

影響を受ける API

EnvelopedCms が AES-256 暗号化を既定で使用

EnvelopedCms で使用される既定の対称暗号化アルゴリズムが TripleDES から AES-256 に変更されました。

変更の説明

以前のバージョンでは、コンストラクターのオーバーロードを使って対称暗号化アルゴリズムを指定せずに EnvelopedCms を使用してデータを暗号化する場合、データは TripleDES/3DES/3DEA/DES3-EDE アルゴリズムで暗号化されます。

.NET Core 3.0 以降では (System.Security.Cryptography.Pkcs NuGet パッケージのバージョン 4.6.0 を介して)、アルゴリズムを最新化し、既定のオプションのセキュリティを向上するために、既定のアルゴリズムが AES-256 に変更されました。 メッセージ受信者の証明書に Diffie-Hellman (非 EC) 公開キーが含まれている場合、基になるプラットフォームの制限のために、暗号化操作は、CryptographicException で失敗する可能性があります。

次のサンプル コードでは、.NET Core 2.2 以前で実行されている場合、データは TripleDES で暗号化されます。 NET Core 3.0 以降で実行されている場合は AES-256 で暗号化されます。

EnvelopedCms cms = new EnvelopedCms(content);
cms.Encrypt(recipient);
return cms.Encode();

導入されたバージョン

3.0

この変更によって悪影響を受ける場合は、型 AlgorithmIdentifier を含む EnvelopedCms コンストラクターで暗号化アルゴリズム識別子を明示的に指定することで、TripleDES 暗号化に戻すことができます。次に例を示します。

Oid tripleDesOid = new Oid("1.2.840.113549.3.7", null);
AlgorithmIdentifier tripleDesIdentifier = new AlgorithmIdentifier(tripleDesOid);
EnvelopedCms cms = new EnvelopedCms(content, tripleDesIdentifier);

cms.Encrypt(recipient);
return cms.Encode();

カテゴリ

暗号

影響を受ける API

RSAOpenSsl キー生成の最小サイズが増加しました

Linux で新しい RSA キーを生成する場合の最小サイズが、384 ビットから 512 ビットに増加しました。

変更の説明

.NET Core 3.0 以降では、Linux で RSA.Create、RSAOpenSsl、および RSACryptoServiceProvider から RSA インスタンス上の LegalKeySizes プロパティによって報告される最小の有効キー サイズが 384 から 512 に増えました。

その結果、.NET Core 2.2 以前のバージョンでは、RSA.Create(384) などのメソッドの呼び出しが成功しています。 .NET Core 3.0 以降のバージョンでは、メソッドの呼び出し RSA.Create(384) によって、サイズが小さすぎることを示す例外がスローされます。

この変更は、Linux で暗号化操作を実行する OpenSSL によって、バージョン 1.0.2 と 1.1.0 の間で最小値が増加したためです。 .NET Core 3.0 では、OpenSSL 1.0.x よりも 1.1.x が優先され、報告される最小バージョンが引き上げられ、この新しい依存関係のより高い制限が反映されます。

導入されたバージョン

3.0

影響を受ける API を呼び出す場合は、生成されるキーのサイズがプロバイダーの最小を下回らないようにしてください。

注意

384 ビットの RSA は、既に安全ではないと見なされています (512 ビットの RSA も同様)。 NIST Special Publication 800-57 Part 1 Revision 4 などの最新の推奨設定では、新しく生成されるキーの最小サイズとして 2,048 ビットが提案されています。

カテゴリ

暗号

影響を受ける API

.NET Core 3.0 では、OpenSSL 1.0.x よりも OpenSSL 1.1.x が優先されます

Linux 用 .NET Core では、複数の Linux ディストリビューションで動作するため、OpenSSL 1.0.x と OpenSSL 1.1.x の両方がサポートされます。 .NET Core 2.1 および .NET Core 2.2 では、最初に 1.0.x が検索されてから、1.1.x にフォールバックされます。 .NET Core 3.0 では、最初に 1.1.x が検索されます。 この変更は、新しい暗号化標準のサポートを追加するために行われました。

この変更は、.NET Core で OpenSSL 固有の相互運用型とのプラットフォーム相互運用を行うライブラリまたはアプリケーションに影響を与える可能性があります。

変更の説明

.NET Core 2.2 以前のバージョンで、ランタイムでは OpenSSL 1.1.x よりも 1.0.x の読み込みが優先されます。 これは、OpenSSL との相互運用に使用する IntPtr と SafeHandle の型が優先設定に応じて libcrypto.so.1.0.0/libcrypto.so.1.0/libcrypto.so.10 のいずれかで使用されることを意味します。

.NET Core 3.0 以降で、ランタイムでは OpenSSL 1.0.x よりも OpenSSL 1.1.x の読み込みが優先されるため、OpenSSL との相互運用に使用する IntPtr と SafeHandle の型は優先設定に応じて libcrypto.so.1.1/libcrypto.so.11/libcrypto.so.1.1.0/libcrypto.so.1.1.1 のいずれかで使用されます。 その結果、OpenSSL と直接相互運用できるライブラリとアプリケーションは、.NET Core 2.1 または .NET Core 2.2 からアップグレードするときに、.NET Core で公開されている値と互換性のないポインターを持つ場合があります。

導入されたバージョン

3.0

OpenSSL を直接操作するライブラリやアプリケーションは、.NET Core ランタイムと同じバージョンの OpenSSL を使用するように注意する必要があります。

OpenSSL を直接使用する .NET Core 暗号化の種類から IntPtr または SafeHandle の値を使用するすべてのライブラリやアプリケーションでは、新しい SafeEvpPKeyHandle.OpenSslVersion プロパティで使用するライブラリのバージョンを比較し、ポインターの互換性を確保する必要があります。

カテゴリ

暗号

影響を受ける API

CryptoStream.Dispose は書き込み時にのみ最後のブロックを変換する

CryptoStream 操作を完了するために使用される CryptoStream.Dispose メソッドは、読み取り時に最後のブロックの変換を試行しなくなりました。

変更内容

以前のバージョンの .NET では、ユーザーが Read モードで CryptoStream を使用するときに不完全な読み取りを実行した場合、Dispose メソッドから例外がスローされる可能性がありました (たとえば、パディングで AES を使用する場合)。 例外がスローされた理由は、最後のブロックの変換が試みられたがデータが不完全だったことにありました。

.NET Core 3.0 以降のバージョンでは、Dispose が読み取り時に最後のブロックの変換を試行しなくなりました。これにより、不完全な読み取りが許容されます。

変更理由

この変更により、ネットワーク操作がキャンセルされたときに、例外をキャッチする必要なしに、暗号化ストリームからの不完全な読み取りが可能になります。

導入されたバージョン

3.0

ほとんどのアプリは、この変更の影響を受けることはありません。

不完全な読み取りが発生した場合にアプリケーションが例外をキャッチしても、その catch ブロックを削除できます。 ご利用のアプリがハッシュ シナリオで最後のブロックの変換を使用した場合、ストリーム全体が破棄される前にそれを確実に読み取るようにする必要がある可能性があります。

カテゴリ

暗号

影響を受ける API

Entity Framework Core

Entity Framework Core の破壊的変更

グローバリゼーション

"C" ロケールは、インバリアント ロケールにマップされます

.NET Core 2.2 以前のバージョンでは、"C" ロケールを en_US_POSIX ロケールにマップする既定の ICU 動作に依存しています。 en_US_POSIX ロケールでは、大文字と小文字を区別しない文字列比較がサポートされていないため、望ましくない照合順序の動作があります。 一部の Linux ディストリビューションでは、"C" ロケールが既定のロケールとして設定されているため、ユーザーが予期しない動作が発生していました。

変更の説明

.NET Core 3.0 以降では、"C" ロケール マッピングが en_US_POSIX ではなくインバリアント ロケールを使用するように変更されました。 一貫性を確保するため、インバリアントへの "C" ロケールのマッピングは、Windows にも適用されます。

en_US_POSIX では大文字と小文字を区別しない並べ替え/検索文字列操作がサポートされないため、"C" を en_US_POSIX カルチャにマッピングすると、お客様の混乱を招いていました。 "C" ロケールは一部の Linux ディストリビューションでは既定のロケールとして使用されているため、これらのオペレーティング システムでお客様にこのような望ましくない動作が発生していました。

導入されたバージョン

3.0

この変更を認識する以外には特にありません。 この変更は、"C" ロケール マッピングを使用するアプリケーションにのみ影響します。

カテゴリ

グローバリゼーション

影響を受ける API

すべての照合順序 API とカルチャ API は、この変更の影響を受けます。

MSBuild

リソース マニフェストのファイル名の変更

.NET Core 3.0 以降では、既定の場合、MSBuild によってリソース ファイルに対して異なるマニフェスト ファイル名が生成されます。

導入されたバージョン

3.0

変更の説明

.NET Core 3.0 より前では、プロジェクト ファイルの EmbeddedResource 項目に LogicalName、ManifestResourceName、または DependentUpon メタデータが指定されなかった場合、MSBuild ではパターン <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources でマニフェスト ファイル名が生成されていました。 RootNamespace がプロジェクト ファイルで定義されていない場合は、既定でそのプロジェクトの名前になります。 たとえば、ルート プロジェクト ディレクトリ内の Form1 という名前のリソース ファイルに対して生成されたマニフェスト名は、MyProject.Form1.resources でした。

.NET Core 3.0 以降では、あるリソース ファイルが同じ名前のソース ファイルと併置されている場合 (たとえば、Form1.resx と Form1.cs)、MSBuild ではそのソース ファイルの型情報が使用されてパターン <Namespace>.<ClassName>.resources でマニフェスト ファイル名が生成されます。 名前空間とクラス名は、併置されたソース ファイルの最初の型から抽出されます。 たとえば、Form1.cs という名前のソース ファイルと併置されている Form1 という名前のリソース ファイルに対して生成されたマニフェスト名は、MyNamespace.Form1.resources になります。 重要な注意点として、.NET Core の以前のバージョンとはファイル名の最初の部分が異なります (MyProject ではなく MyNamespace)。

注意

プロジェクト ファイルの EmbeddedResource 項目で LogicalName、ManifestResourceName、または DependentUpon メタデータが指定されている場合、この変更はそのリソース ファイルには影響しません。

この破壊的変更は、.NET Core プロジェクトへの EmbeddedResourceUseDependentUponConvention プロパティの追加によって導入されました。 既定では、リソース ファイルは .NET Core プロジェクト ファイルに明示的にリストされていないため、生成された .resources ファイルに名前を付ける方法を指定するための DependentUpon メタデータはありません。 EmbeddedResourceUseDependentUponConvention が true に設定されている場合 (既定)、MSBuild では併置されたソース ファイルが検索され、そのファイルから名前空間とクラス名が抽出されます。 EmbeddedResourceUseDependentUponConvention を false に設定すると、MSBuild では RootNamespace と相対ファイル パスを組み合わせた前の動作に従ってマニフェスト名が生成されます。

ほとんどの場合、開発者側でアクションを取る必要はなく、アプリは引き続き動作するはずです。 ただし、この変更によってアプリに影響が出ている場合は、次のいずれかを実行してください。

  • 新しいマニフェスト名を要求するようにコードを変更する。

  • プロジェクト ファイルで EmbeddedResourceUseDependentUponConvention を false に設定して、新しい名前付け規則を無効にする。

    <PropertyGroup>
  <EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
</PropertyGroup>

カテゴリ

MSBuild

影響を受ける API

該当なし

ネットワーキング

HttpRequestMessage.Version の既定値が 1.1 に変更された

System.Net.Http.HttpRequestMessage.Version プロパティの既定値が 2.0 から 1.1 に変更されました。

導入されたバージョン

3.0

変更の説明

.NET Core 1.0 から 2.0 では、System.Net.Http.HttpRequestMessage.Version プロパティの既定値は 1.1 です。 .NET Core 2.1 以降では、2.1 に変更されました。

.NET Core 3.0 以降では、System.Net.Http.HttpRequestMessage.Version プロパティによって返される既定のバージョン番号は再び 1.1 になりました。

既定値 2.0 を返す System.Net.Http.HttpRequestMessage.Version プロパティに依存している場合は、コードを更新します。

カテゴリ

ネットワーキング

影響を受ける API

関連項目