相关文章推荐
果断的冲锋衣  ·  url传数组参数并js获取-掘金·  1 年前    · 
有胆有识的红豆  ·  新功能发布 | ...·  1 年前    · 
大鼻子的鸵鸟  ·  常见前端面试题及答案 - 默语 - 博客园·  1 年前    · 
Code  ›  Core 3.0 中的 .NET 中断性变更 - .NET | Microsoft Learn
string core api接口 默认构造函数
https://learn.microsoft.com/zh-cn/dotnet/core/compatibility/3.0
冷冷的警车
1 年前
  • 身份验证：已删除 HttpContext.Authentication 属性
  • 身份验证：已替换 Newtonsoft.json 类型
  • 身份验证：已更改 OAuthHandler ExchangeCodeAsync 签名
  • 授权：AddAuthorization 重载已移到不同的程序集
  • 授权：已从 AuthorizationFilterContext.Filters 中删除 IAllowAnonymous
  • 授权：IAuthorizationPolicyProvider 实现需要新方法
  • 缓存：已删除 CompactOnMemoryPressure 属性
  • 缓存：Microsoft.Extensions.Caching.SqlServer 使用新的 SqlClient 包
  • 缓存：ResponseCaching“Pubternal”类型已更改为内部类型
  • 数据保护：DataProtection.Blobs 使用新的 Azure 存储 API
  • 托管：已从 Windows 托管捆绑包中删除 AspNetCoreModule V1
  • 托管：通用主机限制 Startup 构造函数注入
  • 托管：已为 IIS 进程外应用启用 HTTPS 重定向
  • 托管：已替换 IHostingEnvironment 和 IApplicationLifetime 类型
  • 托管：已从 WebHostBuilder 依赖项中删除 ObjectPoolProvider
  • HTTP：已删除 DefaultHttpContext 扩展性
  • HTTP：HeaderNames 字段已更改为静态只读
  • HTTP：响应正文基础结构更改
  • HTTP：已更改某些 Cookie SameSite 默认值
  • HTTP：已默认禁用同步 IO
  • 标识：已删除 AddDefaultUI 方法重载
  • 标识：UI 启动版本更改
  • 标识：对于未经身份验证的标识，SignInAsync 会引发异常
  • 标识：SignInManager 构造函数接受新参数
  • 标识：UI 使用静态 Web 资产功能
  • Kestrel：已删除连接适配器
  • Kestrel：已删除空 HTTPS 程序集
  • Kestrel：请求尾部标头已移到新集合
  • Kestrel：传输抽象层更改
  • 本地化：API 已标记为已过时
  • 日志记录：已将 DebugLogger 类设为内部类
  • MVC：已删除控制器操作 Async 后缀
  • MVC：JsonResult 已移至 Microsoft.AspNetCore.Mvc.Core
  • MVC：已弃用预编译工具
  • MVC：类型已更改为内部
  • MVC：已删除 Web API 兼容性填充码
  • Razor：已删除 RazorTemplateEngine API
  • Razor：运行时编译已移到包
  • 会话状态：已删除过时的 API
  • 共享框架：已从 Microsoft.AspNetCore.App 中删除程序集
  • 共享框架：已删除 Microsoft.AspNetCore.All
  • SignalR：已替换 HandshakeProtocol.SuccessHandshakeData
  • SignalR：已删除 HubConnection 方法
  • SignalR：已更改 HubConnectionContext 构造函数
  • SignalR：JavaScript 客户端包名称更改
  • SignalR：过时的 API
  • SPA：SpaServices 和 NodeServices 已标记为过时
  • SPA：SpaServices 和 NodeServices 控制台记录器回退默认更改
  • 目标框架： .NET 不支持框架

    • 已删除过时防伪、CORS、诊断、MVC 和路由 API

    删除了 ASP.NET Core 2.2 中过时的成员和兼容性开关。

    引入的版本

    随着时间的推移，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
  • 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)
  • Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor,Object)

    • 已删除“Pubternal”API

    为了更好地维护 ASP.NET Core 的公共 API 图面，命名空间中 (称为 "pubternal" API 的大多数类型 *.Internal ) 已真正成为内部类型。 这些命名空间中的成员永远不会作为面向公众的 API 得到支持。 API 可能在次要版本中中断（这种情况经常会发生）。 更新到 ASP.NET Core 3.0 时，依赖于这些 API 的代码会中断。

    有关详细信息，请参阅 dotnet/aspnetcore#4932 和 dotnet/aspnetcore#11312 。

    引入的版本

    受影响的 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 + 登录。
    

    ASP.NET 4.x 和 ASP.NET Core 一直在使用 Google+ 登录 API 在 Web 应用中对 Google 帐户用户进行身份验证。 受影响的 NuGet 包是 Microsoft.AspNetCore.Authentication.Google for ASP.NET Core 和 Microsoft.Owin.Security.Google for Microsoft.Owin 以及 ASP.NET Web Forms 和 MVC。
    

    Google 的替代 API 使用不同的数据源和格式。 下面提供的缓解措施和解决方案说明存在结构性更改。 应用应验证数据本身是否仍然满足其需求。 例如，名称、电子邮件地址、配置文件链接和个人资料照片的值可能与以前稍有不同。
    

    引入的版本
    

    所有版本。 此更改在 ASP.NET Core 外部。
    


    将 Owin 与 ASP.NET Web Forms 和 MVC 配合使用
    

    针对 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。 未计划 NuGet 包修补程序，因为 1.x 已处于生命周期结束状态。
    

    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。 在提交 dotnet/aspnetcore@d7a7c65 中删除了与旧 ASP.NET Core 1.x 身份验证堆栈相关的剩余未使用的类/API。
    

    有关讨论，请参阅 dotnet/aspnetcore#6533。
    

    引入的版本
    

    ASP.NET Core 1.0 API 已替换为 中的 Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions扩展方法。
    


    请参阅迁移指南。
    

    ASP.NET Core
    

    受影响的 API
    

  • Microsoft.AspNetCore.Http.Authentication.AuthenticateInfo
    • 

  • Microsoft.AspNetCore.Http.Authentication.AuthenticationManager
    • 

  • Microsoft.AspNetCore.Http.Authentication.AuthenticationProperties
    • 

  • Microsoft.AspNetCore.Http.Features.Authentication.AuthenticateContext
    • 

  • Microsoft.AspNetCore.Http.Features.Authentication.ChallengeBehavior
    • 

  • Microsoft.AspNetCore.Http.Features.Authentication.ChallengeContext
    • 

  • Microsoft.AspNetCore.Http.Features.Authentication.DescribeSchemesContext
    • 

  • Microsoft.AspNetCore.Http.Features.Authentication.IAuthenticationHandler
    • 

  • Microsoft.AspNetCore.Http.Features.Authentication.IHttpAuthenticationFeature.Handler
    • 

  • Microsoft.AspNetCore.Http.Features.Authentication.SignInContext
    • 

  • Microsoft.AspNetCore.Http.Features.Authentication.SignOutContext
    • 

  • Microsoft.AspNetCore.Http.HttpContext.Authentication
    • 

    身份验证：Newtonsoft.json 类型已替换
    

    在 ASP.NET Core 3.0 中， Newtonsoft.Json 身份验证 API 中使用的类型已替换为 System.Text.Json 类型。 除以下情况外，身份验证包的基本使用不受影响：
    

  • 派生自 OAuth 提供程序的类，例如来自 aspnet-contrib 的类。
    • 

  • 高级声明操作实现。
    • 

    有关详细信息，请参阅 dotnet/aspnetcore#7105。 有关讨论，请参阅 dotnet/aspnetcore#7289。
    

    引入的版本
    

    对于派生的 OAuth 实现，最常见的更改是将 JObject.Parse 替换为 CreateTicketAsync 重写中的 JsonDocument.Parse，如本文所示。 JsonDocument 可实现 IDisposable。
    

    以下列表概述了已知更改：
    

  • ClaimAction.Run(JObject, ClaimsIdentity, String) 变为 ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string issuer)。 ClaimAction 的所有派生的实现都受到类似的影响。
    • 

  • ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, Func<JObject,String>) 变为 MapCustomJson(this ClaimActionCollection collection, string claimType, Func<JsonElement, string> resolver)
    • 

  • ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, String, Func<JObject,String>) 变为 MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver)
    • 

  • OAuthCreatingTicketContext 已移除一个旧构造函数，另一个将 JObject 替换为 JsonElement。 已更新 User 属性和 RunClaimActions 方法以使其匹配。
    • 

  • Success(JObject) 现在接受类型为 JsonDocument 而非 JObject 的参数。 已更新 Response 属性以使其匹配。 OAuthTokenResponse 现在可处置，并将由 OAuthHandler 处置。 替代 ExchangeCodeAsync 的派生的 OAuth 实现无需处置 JsonDocument 或 OAuthTokenResponse。
    • 

  • UserInformationReceivedContext.User 从 JObject 更改为 JsonDocument。
    • 

  • TwitterCreatingTicketContext.User 从 JObject 更改为 JsonElement。
    • 

  • TwitterHandler.CreateTicketAsync(ClaimsIdentity,AuthenticationProperties,AccessToken,JObject) 的最后一个参数从 JObject 更改为 JsonElement。 替换方法为 TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement)。
    • 

    ASP.NET Core
    

    受影响的 API
    

  • Microsoft.AspNetCore.Authentication.Facebook
    • 

  • Microsoft.AspNetCore.Authentication.Google
    • 

  • Microsoft.AspNetCore.Authentication.MicrosoftAccount
    • 

  • Microsoft.AspNetCore.Authentication.OAuth
    • 

  • Microsoft.AspNetCore.Authentication.OpenIdConnect
    • 

  • Microsoft.AspNetCore.Authentication.Twitter
    • 

    身份验证：已更改 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; }

    引入的版本
    

    code 和 redirectUri 字符串作为单独的参数传递。




    

    

    Code 和 RedirectUri 是 OAuthCodeExchangeContext 上的属性，可通过 OAuthCodeExchangeContext 构造函数进行设置。 新的 OAuthCodeExchangeContext 类型是传递到 OAuthHandler.ExchangeCodeAsync 的唯一参数。
    

    此更改允许以非中断方式提供其他参数。 无需创建新的 ExchangeCodeAsync 重载。
    


    使用适当的 code 和 redirectUri 值构造 OAuthCodeExchangeContext。 必须提供 AuthenticationProperties 实例。 此单个 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 中删除了程序集中所述。
    

    引入的版本
    

    Microsoft.AspNetCore.Authorization 中已存在 AddAuthorization 方法。
    

    Microsoft.AspNetCore.Authorization.Policy 中存在 AddAuthorization 方法。 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] 属性中的此类实现是在需要配置和依赖项注入时实现强类型的基于属性的授权的常见的支持方式。
    

    引入的版本
    

    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。
    

    引入的版本
    

    IAuthorizationPolicyProvider 的实现不需要 GetFallbackPolicyAsync 方法。
    

    IAuthorizationPolicyProvider 的实现需要 GetFallbackPolicyAsync 方法。
    

    如果未指定策略，则新 AuthorizationMiddleware 需要使用新方法。
    


    将 GetFallbackPolicyAsync 方法添加到 IAuthorizationPolicyProvider 的实现。
    

    ASP.NET Core
    

    受影响的 API
    

    Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
    

    缓存：已删除 CompactOnMemoryPressure 属性
    

    ASP.NET Core 3.0 版本删除了 过时的 MemoryCacheOptions API。
    

    此更改是对 aspnet/Caching#221 的后续补充。 有关讨论，请参阅 dotnet/extensions#1062。
    

    引入的版本
    

    MemoryCacheOptions.CompactOnMemoryPressure 属性可用。
    

    MemoryCacheOptions.CompactOnMemoryPressure 属性已被删除。
    

    自动压缩缓存会引起问题。 若要避免意外行为，只应在需要时压缩缓存。
    


    若要压缩缓存，请向下转换到 MemoryCache 并在需要时调用 Compact。
    

    ASP.NET Core
    

    受影响的 API
    

    MemoryCacheOptions.CompactOnMemoryPressure
    

    缓存：Microsoft.Extensions.Caching.SqlServer 使用新的 SqlClient 包
    

    Microsoft.Extensions.Caching.SqlServer 包将使用新的 Microsoft.Data.SqlClient 包，而不是 System.Data.SqlClient 包。 此更改可能会导致轻微的行为中断性变更。 有关详细信息，请参阅引入新的 Microsoft.Data.SqlClient。
    

    引入的版本
    

    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”类型已更改为内部类型
    

    在 ASP.NET Core 3.0 中，中的 ResponseCaching “pubternal”类型已更改为 internal。
    

    此外，IResponseCachingPolicyProvider 和 IResponseCachingKeyProvider 的默认实现不再作为 AddResponseCaching 方法的一部分添加到服务。
    

    在 ASP.NET Core 中，“pubternal”类型声明为 public ，但驻留在后缀为 .Internal的命名空间中。 尽管这些类型为 public，但它们没有支持策略，可能会发生中断性变更。 遗憾的是，经常会意外使用这些类型，导致对这些项目做出中断性变更，并使维护框架的能力受到限制。
    

    引入的版本
    

    这些类型公开可见，但不受支持。
    

    这些类型现在为 internal。
    

    internal 范围更好地反映了不受支持的策略。
    


    复制应用或库使用的类型。
    

    ASP.NET Core
    

    受影响的 API
    

  • 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
    • 

  • Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware.ResponseCachingMiddleware(RequestDelegate, IOptions<ResponseCachingOptions>, ILoggerFactory, IResponseCachingPolicyProvider, IResponseCache, IResponseCachingKeyProvider)
    • 

    数据保护：DataProtection.Blobs 使用新的 Azure 存储 API
    

    Azure.Extensions.AspNetCore.DataProtection.Blobs 取决于 Azure 存储库。 这些库已重命名其程序集、包和命名空间。 从 ASP.NET Core 3.0 开始， Azure.Extensions.AspNetCore.DataProtection.Blobs 使用新的 Azure.Storage.前缀 API 和包。
    

    有关 Azure 存储 API 的问题，请使用 https://github.com/Azure/azure-storage-net。 有关此问题的讨论，请参阅 dotnet/aspnetcore#19570。
    

    引入的版本
    

    该包引用了 WindowsAzure.Storage NuGet 包。
