トレーニング
モジュール
ASP.NET Core Identity フレームワークを使用して .NET Web アプリをセキュリティで保護する - Training
ASP.NET Core Identity フレームワークを使用して、.NET Web アプリに認証と認可を追加する方法について説明します。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
.NET Core、ASP.NET Core、または EF Core のバージョン 3.0 に移行する場合、この記事の一覧にある破壊的変更がお使いのアプリに影響する可能性があります。
ASP.NET Core 2.2 の古いメンバーと互換性スイッチが削除されました。
3.0
時間経過による API サーフェイスの向上。
.NET Core 2.2 がターゲットの間は、古いビルド メッセージのガイダンスに従って新しい API を採用します。
ASP.NET Core
以下の型とメンバーは、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.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.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.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
メソッド
Microsoft.AspNetCore.Mvc.LocalRedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToActionResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToPageResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToRouteResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor)
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 のガイダンスでは以下が示されていました。
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
名前空間名に 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 では、早ければ 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 の外部での変更です。
Microsoft.Owin
3.1.0 以降については、一時的な軽減策の概要がこちらにあります。 アプリでは、データ形式の変更を確認するために、軽減策を使用してテストを完了する必要があります。 Microsoft.Owin
4.0.1 と修正プログラムをリリースする計画があります。 以前のバージョンを使用しているアプリは、バージョン 4.0.1 に更新する必要があります。
ASP.NET Web Forms および MVC での Owin の軽減策は、ASP.NET Core 1.x に適応できます。 1.x は有効期間の終了状態に達したため、NuGet パッケージの修正プログラムは計画されていません。
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 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
Microsoft.AspNetCore.Authentication.Google
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
ASP.NET Core 3.0 では、Authentication API で使用される Newtonsoft.Json
型が System.Text.Json
型に置き換えられました。 次の場合を除き、Authentication パッケージの基本的な使用方法は影響を受けません。
詳細については、dotnet/aspnetcore#7105 を参照してください。 ディスカッションについては、dotnet/aspnetcore#7289 を参照してください。
3.0
派生 OAuth 実装の場合、最も一般的な変更は、こちらで示すように、CreateTicketAsync
オーバーライドで JObject.Parse
を JsonDocument.Parse
に置き換えることです。 JsonDocument
は、IDisposable
を実装します。
既知の変更の概要を以下に示します。
ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string issuer)
になります。 ClaimAction
のすべての派生実装も同様に影響を受けます。MapCustomJson(this ClaimActionCollection collection, string claimType, Func<JsonElement, string> resolver)
になります。MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver)
になります。JObject
が JsonElement
に置き換えられました。 これに合わせて、User
プロパティと RunClaimActions
メソッドが更新されました。JObject
ではなく、JsonDocument
型のパラメーターを受け取るようになりました。 これに合わせて Response
プロパティが更新されました。 OAuthTokenResponse
が破棄可能になり、OAuthHandler
によって破棄されます。 ExchangeCodeAsync
をオーバーライドする派生 OAuth 実装では、JsonDocument
または OAuthTokenResponse
を破棄する必要はありません。JObject
から JsonDocument
に変更されました。JObject
から JsonElement
に変更されました。JObject
から JsonElement
に変更されました。 代わりのメソッドは、TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement) です。ASP.NET Core
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
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
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
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
なし
ASP.NET Core 3.0 では、IAuthorizationPolicyProvider
に新しい GetFallbackPolicyAsync
メソッドが追加されました。 このフォールバック ポリシーは、ポリシーが指定されていない場合に、承認ミドルウェアによって使用されます。
詳細については、dotnet/aspnetcore#9759 を参照してください。
3.0
IAuthorizationPolicyProvider
の実装には、GetFallbackPolicyAsync
メソッドは必要ありませんでした。
IAuthorizationPolicyProvider
の実装には、GetFallbackPolicyAsync
メソッドが必要です。
ポリシーが指定されていない場合に新しい AuthorizationMiddleware
を使用にするには、新しいメソッドが必要でした。
IAuthorizationPolicyProvider
の実装に GetFallbackPolicyAsync
メソッドを追加します。
ASP.NET Core
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
ASP.NET Core 3.0 のリリースでは、古い MemoryCacheOptions API が削除されました。
この変更は、aspnet/Caching#221 に対するフォローアップです。 ディスカッションについては、dotnet/extensions#1062 を参照してください。
3.0
MemoryCacheOptions.CompactOnMemoryPressure
プロパティを使用できました。
MemoryCacheOptions.CompactOnMemoryPressure
プロパティは削除されました。
キャッシュを自動的に圧縮すると、問題が発生しました。 予期しない動作を避けるため、キャッシュは必要なときにのみ圧縮する必要があります。
キャッシュを圧縮するには、MemoryCache
にダウンキャストし、必要に応じて Compact
を呼び出します。
ASP.NET Core
MemoryCacheOptions.CompactOnMemoryPressure
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
なし
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
Microsoft.AspNetCore.ResponseCaching.Internal.CachedResponse
Microsoft.AspNetCore.ResponseCaching.Internal.CachedVaryByRules
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCacheEntry
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingPolicyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.MemoryResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingContext
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingPolicyProvider
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
なし
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 の使用が明示的に選択されている。<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
が設定されている。ASP.NET Core
なし
汎用ホストが Startup
クラスのコンストラクター挿入でサポートする型は、IHostEnvironment
、IWebHostEnvironment
、IConfiguration
だけです。 WebHost
を使用しているアプリは影響を受けません。
ASP.NET Core 3.0 より前では、コンストラクター挿入は Startup
クラスのコンストラクターの任意の型に使用できました。 ASP.NET Core 3.0 では、Web スタックが汎用ホスト ライブラリに再プラットフォーム化されました。 この変更は、テンプレートの Program.cs ファイルで確認できます。
ASP.NET Core 2.x:
ASP.NET Core 3.0:
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
なし
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
HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)
既存の 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
の両方の名前空間が含まれるようになります。 これらの重複する型を使用すると、両方の名前空間が参照されるときに "あいまいな参照" コンパイラ エラーが発生します。
次のように、古い型の使用を新しく導入された型に置き換えます。
古い型 (警告):
新しい型:
Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
新しい IHostEnvironment
、IsDevelopment
および IsProduction
拡張メソッドは、Microsoft.Extensions.Hosting
名前空間にあります。 その名前空間は、プロジェクトに追加する必要がある場合があります。
ASP.NET Core
ASP.NET Core の定額課金を増やすために、ObjectPoolProvider
が主な依存関係のセットから削除されました。 ObjectPoolProvider
に依存する特定のコンポーネント自体で、それが追加されるようになりました。
ディスカッションについては、dotnet/aspnetcore#5944 を参照してください。
3.0
WebHostBuilder
によって、DI コンテナーに既定で ObjectPoolProvider
が提供されます。
WebHostBuilder
によって、DI コンテナーに既定で ObjectPoolProvider
が提供されなくなりました。
この変更は、ASP.NET Core の定額課金を増やすために行われました。
コンポーネントに ObjectPoolProvider
が必要な場合は、IServiceCollection
を介して依存関係に追加する必要があります。
ASP.NET Core
なし
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
Microsoft.AspNetCore.Http.DefaultHttpContext
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
Microsoft.Net.Http.Headers.HeaderNames
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
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
ASP.NET Core 3.0 以降では、同期サーバー操作は既定で無効になっています。
AllowSynchronousIO
は、HttpRequest.Body.Read
、HttpResponse.Body.Write
、Stream.Flush
などの同期 IO API を有効または無効にする各サーバーのオプションです。 これらの API は長い間、スレッドの枯渇とアプリのハングの原因になっていました。 ASP.NET Core 3.0 Preview 3 以降では、これらの同期操作は既定で無効になっています。
影響を受けるサーバー:
次のようなエラーが発生する可能性があります。
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
ASP.NET Core 3.0 以降では、IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) メソッド オーバーロードはなくなりました。
3.0
この変更は、静的 Web アセット機能が導入された結果でした。
2 つの引数を取るオーバーロードの代わりに IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) を呼び出します。 ブートストラップ 3 を使用している場合、プロジェクト ファイルの <PropertyGroup>
要素に次の行も追加します。
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
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
なし
既定では、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
なし
ASP.NET Core 3.0 以降、SignInManager
コンストラクターに新しい IUserConfirmation<TUser>
パラメーターが追加されました。 詳細については、dotnet/aspnetcore#8356 を参照してください。
3.0
変更の動機は、ID での新しいメール/確認フローのサポートを追加するためでした。
手動で SignInManager
を構築している場合は、IUserConfirmation
の実装を提供するか、依存関係の挿入から 1 つを取得して提供します。
ASP.NET Core
ASP.NET Core 3.0 では静的な Web 資産機能が導入され、ID UI でこれが導入されました。
ID UI で静的な Web 資産機能が導入された結果として、次のようになります。
IdentityUIFrameworkVersion
プロパティを使用して行います。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
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
"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
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter
アセンブリ 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 アプリに読み込んだときに破損する可能性があります。Microsoft.AspNetCore.Server.Kestrel.Https
NuGet パッケージへの直接参照をすべて削除する必要があります。ASP.NET Core
なし
以前のバージョンでは、要求本文が最後まで読み取られると、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
"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
なし
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
Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture
DebugLogger
のアクセス修飾子は、ASP.NET Core 3.0 より前では public
でした。 このアクセス修飾子は、ASP.NET Core 3.0 では、internal
に変わっています。
3.0
次の理由により変更されています。
ConsoleLogger
などの、その他のロガーの実装との整合性を確保します。AddDebug ILoggingBuilder
拡張メソッドを使用して、デバッグ ログを有効にします。 サービスを手動で登録する必要がある場合、DebugLoggerProvider もまだ public
です。
ASP.NET Core
Microsoft.Extensions.Logging.Debug.DebugLogger
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
なし
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
Microsoft.AspNetCore.Mvc.JsonResult
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
なし
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
この変更には、次の名前空間の型が含まれます。
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
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
Microsoft.AspNetCore.Mvc.WebApiCompatShim
RazorTemplateEngine
API が削除され、Microsoft.AspNetCore.Razor.Language.RazorProjectEngine
に置き換えられました。
ディスカッションについては、GitHub イシュー dotnet/aspnetcore#25215 を参照してください。
3.0
Razor ファイルのコードを解析し、生成するためにテンプレート エンジンを作成し、使用できます。
Razor ファイルのコードを解析し、生成するために、RazorProjectEngine
を作成し、RazorTemplateEngine
と同じ種類の情報を提供できます。 RazorProjectEngine
からは追加の構成レベルも与えられます。
RazorTemplateEngine
と既存の実装の結合密度が高すぎました。 Razor の解析および生成パイプラインを正しく構成しようとするとき、この密結合によって問題が増えました。
RazorTemplateEngine
ではなく 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
});
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
RazorTemplateEngine
RazorTemplateEngineOptions
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 ファイルの実行時コンパイルまたは再コンパイルを必要とするアプリでは、次の手順を実行する必要があります。
Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
パッケージへの参照を追加します。
プロジェクトの Startup.ConfigureServices
メソッドを更新して、AddRazorRuntimeCompilation
の呼び出しを含めます。 次に例を示します。
services.AddMvc()
.AddRazorRuntimeCompilation();
ASP.NET Core
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
セッション 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
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
に次のサブコンポーネントが含まれていました。
Newtonsoft.Json
)Microsoft.EntityFrameworkCore.
がプレフィックスとして付加されたアセンブリ)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
を介して参照されるすべてのバイナリに適用されるわけではありません。 重要な例外は次のとおりです。
Microsoft.Extensions
ライブラリは、NuGet パッケージとして利用できます (https://github.com/dotnet/extensions を参照してください)。Microsoft.AspNetCore.App
に含まれていない API。 たとえば、次のコンポーネントは NuGet パッケージとして利用できます。詳細については、「Stop producing packages for shared framework assemblies in 3.0 (3.0 における共有フレームワークのアセンブリのパッケージ生成の停止)」をご覧ください。 ディスカッションについては、dotnet/aspnetcore#3757 を参照してください。
ASP.NET Core
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
なし
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
HandshakeProtocol.SuccessHandshakeData
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
オプションの追加を将来においても利用できるように、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
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
なし
メソッド 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
以下の 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 固有のコンポーネントは不適切であり、推奨されないことを明確にするために、次のようにしました。
これらのパッケージを使用している場合は、次の機能を使用するようにアプリを更新してください。
Microsoft.AspNetCore.SpaServices.Extensions
パッケージ内のもの。サーバー側プリレンダリングやホット モジュール リロードなどの機能を有効にするには、対応する SPA フレームワークのドキュメントを参照してください。 Microsoft.AspNetCore.SpaServices.Extensions
の機能は古くなって "おらず"、引き続きサポートされます。
ASP.NET Core
Microsoft.AspNetCore.NodeServices.HostingModels.INodeInstance
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationException
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationInfo
Microsoft.AspNetCore.NodeServices.HostingModels.NodeServicesOptionsExtensions
Microsoft.AspNetCore.NodeServices.HostingModels.OutOfProcessNodeInstance
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerenderer
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerendererBuilder
Microsoft.AspNetCore.SpaServices.Prerendering.JavaScriptModuleExport
Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper
Microsoft.AspNetCore.SpaServices.Prerendering.RenderToStringResult
Microsoft.AspNetCore.SpaServices.Webpack.WebpackDevMiddlewareOptions
Microsoft.Extensions.DependencyInjection.NodeServicesServiceCollectionExtensions
Microsoft.Extensions.DependencyInjection.PrerenderingServiceCollectionExtensions
ログ記録が構成されていない限り、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
なし
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
なし
.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 ライブラリ
カスタム 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 つの条件がすべて満たされている場合にのみ行われます。
3.0
ほとんどの開発者は、何も措置を講じる必要はありません。
アプリケーションでカスタム EncoderFallback および EncoderFallbackBuffer クラスを使用している場合、Fallback メソッドがランタイムによって最初に呼び出されたときに、EncoderFallbackBuffer.Fallback を実装することで、ターゲットのエンコードに直接変換できる正しい形式の UTF-16 で、データがフォールバック バッファーに入力されるようにします。
Core .NET ライブラリ
(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 ライブラリ
浮動小数点の解析メソッドが、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 ライブラリ
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 ライブラリ
なし。
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 ライブラリ
TypeDescriptionProviderAttribute クラスは移動されました。
.NET Core 2.2 およびそれ以前のバージョンでは、TypeDescriptionProviderAttribute クラスは System.ComponentModel.TypeConverter アセンブリにあります。
.NET Core 3.0 以降では、System.ObjectModel アセンブリに含まれています。
3.0
この変更によって影響を受けるのは、リフレクションを使用し、Assembly.GetType などのメソッドや、型が特定のアセンブリにあることを想定している Activator.CreateInstance のオーバーロードを呼び出すことによって、TypeDescriptionProviderAttribute 型を読み込んでいるアプリケーションのみです。 これに該当する場合は、メソッドの呼び出しで参照されているアセンブリを、型の新しいアセンブリの場所を反映するように更新する必要があります。
Windows フォーム
なし。
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 ライブラリ
.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 ライブラリ
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 ライブラリ
IEnumerable<T> を受け入れるすべての拡張メソッドが影響を受けます。 次に例を示します。
System.Linq.Enumerable
メソッドの大部分 (System.Linq.Enumerable.Count など)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
暗号
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();
暗号
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 ビットが提案されています。
暗号
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 プロパティで使用するライブラリのバージョンを比較し、ポインターの互換性を確保する必要があります。
暗号
CryptoStream
操作を完了するために使用される CryptoStream.Dispose メソッドは、読み取り時に最後のブロックの変換を試行しなくなりました。
以前のバージョンの .NET では、ユーザーが Read モードで CryptoStream を使用するときに不完全な読み取りを実行した場合、Dispose メソッドから例外がスローされる可能性がありました (たとえば、パディングで AES を使用する場合)。 例外がスローされた理由は、最後のブロックの変換が試みられたがデータが不完全だったことにありました。
.NET Core 3.0 以降のバージョンでは、Dispose が読み取り時に最後のブロックの変換を試行しなくなりました。これにより、不完全な読み取りが許容されます。
この変更により、ネットワーク操作がキャンセルされたときに、例外をキャッチする必要なしに、暗号化ストリームからの不完全な読み取りが可能になります。
3.0
ほとんどのアプリは、この変更の影響を受けることはありません。
不完全な読み取りが発生した場合にアプリケーションが例外をキャッチしても、その catch
ブロックを削除できます。
ご利用のアプリがハッシュ シナリオで最後のブロックの変換を使用した場合、ストリーム全体が破棄される前にそれを確実に読み取るようにする必要がある可能性があります。
暗号
.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 は、この変更の影響を受けます。
.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
該当なし
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 プロパティに依存している場合は、コードを更新します。
ネットワーキング
.NET Core 3.0 では、テキスト を別のコントロールにドラッグするときにテキスト エディター コントロールが System.Windows.DataObject を作成する方法が変更されました。 変更によって自動変換が無効になり、データがDataFormats.StringFormatに変換される代わりに、データがDataFormats.TextまたはDataFormats.UnicodeTextとして保持されます。
.NET Core 3.0
Windows Presentation Foundation
テキスト エディター コントロールからテキストをドラッグするときの System.Windows.DataObject のデータ型が DataFormats.StringFormatされました。
テキスト エディター コントロールからテキストをドラッグするときの System.Windows.DataObject のデータ型は、 DataFormats.Text または DataFormats.UnicodeText。
この変更は、動作変更です。
変更が意図せず行われました。
この変更は .NET 7 で回避されました。 .NET 7 以降にアップグレードします。
.NET に関するフィードバック
.NET はオープンソース プロジェクトです。 フィードバックを提供するにはリンクを選択します。
トレーニング
モジュール
ASP.NET Core Identity フレームワークを使用して .NET Web アプリをセキュリティで保護する - Training
ASP.NET Core Identity フレームワークを使用して、.NET Web アプリに認証と認可を追加する方法について説明します。