该包引用 Microsoft.Azure.Storage.Blob NuGet 包。
    

    该包引用 Azure.Storage.Blob NuGet 包。
    

    此更改允许 Azure.Extensions.AspNetCore.DataProtection.Blobs 迁移到建议的 Azure 存储包。
    

    如果仍需要将较旧的 Azure 存储 API 与 ASP.NET Core 3.0 配合使用，请将直接依赖项添加到 包 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。
    

    引入的版本
    

    ANCM V1 包含在 Windows 托管捆绑包中。
    

    ANCM V1 不包含在 Windows 托管捆绑包中。
    

    ANCM V2 与 ANCM OutOfProcess 向后兼容，建议与 ASP.NET Core 3.0 应用一起使用。
    


    将 ANCM V2 与 ASP.NET Core 3.0 应用配合使用。
    

    如果需要 ANCM V1，可以使用 ASP.NET Core 2.1 或 2.2 Windows 托管捆绑包安装它。
    

    此更改将破坏以下 ASP.NET Core 3.0 应用：
    

  • 已明确选择将 ANCM V1 与 <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName> 结合使用。
    • 

  • 具有 <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" /> 的自定义 web.config 文件。
    • 

    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 使用一个依赖关系注入 (DI) 容器生成应用。 WebHost 使用两个容器：一个用于主机，另一个用于应用。 因此，Startup 构造函数不再支持自定义服务注入。 只能注入 IHostEnvironment、IWebHostEnvironment 和 IConfiguration。 此更改可防止出现 DI 问题，例如重复创建单一实例服务。
    

    引入的版本
    

    此更改是将 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。
    

    引入的版本
    

    ASP.NET Core 2.1 项目模板首先引入了对 HTTPS 中间件方法（如 和 UseHsts）UseHttpsRedirection的支持。 启用 HTTPS 重定向需要添加配置，因为开发中的应用不使用默认端口 443。 仅当请求已使用 HTTPS 时，HTTP 严格传输安全 (HSTS) 才处于活动状态。 默认跳过 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 3.0.1 和 3.1.0 预览版 3 中修改了上述行为，以扭转 ASP.NET Core 2.x 中的行为更改。 这些更改仅影响 IIS 进程外应用。
    

    如上所述，安装 ASP.NET Core 3.0.0 也会在 ASP.NET Core 2.x 应用中激活UseHttpsRedirection中间件。 对 ASP.NET Core 3.0.1 和 3.1.0 预览版 3 中的 ANCM 进行了更改，以便安装它们不再对 ASP.NET Core 2.x 应用产生此影响。 ASPNETCORE_HTTPS_PORT在 ASP.NET Core 3.0.1 和 3.1.0 预览版 3 中，ANCM 填充的.NET环境变量已更改为 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 (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 预览版 3 ANCM 之前安装 ASP.NET Core 3.0.1 运行时。 这样做可确保 ASP UseHttpsRedirection Core 3.0 应用继续按预期.NET 运行。
    

    在 Azure 应用服务中，由于 ANCM 具有全局性，其部署时间与运行时不同。 部署 ASP.NET Core 3.0.1 和 3.1.0 后，ANCM 已通过这些更改部署到 Azure。
    

    ASP.NET Core
    

    受影响的 API
    

    HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)
    

    托管：IHostingEnvironment 和 IApplicationLifetime 类型已标记为过时并被替换
    

    引入了新类型以替换现有的 IHostingEnvironment 和 IApplicationLifetime 类型。
    

    引入的版本
    

    Microsoft.Extensions.Hosting 和 Microsoft.AspNetCore.Hosting 有两个不同的 IHostingEnvironment 和 IApplicationLifetime 类型。
    

    旧类型已标记为过时，并已替换为新类型。
    

    在 ASP.NET Core 2.1 中引入时Microsoft.Extensions.Hosting，某些类型（如 IHostingEnvironment 和IApplicationLifetime）是从 Microsoft.AspNetCore.Hosting复制的。 某些 ASP.NET Core 3.0 更改会导致应用同时 Microsoft.Extensions.Hosting 包含 和 Microsoft.AspNetCore.Hosting 命名空间。 如果同时引用了两个命名空间，则使用这些重复类型会导致“引用不明确”编译器错误。
    


    将旧类型的所有使用替换为新引入的类型，如下所示：
    

    过时类型（警告）：
    

  • Microsoft.Extensions.Hosting.IHostingEnvironment
    • 

  • Microsoft.AspNetCore.Hosting.IHostingEnvironment
    • 

  • Microsoft.Extensions.Hosting.IApplicationLifetime
    • 

  • Microsoft.AspNetCore.Hosting.IApplicationLifetime
    • 

  • Microsoft.Extensions.Hosting.EnvironmentName
    • 

  • Microsoft.AspNetCore.Hosting.EnvironmentName
    • 

  • Microsoft.Extensions.Hosting.IHostEnvironment
    • 

  • Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
    • 

  • Microsoft.Extensions.Hosting.IHostApplicationLifetime
    • 

  • Microsoft.Extensions.Hosting.Environments
    • 

    新的 IHostEnvironmentIsDevelopment 和 IsProduction 扩展方法在 Microsoft.Extensions.Hosting 命名空间中。 可能需要将该命名空间添加到项目中。
    

    ASP.NET Core
    

    受影响的 API
    

  • Microsoft.AspNetCore.Hosting.EnvironmentName
    • 

  • Microsoft.AspNetCore.Hosting.IApplicationLifetime
    • 

  • Microsoft.AspNetCore.Hosting.IHostingEnvironment
    • 

  • Microsoft.Extensions.Hosting.EnvironmentName
    • 

  • Microsoft.Extensions.Hosting.IApplicationLifetime
    • 

  • Microsoft.Extensions.Hosting.IHostingEnvironment
    • 

    托管：已从 WebHostBuilder 依赖项中删除 ObjectPoolProvider
    

    作为使 ASP.NET Core 更付费的一部分，ObjectPoolProvider已从main依赖项集中删除。 依赖于 ObjectPoolProvider 的特定组件现在会自行添加。
    

    有关讨论，请参阅 dotnet/aspnetcore#5944。
    

    引入的版本
    

    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。
    

    引入的版本
    

    类可从 DefaultHttpContext 派生。
    

    类不可从 DefaultHttpContext 派生。
    

    最初提供扩展性是为了允许 HttpContext 合并，但它引入了不必要的复杂性并妨碍了其他优化。
    


    如果在单元测试中使用 Mock<DefaultHttpContext>，请改为开始使用 Mock<HttpContext>。
    

    ASP.NET Core
    

    受影响的 API
    

    Microsoft.AspNetCore.Http.DefaultHttpContext
    

    HTTP：HeaderNames 常量已更改为静态只读
    

    从 ASP.NET Core 3.0 预览版 5 开始，中的 Microsoft.Net.Http.Headers.HeaderNames 字段从 const 更改为 static readonly。
    

    有关讨论，请参阅 dotnet/aspnetcore#9514。
    

    引入的版本
    

    这些字段以前是 const。
    

    这些字段现在是 static readonly。
    

  • 防止将值嵌入到程序集边界内，允许根据需要更正值。
    • 

  • 实现更快的引用同等性检查。
    • 


    针对 3.0 重新编译。 通过以下方式使用这些字段的源代码将无法再执行此项操作：
    

  • 作为特性参数
    • 

  • 作为 switch 语句中的 case
    • 

  • 定义其他 const 时
    • 

    若要解决中断性变更，请切换到使用自定义标头名称常量或字符串文本。
    

    ASP.NET Core
    

    受影响的 API
    

    Microsoft.Net.Http.Headers.HeaderNames
    

    HTTP：响应正文基础结构更改
    

    支持 HTTP 响应正文的基础结构已发生更改。 如果直接使用 HttpResponse，则不需要进行任何代码更改。 如果要包装或替换 HttpResponse.Body 或访问 HttpContext.Features，请进行进一步了解。
    

    引入的版本
    

    有三个 API 与 HTTP 响应正文关联：
    

  • IHttpResponseFeature.Body
    • 

  • IHttpSendFileFeature.SendFileAsync
    • 

  • IHttpBufferingFeature.DisableResponseBuffering
    • 

    如果替换 HttpResponse.Body，则它通过使用 StreamResponseBodyFeature 为所有预期的 API 提供默认实现，将整个 IHttpResponseBodyFeature 替换为给定流周围的包装器。 重新设置回原始流会还原此更改。
    

    动机是将响应正文 API 合并为单一新功能接口。
    


    使用之前在其中使用 IHttpResponseFeature.Body、IHttpSendFileFeature 或 IHttpBufferingFeature 的 IHttpResponseBodyFeature。
    

    ASP.NET Core
    

    受影响的 API
    

  • Microsoft.AspNetCore.Http.Features.IHttpBufferingFeature
    • 

  • Microsoft.AspNetCore.Http.Features.IHttpResponseFeature.Body
    • 

  • Microsoft.AspNetCore.Http.Features.IHttpSendFileFeature
    • 


    SameSite 是 cookie 的一个选项，可以帮助减轻某些跨站点请求伪造 (CSRF) 攻击。 最初引入此选项时，会跨各种 ASP.NET Core API 使用不一致的默认值。 不一致会导致结果混乱。 从 ASP.NET Core 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
    

  • IResponseCookies.Append(String, String, CookieOptions)
    • 

  • CookiePolicyOptions.MinimumSameSitePolicy
    • 

    HTTP：所有服务器均禁用同步 IO
    

    从 ASP.NET Core 3.0 开始，同步服务器操作默认处于禁用状态。
    

    AllowSynchronousIO 是每台服务器中包含的一个选项，用于启用或禁用同步 IO API，如 HttpRequest.Body.Read、HttpResponse.Body.Write 和 Stream.Flush。 这些 API 长期以来一直是线程不足和应用挂起的根源。 从 ASP.NET Core 3.0 预览版 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;

    如果调用 Dispose 中同步 API 的 TextWriter 或另一个流出现问题，请改为调用新的 DisposeAsync API。
    

    有关讨论，请参阅 dotnet/aspnetcore#7644。
    

    引入的版本
    

    默认情况下允许 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 预览版 3 开始，同步操作默认处于禁用状态。
    


    使用这些方法的异步版本。 作为一种临时缓解措施，还可以根据每个请求重写该行为。
    

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

    ASP.NET Core
    

    受影响的 API
    

  • Stream.Flush
    • 

  • Stream.Read
    • 

  • Stream.Write
    • 

    标识：已删除 AddDefaultUI 方法重载
    

    从 ASP.NET Core 3.0 开始， IdentityBuilderUIExtensions.AddDefaultUI (IdentityBuilder，UIFramework)  方法重载不再存在。
    

    引入的版本
    

    此更改是采用静态 Web 资产功能的结果。
    

    调用 IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) 而不是使用两个参数的重载。 如果使用的是 Bootstrap 3，还应将以下行添加到项目文件中的 <PropertyGroup> 元素：
    

    <IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

    ASP.NET Core
    

    受影响的 API
    

    IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
    

    标识：已更改 UI 的默认 Bootstrap 版本
    

    从 ASP.NET Core 3.0 开始，标识 UI 默认使用 Bootstrap 版本 4。
    

    引入的版本
    

    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 时间范围内发布的。
    


    如果使用默认标识用户界面并将其添加到 Startup.ConfigureServices 中，则会受到此更改的影响，如以下示例中所示：
    

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

    请执行以下一项操作：
    

  • 迁移应用，以使用其迁移指南来使用 Bootstrap 4。
    

  • 更新 Startup.ConfigureServices 以强制使用 Bootstrap 3。 例如：
    

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

    ASP.NET Core
    

    受影响的 API
    

    标识：对于未经身份验证的标识，SignInAsync 会引发异常
    

    默认情况下，SignInAsync 会为其中 IsAuthenticated 为 false 的主体/标识引发异常。
    

    引入的版本
    

    SignInAsync 接受任何主体/标识，包括其中 IsAuthenticated 为 false 的标识。
    

    默认情况下，SignInAsync 会为其中 IsAuthenticated 为 false 的主体/标识引发异常。 有一个新的标志可禁止显示此行为，但默认行为已更改。
    

    旧行为是有问题的，因为在默认情况下，[Authorize] / RequireAuthenticatedUser() 拒绝了这些主体。
    


    在 ASP.NET Core 3.0 预览版 6 中，默认有AuthenticationOptionstrue一个 RequireAuthenticatedSignIn 标志。 将此标志设置为 false 以还原旧行为。
    

    ASP.NET Core
    

    受影响的 API
    

    标识：SignInManager 构造函数接受新参数
    

    从 ASP.NET Core 3.0 开始，已向SignInManager构造函数添加了一个新IUserConfirmation<TUser>参数。 有关详细信息，请参阅 dotnet/aspnetcore#8356。
    

    引入的版本
    

    更改的动机是为了添加对标识中的新电子邮件/确认流的支持。
    


    如果手动构造 SignInManager，请提供 IUserConfirmation 的实现，或从依赖项注入获取一个实现来提供。
    

    ASP.NET Core
    

    受影响的 API
    

    SignInManager<TUser>
    

    标识：UI 使用静态 Web 资产功能
    

    ASP.NET Core 3.0 引入了静态 Web 资产功能，标识 UI 已采用此功能。
    

    由于标识 UI 采用静态 Web 资产功能，因此：
    

  • 可通过使用项目文件中的 IdentityUIFrameworkVersion 属性来完成框架选择。
    • 

  • Bootstrap 4 是标识 UI 的默认 UI 框架。 Bootstrap 3 的生命周期已经结束，应考虑迁移到受支持的版本。
    • 

    引入的版本
    

    标识 UI 的默认 UI 框架为 Bootstrap 3。 可使用 Startup.ConfigureServices 中 AddDefaultUI 方法调用的参数配置 UI 框架。




    

    

    标识 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 的移动的一部分，已从 Kestrel 中删除 IConnectionAdapter 的概念。 连接适配器将替换为连接中间件 (类似于 ASP.NET Core 管道中的 HTTP 中间件，但对于较低级别的连接) 。 HTTPS 和连接日志记录已从连接适配器转移到连接中间件。 这些扩展方法应能继续无缝运行，但实现详细信息发生了改变。
    

    有关详细信息，请参阅 dotnet/aspnetcore#11412。 有关讨论，请参阅 dotnet/aspnetcore#11475。
    

    引入的版本
    

    Kestrel 扩展性组件是使用 IConnectionAdapter 创建的。
    

    Kestrel 扩展性组件被创建为中间件。
    

    此更改旨在提供更灵活的扩展性体系结构。
    


    转换 IConnectionAdapter 的任何实现以使用新的中间件模式，如此处所示。
    

    ASP.NET Core
    

    受影响的 API
    

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

    Kestrel：已删除空 HTTPS 程序集
    

    已删除程序集 Microsoft.AspNetCore.Server.Kestrel.Https。
    

    引入的版本
    

    在 ASP.NET Core 2.1 中， 的内容 Microsoft.AspNetCore.Server.Kestrel.Https 已移动到 Microsoft.AspNetCore.Server.Kestrel.Core。 此更改是使用 [TypeForwardedTo] 属性以非中断方式进行的。
    


  • 引用 2.0 的 Microsoft.AspNetCore.Server.Kestrel.Https 库应将所有 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 尾部后，这些尾部即可用。 客户端将不会发生尾部，直到整个请求正文至少已由服务器缓冲。 可能需要读取请求正文，以释放缓冲区空间。 如果读取请求正文直到结尾，则尾部始终可用。 尾部标记正文的结尾。
    

    引入的版本
    

    请求尾部标头将添加到 HttpRequest.Headers 集合中。
    

    请求尾部标头在 HttpRequest.Headers 集合中不存在。 在 HttpRequest 上使用以下扩展方法来访问它们：
    

  • GetDeclaredTrailers() - 获取列出了正文后应具有的尾部的请求“尾部”标头。
    • 

  • SupportsTrailers() - 指示请求是否支持接收尾部标头。
    • 

  • CheckTrailersAvailable() - 确定请求是否支持尾部以及是否可读取。
    • 

  • GetTrailer(string trailerName) - 从响应获取请求的尾随标头。
    • 

    在 gRPC 等方案中，尾部是关键功能。 将尾部合并到请求标头会使用户感到困惑。
    


    在 HttpRequest 上使用尾部相关扩展方法访问尾部。
    

    ASP.NET Core
    

    受影响的 API
    

    HttpRequest.Headers
    

    Kestrel：已删除并公开传输抽象
    

    作为远离“pubternal”API 的一部分，Kestrel 传输层 API 被公开为 Microsoft.AspNetCore.Connections.Abstractions 库中的公共接口。
    

    引入的版本
    

  • Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions 库中提供传输相关的抽象。
    • 

  • ListenOptions.NoDelay 属性可用。
    • 

  • 在 Microsoft.AspNetCore.Connections.Abstractions 库中引入 IConnectionListener 接口以公开 ...Transport.Abstractions 库最常用的功能。
    • 

  • 现在提供传输选项 NoDelay（LibuvTransportOptions 和 SocketTransportOptions）。
    • 

  • SchedulingMode 不再可用。
    • 

    ASP.NET Core 3.0 已从“pubternal”API 迁移。
    


    ASP.NET Core
    

    受影响的 API
    

    本地化：ResourceManagerWithCultureStringLocalizer 和 WithCulture 被标记为过时
    

    ResourceManagerWithCultureStringLocalizer 类和 WithCulture 接口成员通常是造成本地化用户混淆的原因，尤其是在创建自己的 IStringLocalizer 实现时。 这些项给用户留下了 IStringLocalizer 实例“按语言、按资源”的印象。 实际上，实例应该仅“按资源”。 搜索的语言由 CultureInfo.CurrentUICulture 在执行时确定。 为了消除混淆的根源，API 在 ASP.NET Core 3.0 预览版 3 中标记为已过时。 将从未来版本中删除这些 API。
    

    有关上下文，请参阅 dotnet/aspnetcore#3324。 有关讨论，请参阅 dotnet/aspnetcore#7756。
    

    引入的版本
    

    方法未标记为 Obsolete。
    

    方法被标记为 Obsolete。
    

    API 表示一个不推荐使用的用例。 本地化设计存在混淆。
    

    建议改用 ResourceManagerStringLocalizer。 允许 CurrentCulture 设置区域性。 如果没有这个选项，请创建并使用 ResourceManagerWithCultureStringLocalizer 的副本。
    

    ASP.NET Core
    

    受影响的 API
    

  • ResourceManagerWithCultureStringLocalizer
    • 

  • ResourceManagerStringLocalizer.WithCulture
    • 

    日志记录：已将 DebugLogger 类设为内部类
    

    在 ASP.NET Core 3.0 之前， DebugLogger的访问修饰符为 public。 在 ASP.NET Core 3.0 中，访问修饰符更改为 internal。
    

    引入的版本
    

    正在进行更改以便：
    

  • 强制执行与其他记录器（如 ConsoleLogger）实现的一致性。
    • 

  • 减少 API 图面。
    • 


    使用 AddDebugILoggingBuilder 扩展方法来启用调试日志记录。 如果需要手动注册服务，DebugLoggerProvider 也仍为 public。
    

    ASP.NET Core
    

    受影响的 API
    

    Microsoft.Extensions.Logging.Debug.DebugLogger
    

    MVC：从控制器操作名称中删除了异步后缀
    

    作为寻址 dotnet/aspnetcore#4849 的一部分，ASP.NET Core MVC 默认从操作名称中剪裁后缀 Async 。 从 ASP.NET Core 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 预览版 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。
    

    ASP Core 组合.NET 的平台级更改，如 aspnet/Announcements#325 中所述。
    


    根据 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 在生成时验证 .cshtml 文件的正确性，同时缩短应用的启动时间。 默认情况下，Razor SDK 处于启用状态，并且不需要任何手势即可开始使用。
    

    在 ASP.NET Core 3.0 中.NET ，ASP Core 1.1 时代 MVC 预编译工具已删除。 早期的包版本将继续收到修补版本中的重要 Bug 和安全修补程序。
    

    引入的版本
    

    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 中使用对预编译的本机支持。 如果 Bug 或缺失的功能阻止迁移到 Razor SDK，请在 dotnet/aspnetcore 中提出问题。
    

    ASP.NET Core
    

    受影响的 API
    

    MVC：“Pubternal”类型已更改为内部类型
    

    在 ASP.NET Core 3.0 中，MVC 中的所有“pubternal”类型都已更新为 public 在受支持的命名空间中，或者 internal 根据需要。
    

    在 ASP.NET Core 中，“pubternal”类型声明为 public ，但驻留在后缀命名空间中 .Internal。 尽管这些类型为 public，但它们没有支持策略，并且可能会发生中断性变更。 遗憾的是，经常会意外使用这些类型，导致对这些项目做出中断性变更，并使维护框架的能力受到限制。
    

    引入的版本
    

    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 兼容性填充码
    

    从 ASP.NET Core 3.0 开始，包 Microsoft.AspNetCore.Mvc.WebApiCompatShim 不再可用。
    

    Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) 包提供 ASP.NET Core 与 ASP.NET 4.x Web API 2 的部分兼容性，以简化将现有 Web API 实现迁移到 ASP.NET Core 的流程。 但是，使用 WebApiCompatShim 的应用不会从最新 ASP.NET Core 版本中提供的 API 相关功能中受益。 此类功能包括改进的开放 API 规范生成、标准化错误处理和客户端代码生成。 为了更好地专注于 3.0 中的 API 工作，已删除 WebApiCompatShim。 使用 WebApiCompatShim 的现有应用应迁移到较新的 [ApiController] 模型。
    

    引入的版本
    

    Web API 兼容性填充码是一种迁移工具。 它限制用户访问 ASP.NET Core 中添加的新功能。
    


    删除此填充码的用法，并直接迁移到 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。
    

    引入的版本
    

    可创建模板引擎并将其用于分析和生成 Razor 文件的代码。
    

    可创建 RazorProjectEngine，使其提供与 RazorTemplateEngine 相同类型的信息，以分析和生成 Razor 文件的代码。 RazorProjectEngine 也可提供额外的配置级别。
    

    RazorTemplateEngine 与现有实现过于紧密耦合。 在尝试正确配置 Razor 分析/生成管道时，这种紧密耦合会导致更多问题。
    

    请使用 RazorProjectEngine，而不是 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

    生成 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 移动到单独的包中。
    

    引入的版本
    

    无需额外的包，即可使用运行时编译。
    

    此功能已移至 Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation 包中。
    

    以下 API 以前在 Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions 中提供，用于支持运行时编译。 现在可通过 Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions 获取 API。
    

  • RazorViewEngineOptions.FileProviders 现为 MvcRazorRuntimeCompilationOptions.FileProviders
    • 

  • RazorViewEngineOptions.AdditionalCompilationReferences 现为 MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths
    • 

    此外，已删除 Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange。 默认情况下，通过引用 Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation 包来启用对文件更改的重新编译。




    

    

    若要删除 Roslyn 上的 ASP.NET Core 共享框架依赖项，必须进行此更改。
    


    需要对 Razor 文件进行运行时编译或重新编译的应用应执行以下步骤：
    

  • 添加对 Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation 包的引用。
    

  • 更新项目的 Startup.ConfigureServices 方法以包含对 AddRazorRuntimeCompilation 的调用。 例如：
    

    services.AddMvc()
    .AddRazorRuntimeCompilation();

    ASP.NET Core
    

    受影响的 API
    

    Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
    

    会话状态：已删除过时的 API
    

    已删除用于配置会话 cookie 的过时 API。 有关详细信息，请参阅 aspnet/Announcements#257。
    

    引入的版本
    

    此更改强制实施跨 API 的一致性来配置使用 cookie 的功能。
    


    将已删除的 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.Builder.SessionOptions.CookieDomain
    • 

  • Microsoft.AspNetCore.Builder.SessionOptions.CookieHttpOnly
    • 

  • Microsoft.AspNetCore.Builder.SessionOptions.CookieName
    • 

  • Microsoft.AspNetCore.Builder.SessionOptions.CookiePath
    • 

  • Microsoft.AspNetCore.Builder.SessionOptions.CookieSecure
    • 

    共享框架：从 Microsoft.AspNetCore.App 中删除了程序集
    

    从 ASP.NET Core 3.0 开始，ASP.NET Core 共享框架 (Microsoft.AspNetCore.App) 仅包含 Microsoft 完全开发、支持和可维护的第一方程序集。
    

    将更改视为重新定义 ASP.NET Core“平台”的边界。共享框架将由 任何人通过 GitHub 进行源构建 ，并将继续为应用提供核心共享框架的现有优势 .NET 。 一些优势包括部署大小更小、集中修补和启动时间更快。
    

    作为此更改的一部分，Microsoft.AspNetCore.App 中引入了一些值得注意的重大更改。
    

    引入的版本
    

    项目通过项目文件中的 <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所有其他数据访问库保持一致。 它为 Entity Framework Core 提供了在支持各种 .NET 平台的同时继续创新的最简单路径。 将 Entity Framework Core 移出共享框架不会影响其作为 Microsoft 开发、支持和可服务的库的状态。 核心.NET支持策略继续涵盖它。
    

    Json.NET 和 Entity Framework Core 继续使用 ASP.NET Core。 但是，它们不会包含在共享框架中。
    

    有关详细信息，请参阅 Core 3.0 中 .NET JSON 的未来。 另请参阅从共享框架中删除的二进制文件的完整列表。
    

    此更改简化了 Microsoft.AspNetCore.App 的使用，并减少了 NuGet 包与共享框架之间的重复。
    

    有关此更改动机的详细信息，请参阅博客文章。
    

    从 ASP.NET Core 3.0 开始，项目不再需要将 程序集 Microsoft.AspNetCore.App 用作 NuGet 包。 为了简化 ASP.NET Core 共享框架的目标设定和使用，不再生成自 ASP.NET Core 1.0 以来随附的许多 NuGet 包。 通过将 <FrameworkReference> 用于 Microsoft.AspNetCore.App，应用仍可使用这些包提供的 API。 常见的 API 示例包括 Kestrel、MVC 和 Razor。
    

    此更改不适用于 ASP.NET Core 2.x 中通过 Microsoft.AspNetCore.App 引用的所有二进制文件。 值得注意的例外包括：
    

  • Microsoft.Extensions 继续面向 .NET Standard 的库作为 NuGet 包提供， (请参阅 https://github.com/dotnet/extensions) 。
    • 

  • ASP.NET Core 团队生成的 API 不属于 Microsoft.AspNetCore.App。 例如，以下组件以 NuGet 包的形式提供：
    •  
    推荐文章
    果断的冲锋衣  ·  url传数组参数并js获取-掘金
    1 年前
    有胆有识的红豆  ·  新功能发布 | 自动化模块在测试中的判定方法_51CTO博客_功能自动化测试的基础
    1 年前
    大鼻子的鸵鸟  ·  常见前端面试题及答案 - 默语 - 博客园
    1 年前
    今天看啥   ·   Py中国   ·   codingpro   ·   藏经阁   ·   小百科   ·   link之家   ·   卧龙AI搜索
    删除内容请联系邮箱 2879853325@qq.com
    Code - 代码工具平台
    © 2024 ~ 沪ICP备11025650号