Net Core2 - 2 para 3

Alterações recentes de migração da versão 2,2 para a
3,0
15/10/2019 • 55 minutos para ler •
Neste artigo
ASP.NET Core
CoreFx
Criptografia
Entity Framework Core
Globalização
Rede
） Importante
Este artigo está em construção. Esta não é uma lista completa de alterações significativas do .NET Core. Para obter mais informações
sobre as alterações significativas no .NET Core, você pode examinar os problemas individuais de alterações significativas no
repositório dotnet/docs no github.
Se você estiver migrando da versão 2,2 para a versão 3,0 do .NET Core, ASP.NET Core ou EF Core, examine os tópicos a seguir para obter
alterações significativas que possam afetar seu aplicativo:
ASP.NET Core
APIs antifalsificação obsoletas, CORS, diagnóstico, MVC e roteamento removidas
Os membros obsoletos e as opções de compatibilidade no ASP.NET Core 2,2 foram removidos.
Versão introduzida
3.0
Motivo da alteração
Melhoria da superfície da API ao longo do tempo.
Ação recomendada
Embora tenha como alvo o .NET Core 2,2, siga as orientações nas mensagens de compilação obsoletas para adotar novas APIs em vez
disso.
Categoria
ASP.NET Core
APIs afetadas
Os seguintes tipos e membros foram marcados como obsoletos para ASP.NET Core 2,1 e 2,2:
Tipos
• 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
Construtores
• Microsoft.AspNetCore.Cors.Infrastructure.CorsService.CorsService(IOptions<CorsOptions>)
• Microsoft.AspNetCore.Routing.Tree.TreeRouteBuilder.TreeRouteBuilder(ILoggerFactory, UrlEncoder, ObjectPool<UriBuildingContext>,
IInlineConstraintResolver)
• Microsoft.AspNetCore.Mvc.Formatters.OutputFormatterCanWriteContext.OutputFormatterCanWriteContext()
• Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider.DefaultApiDescriptionProvider(IOptions<MvcOptions>,
IInlineConstraintResolver, IModelMetadataProvider)
• Microsoft.AspNetCore.Mvc.ApiExplorer.DefaultApiDescriptionProvider.DefaultApiDescriptionProvider(IOptions<MvcOptions>,
IInlineConstraintResolver, IModelMetadataProvider, IActionResultTypeMapper)
• Microsoft.AspNetCore.Mvc.Formatters.FormatFilter.FormatFilter(IOptions<MvcOptions>)
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ArrayModelBinder<TElement>.ArrayModelBinder<TElement>(IModelBinder)
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ByteArrayModelBinder.ByteArrayModelBinder()
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.CollectionModelBinder<TElement>.CollectionModelBinder<TElement>
(IModelBinder)
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder.ComplexTypeModelBinder
(IDictionary<ModelMetadata,IModelBinder>)
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DictionaryModelBinder<TKey,TValue>.DictionaryModelBinder<TKey,TValue>
(IModelBinder, IModelBinder)
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DoubleModelBinder.DoubleModelBinder(NumberStyles)
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FloatModelBinder.FloatModelBinder(NumberStyles)
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormCollectionModelBinder.FormCollectionModelBinder()
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormFileModelBinder.FormFileModelBinder()
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.HeaderModelBinder.HeaderModelBinder()
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.KeyValuePairModelBinder<TKey,TValue>.KeyValuePairModelBinder<TKey,TValue>
(IModelBinder, IModelBinder)
• Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder.SimpleTypeModelBinder(Type)
• Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes.ModelAttributes(IEnumerable<Object>)
• Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes.ModelAttributes(IEnumerable<Object>, IEnumerable<Object>)
• Microsoft.AspNetCore.Mvc.ModelBinding.ModelBinderFactory.ModelBinderFactory(IModelMetadataProvider, IOptions<MvcOptions>)
• Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.ParameterBinder(IModelMetadataProvider, IModelBinderFactory,
IObjectModelValidator)
• Microsoft.AspNetCore.Mvc.Routing.KnownRouteValueConstraint.KnownRouteValueConstraint()
• Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter.XmlDataContractSerializerInputFormatter()
• Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter.XmlDataContractSerializerInputFormatter(Boolean)
• Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter.XmlDataContractSerializerInputFormatter
(MvcOptions)
• Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter.XmlSerializerInputFormatter()
• Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter.XmlSerializerInputFormatter(Boolean)
• Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter.XmlSerializerInputFormatter(MvcOptions)
• Microsoft.AspNetCore.Mvc.TagHelpers.ImageTagHelper.ImageTagHelper(IHostingEnvironment, IMemoryCache, HtmlEncoder,
IUrlHelperFactory)
• Microsoft.AspNetCore.Mvc.TagHelpers.LinkTagHelper.LinkTagHelper(IHostingEnvironment, IMemoryCache, HtmlEncoder,
JavaScriptEncoder, IUrlHelperFactory)
• Microsoft.AspNetCore.Mvc.TagHelpers.ScriptTagHelper.ScriptTagHelper(IHostingEnvironment, IMemoryCache, HtmlEncoder,
JavaScriptEncoder, IUrlHelperFactory)
• Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.RazorPageAdapter.RazorPageAdapter(RazorPageBase)
Propriedades
• 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
Métodos
• 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)
Autenticação: Google + preterido e substituído
O Google está começando a desligar o Google + entrar para aplicativos como no início de 28 de janeiro de 2019.
Alterar descrição
ASP.NET 4. x e ASP.NET Core têm usado as APIs de entrada do Google + para autenticar usuários da conta do Google em aplicativos Web.
Os pacotes NuGet afetados são Microsoft. AspNetCore. Authentication. Google para ASP.NET Core e Microsoft. Owin. Security. Google para
Microsoft.Owin com ASP.NET Web Forms e MVC.
As APIs de substituição do Google usam uma fonte de dados e um formato diferentes. As atenuações e soluções fornecidas abaixo têm
uma conta para as alterações estruturais. Os aplicativos devem verificar se os dados em si ainda atendem às suas necessidades. Por
exemplo, nomes, endereços de email, links de perfil e fotos de perfil podem fornecer valores sutilmente diferentes de antes.
Versão introduzida
Todas as versões. Essa alteração é externa a ASP.NET Core.
Ação recomendada
Owin com ASP.NET Web Forms e MVC
Para Microsoft.Owin 3.1.0 e posterior, uma mitigação temporária é descrita aqui. Os aplicativos devem concluir o teste com a mitigação
para verificar se há alterações no formato de dados. Há planos para liberar Microsoft.Owin 4.0.1 com uma correção. Os aplicativos que
usam qualquer versão anterior devem ser atualizados para a versão 4.0.1.
ASP.NET Core 1. x
A mitigação no Owin com ASP.NET Web Forms e MVC pode ser adaptada para ASP.NET Core 1. x. Os patches do pacote NuGet não estão
planejados porque 1. x atingiu o status de término da vida útil .
ASP.NET Core 2. x
Para Microsoft.AspNetCore.Authentication.Google versão 2. x, substitua sua chamada existente para AddGoogle em

Startup.ConfigureServices pelo seguinte código:
C# ＝ Copiar
.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");
});
Os patches de fevereiro de 2,1 e 2,2 incorporaram a reconfiguração anterior como o novo padrão. Nenhum patch está planejado para
ASP.NET Core 2,0, pois ele atingiu o fim da vida útil.
ASP.NET Core 3,0
A mitigação fornecida para o ASP.NET Core 2. x também pode ser usada para ASP.NET Core 3,0. Em futuras versões do 3,0, o pacote
Microsoft.AspNetCore.Authentication.Google pode ser removido. Os usuários seriam direcionados para
Microsoft.AspNetCore.Authentication.OpenIdConnect em vez disso. O código a seguir mostra como substituir AddGoogle por
AddOpenIdConnect em Startup.ConfigureServices . Essa substituição pode ser usada com o ASP.NET Core 2,0 e posterior e pode ser
adaptada para o ASP.NET Core 1. x, conforme necessário.
C# ＝ Copiar
.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 "/sigin-oidc"
o.Scope.Add("email");
});
JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
Categoria
ASP.NET Core
APIs afetadas
Microsoft.AspNetCore.Authentication.Google
Autenticação: Propriedade HttpContext. Authentication removida
A propriedade preterida Authentication em HttpContext foi removida.
Alterar descrição
Como parte do ASPNET/AspNetCore # 6504, a propriedade preterida Authentication em HttpContext foi removida. A propriedade
Authentication foi preterida desde 2,0. Um Guia de migração foi publicado para migrar o código usando essa propriedade preterida para
as novas APIs de substituição. As classes/APIs não usadas restantes relacionadas à pilha de autenticação antiga ASP.NET Core 1. x foram
removidas na confirmação aspnet/AspNetCore@d7a7c65.
Para obter uma discussão, consulte ASPNET/AspNetCore # 6533.
Versão introduzida
3.0
ASP.NET Core APIs 1,0 foram substituídas por métodos de extensão em

Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.
Ação recomendada
Consulte o Guia de migração.
Categoria
ASP.NET Core
APIs afetadas
• 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
Autenticação: tipos Newtonsoft. JSON substituídos
No ASP.NET Core 3,0, os tipos Newtonsoft.Json usados em APIs de autenticação foram substituídos por tipos System.Text.Json . Exceto
pelos seguintes casos, o uso básico dos pacotes de autenticação permanece inalterado:
• Classes derivadas de provedores OAuth, como as de ASPNET-contrib.

• Implementações avançadas de manipulação de declaração.
Para obter mais informações, consulte ASPNET/AspNetCore # 7105. Para obter uma discussão, consulte ASPNET/AspNetCore # 7289.
Versão introduzida
3.0
Ação recomendada
Para implementações de OAuth derivadas, a alteração mais comum é substituir JObject.Parse por JsonDocument.Parse na substituição
CreateTicketAsync , conforme mostrado aqui. JsonDocument implementa IDisposable .
A lista a seguir descreve as alterações conhecidas:
• ClaimAction.Run(JObject, ClaimsIdentity, String) se torna ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string

issuer) . Todas as implementações derivadas de ClaimAction são afetadas de forma semelhante.
• ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, Func<JObject,String>) se torna MapCustomJson

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

MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver)
• OAuthCreatingTicketContext teve um Construtor antigo removido e o outro foi substituído JObject por JsonElement . A propriedade
User e o método RunClaimActions foram atualizados para corresponder.
• Success(JObject) agora aceita um parâmetro do tipo JsonDocument em vez de JObject . A propriedade Response foi atualizada para
corresponder. OAuthTokenResponse agora é descartável e será descartado por OAuthHandler . As implementações de OAuth derivadas
que substituem ExchangeCodeAsync não precisam descartar o JsonDocument ou o OAuthTokenResponse .
• UserInformationReceivedContext.User alterado de JObject para JsonDocument .
• TwitterCreatingTicketContext.User alterado de JObject para JsonElement .
• TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JObject) mudou de aceitando JObject para
JsonElement .
Categoria
ASP.NET Core
APIs afetadas
• Microsoft.AspNetCore.Authentication.Facebook
• Microsoft.AspNetCore.Authentication.Google
• Microsoft.AspNetCore.Authentication.MicrosoftAccount
• Microsoft.AspNetCore.Authentication.OAuth
• Microsoft.AspNetCore.Authentication.OpenIdConnect
• Microsoft.AspNetCore.Authentication.Twitter
Autenticação: assinatura OAuthHandler ExchangeCodeAsync alterada
No ASP.NET Core 3,0, a assinatura de OAuthHandler.ExchangeCodeAsync foi alterada de:
C# ＝ Copiar
protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse>

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

ExchangeCodeAsync(Microsoft.AspNetCore.Authentication.OAuth.OAuthCodeExchangeContext context) { throw null; }
Versão introduzida
3.0
Comportamento antigo
As cadeias de caracteres code e redirectUri foram passadas como argumentos separados.
Novo comportamento
Code e RedirectUri são propriedades em OAuthCodeExchangeContext que podem ser definidas por meio do Construtor
OAuthCodeExchangeContext . O novo tipo OAuthCodeExchangeContext é o único argumento passado para OAuthHandler.ExchangeCodeAsync .
Essa alteração permite que parâmetros adicionais sejam fornecidos de forma não-significativa. Não há necessidade de criar novas
sobrecargas ExchangeCodeAsync .
Ação recomendada
Construa um OAuthCodeExchangeContext com os valores de code e redirectUri apropriados. Uma instância AuthenticationProperties deve
ser fornecida. Essa instância única OAuthCodeExchangeContext pode ser passada para OAuthHandler.ExchangeCodeAsync em vez de vários
argumentos.
Categoria
ASP.NET Core
APIs afetadas
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
Autorização: sobrecarga de addautoria movida para um assembly diferente
Os métodos Core AddAuthorization que costumava residir em Microsoft.AspNetCore.Authorization foram renomeados para
AddAuthorizationCore . Os métodos antigos de AddAuthorization ainda existem, mas estão no pacote
Microsoft.AspNetCore.Authorization.Policy , em vez disso. Os aplicativos que usam os dois métodos não devem ter nenhum impacto. Os
aplicativos que não estavam usando o pacote de política devem mudar para usando AddAuthorizationCore .
Versão introduzida
3.0
os métodos AddAuthorization existiam no Microsoft.AspNetCore.Authorization .
Novo comportamento
os métodos AddAuthorization existem no Microsoft.AspNetCore.Authorization.Policy . AddAuthorizationCore é o novo nome para os
métodos antigos.
AddAuthorization é um nome de método melhor para adicionar todos os serviços comuns necessários para autorização.
Ação recomendada
Adicione uma referência a Microsoft.AspNetCore.Authorization.Policy ou use AddAuthorizationCore em vez disso.
Categoria
ASP.NET Core
APIs afetadas
Microsoft.Extensions.DependencyInjection.AuthorizationServiceCollectionExtensions.AddAuthorization(IServiceCollection,
Action<AuthorizationOptions>)
Autorização: implementações de IAuthorizationPolicyProvider exigem novo método
No ASP.NET Core 3,0, um novo método GetFallbackPolicyAsync foi adicionado a IAuthorizationPolicyProvider . Essa política de fallback é
usada pelo middleware de autorização quando nenhuma política é especificada.
Para obter mais informações, consulte ASPNET/AspNetCore # 9759.
Versão introduzida
3.0
As implementações de IAuthorizationPolicyProvider não exigiam um método GetFallbackPolicyAsync .
Novo comportamento
As implementações de IAuthorizationPolicyProvider exigem um método GetFallbackPolicyAsync .
Um novo método era necessário para o novo AuthorizationMiddleware a ser usado quando nenhuma política é especificada.
Ação recomendada
Adicione o método GetFallbackPolicyAsync às suas implementações de IAuthorizationPolicyProvider .
Categoria
ASP.NET Core
APIs afetadas
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
Caching: Propriedade CompactOnMemoryPressure removida
A versão ASP.NET Core 3,0 removeu as APIs MemoryCacheOptions obsoletas.
Alterar descrição
Essa alteração é um acompanhamento do ASPNET/Caching # 221. Para obter uma discussão, consulte ASPNET/Extensions # 1062.
Versão introduzida
3.0
a propriedade MemoryCacheOptions.CompactOnMemoryPressure estava disponível.
Novo comportamento
A propriedade MemoryCacheOptions.CompactOnMemoryPressure foi removida.
A compactação automática do cache causou problemas. Para evitar um comportamento inesperado, o cache só deve ser compactado
quando necessário.
Ação recomendada
Para compactar o cache, downcast para MemoryCache e chamar Compact quando necessário.
Categoria
ASP.NET Core
APIs afetadas
MemoryCacheOptions.CompactOnMemoryPressure
Caching: o Microsoft. Extensions. Caching. SqlServer usa o novo pacote SqlClient
O pacote Microsoft.Extensions.Caching.SqlServer usará o novo pacote Microsoft.Data.SqlClient em vez do pacote

System.Data.SqlClient . Essa alteração pode causar pequenas alterações significativas no comportamento. Para obter mais informações,
consulte apresentando o novo Microsoft. Data. SqlClient.
Versão introduzida
3.0
O pacote Microsoft.Extensions.Caching.SqlServer usou o pacote System.Data.SqlClient .
Novo comportamento
Microsoft.Extensions.Caching.SqlServer agora está usando o pacote Microsoft.Data.SqlClient .
Microsoft.Data.SqlClient é um novo pacote criado de System.Data.SqlClient . É aqui que todo o novo recurso funcionará a partir de
agora.
Ação recomendada
Os clientes não devem precisar se preocupar com essa alteração significativa, a menos que estejam usando tipos retornados pelo pacote
Microsoft.Extensions.Caching.SqlServer e convertendo-os em tipos System.Data.SqlClient . Por exemplo, se alguém estivesse
convertendo um DbConnection para o tipo SqlConnection antigo, ele precisaria alterar a conversão para o novo tipo de
Microsoft.Data.SqlClient.SqlConnection .
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Caching: tipos de ResponseCaching "pubternal" alterados para interno
No ASP.NET Core 3,0, os tipos "pubternal" no ResponseCaching foram alterados para internal .
Além disso, as implementações padrão de IResponseCachingPolicyProvider e IResponseCachingKeyProvider não são mais adicionadas aos
serviços como parte do método AddResponseCaching .
Alterar descrição
Em ASP.NET Core, os tipos "pubternal" são declarados como public , mas residem em um namespace com sufixo .Internal . Embora esses
tipos sejam públicos, eles não têm nenhuma política de suporte e estão sujeitos a alterações significativas. Infelizmente, o uso acidental
desses tipos foi comum, resultando em alterações significativas nesses projetos e limitando a capacidade de manter a estrutura.
Versão introduzida
3.0
Esses tipos foram publicamente visíveis, mas sem suporte.
Novo comportamento
Esses tipos agora são internal .
O escopo internal reflete melhor a política sem suporte.
Ação recomendada
Tipos de cópia que são usados pelo seu aplicativo ou biblioteca.
Categoria
ASP.NET Core
APIs afetadas
• 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)
Proteção de dados: dataprotection. AzureStorage usa novas APIs de armazenamento do Azure
o Microsoft.AspNetCore.DataProtection.AzureStorage depende das bibliotecas de armazenamento do Azure. Essas bibliotecas renomeam

seus assemblies, pacotes e namespaces. A partir do ASP.NET Core 3,0, o Microsoft.AspNetCore.DataProtection.AzureStorage usa as novas
APIs e pacotes prefixados do Microsoft.Azure.Storage. .
Para perguntas sobre as APIs de armazenamento do Azure, use https://github.com/Azure/azure-storage-net. Para obter uma discussão
sobre esse problema, consulte ASPNET/AspNetCore # 8472.
Versão introduzida
3.0
O pacote referenciou o pacote NuGet WindowsAzure.Storage .
Novo comportamento
O pacote faz referência ao pacote NuGet Microsoft.Azure.Storage.Blob .
Essa alteração permite que Microsoft.AspNetCore.DataProtection.AzureStorage migre para os pacotes de armazenamento do Azure
recomendados.
Ação recomendada
Se você ainda precisar usar as APIs mais antigas do armazenamento do Azure com o ASP.NET Core 3,0, adicione uma dependência direta
ao pacote WindowsAzure. Storage . Esse pacote pode ser instalado juntamente com as novas APIs Microsoft.Azure.Storage .
Em muitos casos, a atualização envolve apenas a alteração das instruções using para usar os novos namespaces:
diff ＝ Copiar
- using Microsoft.WindowsAzure.Storage;
- using Microsoft.WindowsAzure.Storage.Blob;
+ using Microsoft.Azure.Storage;
+ using Microsoft.Azure.Storage.Blob;
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Hospedagem: AspNetCoreModule v1 removido do pacote de hospedagem do Windows
A partir do ASP.NET Core 3,0, o grupo de hospedagem do Windows não conterá AspNetCoreModule (ANCM) v1.
O ANCM V2 é compatível com versões anteriores com ANCM OutOfProcess e é recomendado para uso com ASP.NET Core aplicativos 3,0.
Versão introduzida
3.0
O ANCM v1 está incluído no pacote de hospedagem do Windows.
Novo comportamento
O ANCM v1 não está incluído no pacote de hospedagem do Windows.
O ANCM V2 é compatível com versões anteriores com ANCM OutOfProcess e é recomendado para uso com ASP.NET Core aplicativos 3,0.
Ação recomendada
Use o ANCM V2 com aplicativos ASP.NET Core 3,0.
Se o ANCM v1 for necessário, ele poderá ser instalado usando o pacote de hospedagem ASP.NET Core 2,1 ou 2,2 do Windows.
Essa alteração interromperá ASP.NET Core aplicativos 3,0 que:

• Explicitamente, optado por usar o ANCM v1 com <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName> .
• Ter um arquivo Web. config personalizado com <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule"
resourceType="Unspecified" /> .
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Hospedagem: host genérico restringe injeção de construtor de inicialização
Os únicos tipos aos quais o host genérico dá suporte para injeção de construtor de classe Startup são IHostEnvironment ,
IWebHostEnvironment e IConfiguration . Os aplicativos que usam WebHost não são afetados.
Alterar descrição
Antes do ASP.NET Core 3,0, a injeção de Construtor poderia ser usada para tipos arbitrários no construtor da classe Startup . No ASP.NET
Core 3,0, a pilha da Web foi replataforma na biblioteca de hosts genérica. Você pode ver a alteração no arquivo Program.cs dos modelos:
ASP.NET Core 2. x:
https://github.com/aspnet/AspNetCore/blob/5cb615fcbe8559e49042e93394008077e30454c0/src/Templating/src/Microsoft.DotNet.Web.Pr
ojectTemplates/content/EmptyWeb-CSharp/Program.cs#L20-L22
ASP.NET Core 3,0:
https://github.com/aspnet/AspNetCore/blob/b1ca2c1155da3920f0df5108b9fedbe82efaa11c/src/ProjectTemplates/Web.ProjectTemplates/c
ontent/EmptyWeb-CSharp/Program.cs#L19-L24
Host usa um contêiner de injeção de dependência (DI) para compilar o aplicativo. WebHost usa dois contêineres: um para o host e outro
para o aplicativo. Como resultado, o Construtor Startup não oferece mais suporte à injeção de serviço personalizado. Somente
IHostEnvironment , IWebHostEnvironment e IConfiguration podem ser injetados. Essa alteração impede problemas de DI como a criação
duplicada de um serviço singleton.
Versão introduzida
3.0
Essa alteração é uma consequência da replataforma da pilha da Web na biblioteca de hosts genérica.
Ação recomendada
Insira serviços na assinatura do método Startup.Configure . Por exemplo:
C# ＝ Copiar
public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Hospedagem: tipos IHostingEnvironment e IApplicationLifetime marcados como obsoletos e substituídos
Novos tipos foram introduzidos para substituir os tipos existentes IHostingEnvironment e IApplicationLifetime .
Versão introduzida
3.0
Havia dois tipos diferentes IHostingEnvironment e IApplicationLifetime de Microsoft.Extensions.Hosting e

Microsoft.AspNetCore.Hosting .
Novo comportamento
Os tipos antigos foram marcados como obsoletos e substituídos por novos tipos.
Quando Microsoft.Extensions.Hosting foi introduzido no ASP.NET Core 2,1, alguns tipos, como IHostingEnvironment e
IApplicationLifetime , foram copiados de Microsoft.AspNetCore.Hosting . Algumas alterações ASP.NET Core 3,0 fazem com que os
aplicativos incluam os namespaces Microsoft.Extensions.Hosting e Microsoft.AspNetCore.Hosting . Qualquer uso desses tipos duplicados
causa um erro de compilador "referência ambígua" quando ambos os namespaces são referenciados.
Ação recomendada
Substituídos os usos dos tipos antigos pelos tipos introduzidos recentemente, como abaixo:
Tipos obsoletos (aviso):
• Microsoft.Extensions.Hosting.IHostingEnvironment
• Microsoft.AspNetCore.Hosting.IHostingEnvironment
• Microsoft.Extensions.Hosting.IApplicationLifetime
• Microsoft.AspNetCore.Hosting.IApplicationLifetime
• Microsoft.Extensions.Hosting.EnvironmentName
• Microsoft.AspNetCore.Hosting.EnvironmentName
Novos tipos:
• Microsoft.Extensions.Hosting.IHostEnvironment
• Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
• Microsoft.Extensions.Hosting.IHostApplicationLifetime
• Microsoft.Extensions.Hosting.Environments
Os novos métodos de extensão IHostEnvironment IsDevelopment e IsProduction estão no namespace Microsoft.Extensions.Hosting . Esse
namespace pode precisar ser adicionado ao seu projeto.
Categoria
ASP.NET Core
APIs afetadas
• Microsoft.AspNetCore.Hosting.EnvironmentName
• Microsoft.AspNetCore.Hosting.IApplicationLifetime
• Microsoft.AspNetCore.Hosting.IHostingEnvironment
• Microsoft.Extensions.Hosting.EnvironmentName
• Microsoft.Extensions.Hosting.IApplicationLifetime
• Microsoft.Extensions.Hosting.IHostingEnvironment
Hospedagem: objectpoolprovider removido de dependências WebHostBuilder
Como parte de fazer ASP.NET Core mais Pay for Play, o ObjectPoolProvider foi removido do conjunto principal de dependências. Os
componentes específicos que dependem de ObjectPoolProvider agora o adicionam.
Versão introduzida
3.0
WebHostBuilder fornece ObjectPoolProvider por padrão no contêiner de DI.
Novo comportamento
o WebHostBuilder não fornece mais ObjectPoolProvider por padrão no contêiner de DI.
Essa alteração foi feita para fazer ASP.NET Core mais Pay for Play.
Ação recomendada
Se o componente exigir ObjectPoolProvider , ele precisará ser adicionado às suas dependências por meio do IServiceCollection .
Categoria
ASP.NET Core
APIs afetadas
Nenhum
HTTP: extensibilidade defaulthttpcontext removida
Como parte dos aprimoramentos de desempenho do ASP.NET Core 3,0, a extensibilidade do DefaultHttpContext foi removida. Agora, a
classe é sealed . Para obter mais informações, consulte ASPNET/AspNetCore # 6504.
Se os testes de unidade usarem Mock<DefaultHttpContext> , use Mock<HttpContext> em vez disso.
Versão introduzida
3.0
Classes podem derivar de DefaultHttpContext .
Novo comportamento
Classes não podem derivar de DefaultHttpContext .
A extensibilidade foi inicialmente fornecida para permitir o pooling do HttpContext , mas introduziu uma complexidade desnecessária e
impedia outras otimizações.
Ação recomendada
Se você estiver usando Mock<DefaultHttpContext> em seus testes de unidade, comece a usar Mock<HttpContext> em vez disso.
Categoria
ASP.NET Core
APIs afetadas
Microsoft.AspNetCore.Http.DefaultHttpContext
Constantes HTTP: Headernames alteradas para static readonly
A partir do ASP.NET Core 3,0 Preview 5, os campos em Microsoft.Net.Http.Headers.HeaderNames mudaram de const para static
readonly .
Versão introduzida
3.0
Esses campos costumava ser const .
Novo comportamento
Esses campos agora são static readonly .
A alteração:
• Impede que os valores sejam inseridos entre limites de assembly, permitindo correções de valor conforme necessário.
• Permite verificações de igualdade de referência mais rápidas.
Ação recomendada
Recompile em relação a 3,0. O código-fonte que usa esses campos das seguintes maneiras não pode mais fazer isso:
• Como um argumento de atributo

• Como um case em uma instrução switch
• Ao definir outro const
Para contornar a alteração significativa, alterne para usando constantes de nome de cabeçalho autodefinido ou literais de cadeia de
caracteres.
Categoria
ASP.NET Core
APIs afetadas
Microsoft.Net.Http.Headers.HeaderNames
HTTP: alterações de infraestrutura de corpo de resposta
A infraestrutura que faz o backup de um corpo de resposta HTTP foi alterada. Se você estiver usando HttpResponse diretamente, não
precisará fazer nenhuma alteração de código. Leia mais detalhadamente se você estiver encapsulando ou substituindo HttpResponse.Body
ou acessando HttpContext.Features .
Versão introduzida
3.0
Havia três APIs associadas ao corpo da resposta HTTP:
• IHttpResponseFeature.Body
• IHttpSendFileFeature.SendFileAsync
• IHttpBufferingFeature.DisableResponseBuffering
Novo comportamento
Se você substituir HttpResponse.Body , ele substituirá todo o IHttpResponseBodyFeature por um wrapper em seu fluxo específico usando
StreamResponseBodyFeature para fornecer implementações padrão para todas as APIs esperadas. A configuração de volta do fluxo original
reverte essa alteração.
A motivação é combinar as APIs de corpo de resposta em uma única interface de recurso nova.
Ação recomendada
Use IHttpResponseBodyFeature em que você estava usando anteriormente IHttpResponseFeature.Body , IHttpSendFileFeature ou

IHttpBufferingFeature .
Categoria
ASP.NET Core
APIs afetadas
• Microsoft.AspNetCore.Http.Features.IHttpBufferingFeature
• Microsoft.AspNetCore.Http.Features.IHttpResponseFeature.Body
• Microsoft.AspNetCore.Http.Features.IHttpSendFileFeature
HTTP: e/s síncrona desabilitada em todos os servidores
A partir do ASP.NET Core 3,0, as operações de servidor síncronas são desabilitadas por padrão.
Alterar descrição
AllowSynchronousIO é uma opção em cada servidor que habilita ou desabilita APIs de e/s síncronas como HttpRequest.Body.Read ,
HttpResponse.Body.Write e Stream.Flush . Essas APIs têm sido uma origem de privação de threads e bloqueios de aplicativo. A partir do
ASP.NET Core 3,0 Preview 3, essas operações síncronas são desabilitadas por padrão.
Servidores afetados:
• Kestrel
• HttpSys
• IIS em processo
• TestServer
Esperar erros semelhantes a:
• 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.
Cada servidor tem uma opção AllowSynchronousIO que controla esse comportamento e o padrão para todos eles agora é false .
O comportamento também pode ser substituído em uma base por solicitação como uma mitigação temporária. Por exemplo:
C# ＝ Copiar
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();

if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}
Se você tiver problemas com um TextWriter ou outro fluxo chamando uma API síncrona no Dispose , chame a nova API DisposeAsync em
vez disso.
Versão introduzida
3.0
os HttpRequest.Body.Read , HttpResponse.Body.Write e Stream.Flush eram permitidos por padrão.
Novo comportamento
Essas APIs síncronas não são permitidas por padrão:
Esperar erros semelhantes a:
• 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.
Essas APIs síncronas têm sido uma origem de privação de threads e bloqueios de aplicativo. A partir do ASP.NET Core 3,0 Preview 3, as
operações síncronas são desabilitadas por padrão.
Ação recomendada
Use as versões assíncronas dos métodos. O comportamento também pode ser substituído em uma base por solicitação como uma
mitigação temporária.
C# ＝ Copiar
var syncIOFeature = HttpContext.Features.Get<IHttpBodyControlFeature>();

if (syncIOFeature != null)
{
syncIOFeature.AllowSynchronousIO = true;
}
Categoria
ASP.NET Core
APIs afetadas
• Stream.Flush
• Stream.Read
• Stream.Write
Identidade: sobrecarga do método AddDefaultUI removida
A partir do ASP.NET Core 3,0, a sobrecarga do método IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework) não existe
mais.
Versão introduzida
3.0
Essa alteração foi resultado da adoção do recurso de ativos da Web estáticos.
Ação recomendada
Chame IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) em vez da sobrecarga. Se você estiver usando a inicialização 3, adicione

também a seguinte linha a um elemento <PropertyGroup> em seu arquivo de projeto:
XML ＝ Copiar
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
Categoria
ASP.NET Core
APIs afetadas
Microsoft.AspNetCore.Identity.IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
Identidade: versão de inicialização padrão da interface do usuário alterada
A partir do ASP.NET Core 3,0, a interface do usuário de identidade usa como padrão a versão 4 da inicialização.
Versão introduzida
3.0
A chamada do método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); era a mesma que

services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
Novo comportamento
A chamada do método services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); é a mesma que

A inicialização 4 foi lançada durante ASP.NET Core período de tempo de 3,0.
Ação recomendada
Você será afetado por essa alteração se usar a interface do usuário de identidade padrão e a tiver adicionado em
Startup.ConfigureServices , conforme mostrado no exemplo a seguir:
C# ＝ Copiar
services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
Execute uma das seguintes ações:
• Migre seu aplicativo para usar a inicialização 4 usando o Guia de migração.
• Atualize Startup.ConfigureServices para impor o uso da inicialização 3. Por exemplo:
C# ＝ Copiar
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Identidade: o SignInAsync gera uma exceção para a identidade não autenticada
Por padrão, SignInAsync gera uma exceção para entidades/identidades nas quais IsAuthenticated é false .
Versão introduzida
3.0
SignInAsync aceita quaisquer entidades/identidades, incluindo identidades nas quais IsAuthenticated é false .
Novo comportamento
Por padrão, SignInAsync gera uma exceção para entidades/identidades nas quais IsAuthenticated é false . Há um novo sinalizador para
suprimir esse comportamento, mas o comportamento padrão foi alterado.
O comportamento antigo era problemático porque, por padrão, essas entidades foram rejeitadas por [Authorize] @ no__t-1 @ no__t-2.
Ação recomendada
No ASP.NET Core 3,0 Preview 6, há um sinalizador RequireAuthenticatedSignIn no AuthenticationOptions que é true por padrão. Defina
esse sinalizador como false para restaurar o comportamento antigo.
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Identity: o Construtor SignInManager aceita o novo parâmetro
A partir do ASP.NET Core 3,0, um novo parâmetro IUserConfirmation<TUser> foi adicionado ao Construtor SignInManager . Para obter mais
informações, consulte ASPNET/AspNetCore # 8356.
Versão introduzida
3.0
A motivação para a alteração foi adicionar suporte a novos fluxos de email/confirmação em identidade.
Ação recomendada
Se você construir manualmente um SignInManager , forneça uma implementação de IUserConfirmation ou pegue um da injeção de
dependência a ser fornecida.
Categoria
ASP.NET Core
APIs afetadas
SignInManager<TUser>.SignInManager<TUser>
Identidade: a interface do usuário usa o recurso de ativos da Web estáticos
O ASP.NET Core 3,0 introduziu um recurso de ativos da Web estático e a interface do usuário da identidade o adotou.
Alterar descrição
Como resultado da interface do usuário de identidade adotando o recurso de ativos da Web estáticos:
• A seleção de estrutura é realizada usando a propriedade IdentityUIFrameworkVersion em seu arquivo de projeto.

• A inicialização 4 é a estrutura de interface do usuário padrão para a interface do usuário de identidade. A inicialização 3 atingiu o fim
da vida útil e você deve considerar a migração para uma versão com suporte.
Versão introduzida
3.0
A estrutura de interface do usuário padrão da interface do usuário de identidade foi a inicialização 3. A estrutura da interface do usuário
pode ser configurada usando um parâmetro para a chamada do método AddDefaultUI em Startup.ConfigureServices .
Novo comportamento
A estrutura de interface do usuário padrão para identidade de interface do usuário é Bootstrap 4. A estrutura da interface do usuário deve
ser configurada em seu arquivo de projeto, em vez de na chamada do método AddDefaultUI .
A adoção do recurso de ativos da Web estáticos exigia que a configuração da estrutura da interface do usuário se mova para o MSBuild. A
decisão sobre qual estrutura deve ser inserida é uma decisão em tempo de compilação, não uma decisão de tempo de execução.
Ação recomendada
Examine a interface do usuário do site para garantir que os novos componentes Bootstrap 4 sejam compatíveis. Se necessário, use a
propriedade do MSBuild IdentityUIFrameworkVersion para reverter para a inicialização 3. Adicione a propriedade a um elemento
<PropertyGroup> em seu arquivo de projeto:
XML ＝ Copiar
<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>
Categoria
ASP.NET Core
APIs afetadas
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
Kestrel: adaptadores de conexão removidos
Como parte da mudança para mover APIs "pubternal" para public , o conceito de um IConnectionAdapter foi removido de Kestrel. Os
adaptadores de conexão estão sendo substituídos pelo middleware de conexão (semelhante ao middleware HTTP no pipeline de ASP.NET
Core, mas para conexões de nível inferior). O log de conexão e HTTPS foi movido dos adaptadores de conexão para o middleware de
conexão. Esses métodos de extensão devem continuar funcionando sem problemas, mas os detalhes da implementação foram alterados.
Para obter mais informações, consulte ASPNET/AspNetCore # 11412. Para obter uma discussão, consulte ASPNET/AspNetCore # 11475.
Versão introduzida
3.0
Os componentes de extensibilidade do Kestrel foram criados usando IConnectionAdapter .
Novo comportamento
Os componentes de extensibilidade do Kestrel são criados como middleware.
Essa alteração destina-se a fornecer uma arquitetura de extensibilidade mais flexível.
Ação recomendada
Converta todas as implementações de IConnectionAdapter para usar o novo padrão de middleware, conforme mostrado aqui.
Categoria
ASP.NET Core
APIs afetadas
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter
Kestrel: assembly HTTPS vazio removido

O assembly Microsoft.AspNetCore.Server.Kestrel.Https foi removido.
Versão introduzida
3.0
No ASP.NET Core 2,1, o conteúdo de Microsoft.AspNetCore.Server.Kestrel.Https foi movido para

Microsoft.AspNetCore.Server.Kestrel.Core. Essa alteração foi feita de forma não significativa usando atributos [TypeForwardedTo] .
Ação recomendada
• Bibliotecas que fazem referência a Microsoft.AspNetCore.Server.Kestrel.Https 2,0 devem atualizar todas as dependências de
ASP.NET Core para 2,1 ou posterior. Caso contrário, eles poderão ser interrompidos quando forem carregados em um aplicativo
ASP.NET Core 3,0.
• Os aplicativos e bibliotecas destinados a ASP.NET Core 2,1 e posterior devem remover todas as referências diretas para o pacote
NuGet Microsoft.AspNetCore.Server.Kestrel.Https .
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Kestrel: Solicitar cabeçalhos de trailer movidos para nova coleção
Nas versões anteriores, Kestrel adicionou cabeçalhos de trailers de HTTP/1.1 na coleção de cabeçalhos de solicitação quando o corpo da
solicitação foi lido até o final. Esse comportamento causou preocupações sobre ambigüidade entre cabeçalhos e trailers. A decisão foi feita
para mover os trailers para uma nova coleção.
Os trailers de solicitação HTTP/2 não estavam disponíveis no ASP.NET Core 2,2, mas agora também estão disponíveis nesta nova coleção no
ASP.NET Core 3,0.
Novos métodos de extensão de solicitação foram adicionados para acessar esses trailers.
Os trailers HTTP/1.1 estão disponíveis quando todo o corpo da solicitação tiver sido lido.
Os trailers HTTP/2 estão disponíveis quando são recebidos do cliente. O cliente não enviará os trailers até que todo o corpo da solicitação
tenha sido pelo menos armazenado em buffer pelo servidor. Talvez seja necessário ler o corpo da solicitação para liberar espaço no buffer.
Os trailers sempre estarão disponíveis se você ler o corpo da solicitação para o final. Os marcadores marcam o fim do corpo.
Versão introduzida
3.0
Os cabeçalhos do trailer de solicitação seriam adicionados à coleção HttpRequest.Headers .
Novo comportamento
Os cabeçalhos de trailer de solicitação não estão presentes na coleção HttpRequest.Headers . Use os métodos de extensão a seguir em
HttpRequest para acessá-los:
• GetDeclaredTrailers() -Obtém o cabeçalho "trailer" da solicitação que lista os marcadores a serem esperados após o corpo.
• SupportsTrailers() -indica se a solicitação dá suporte ao recebimento de cabeçalhos de trailer.
• CheckTrailersAvailable() -determina se a solicitação dá suporte a trailers e se está disponível para leitura.
• GetTrailer(string trailerName) -Obtém o cabeçalho à direita solicitado da resposta.
Os trailers são um recurso importante em cenários como o gRPC. Mesclar os trailers em cabeçalhos de solicitação era confuso para os
usuários.
Ação recomendada
Use os métodos de extensão relacionados ao trailer em HttpRequest para acessar os trailers.
Categoria
ASP.NET Core
APIs afetadas
HttpRequest.Headers
Kestrel: abstrações de transporte removidas e tornadas públicas
Como parte da afastamento das APIs "pubternal", as APIs da camada de transporte do Kestrel são expostas como uma interface pública na
biblioteca Microsoft.AspNetCore.Connections.Abstractions .
Versão introduzida
3.0
• Abstrações relacionadas ao transporte estavam disponíveis na biblioteca

Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions .
• A propriedade ListenOptions.NoDelay estava disponível.
Novo comportamento
• A interface IConnectionListener foi introduzida na biblioteca Microsoft.AspNetCore.Connections.Abstractions para expor a

funcionalidade mais usada da biblioteca ...Transport.Abstractions .
• O NoDelay agora está disponível nas opções de transporte ( LibuvTransportOptions e SocketTransportOptions ).
• SchedulingMode não está mais disponível.
ASP.NET Core 3,0 foi afastado das APIs "pubternal".
Ação recomendada
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Localização: ResourceManagerWithCultureStringLocalizer e WithCulture marcados como obsoletos
A classe ResourceManagerWithCultureStringLocalizer e o membro da interface WithCulture geralmente são fontes de confusão para os
usuários da localização, especialmente ao criar sua própria implementação IStringLocalizer . Esses itens dão ao usuário a impressão de
que uma instância IStringLocalizer é "por idioma, por recurso". Na realidade, as instâncias só devem ser "por recurso". O idioma
procurado é determinado pelo CultureInfo.CurrentUICulture no momento da execução. Para eliminar a origem da confusão, as APIs foram
marcadas como obsoletas no ASP.NET Core 3,0 Preview 3. As APIs serão removidas em uma versão futura.
Para contexto, consulte ASPNET/AspNetCore # 3324. Para obter uma discussão, consulte ASPNET/AspNetCore # 7756.
Versão introduzida
3.0
Os métodos não estavam marcados como Obsolete .

Novo comportamento
Os métodos são marcados Obsolete .
As APIs representaram um caso de uso que não é recomendado. Houve uma confusão sobre o design da localização.
Ação recomendada
A recomendação é usar ResourceManagerStringLocalizer em vez disso. Permita que a cultura seja definida pelo CurrentCulture . Se essa
não for uma opção, crie e use uma cópia de ResourceManagerWithCultureStringLocalizer.
Categoria
ASP.NET Core
APIs afetadas
• ResourceManagerWithCultureStringLocalizer
• ResourceManagerStringLocalizer.WithCulture
Log: classe DebugLogger criada internamente
Antes do ASP.NET Core 3,0, o modificador de acesso de DebugLogger era public . No ASP.NET Core 3,0, o modificador de acesso foi
alterado para internal .
Versão introduzida
3.0
A alteração está sendo feita para:
• Impor consistência com outras implementações de agente, como ConsoleLogger .

• Reduza a superfície da API.
Ação recomendada
Use o método de extensão AddDebug ILoggingBuilder para habilitar o log de depuração. DebugLoggerProvider ainda é public no caso
de o serviço precisar ser registrado manualmente.
Categoria
ASP.NET Core
APIs afetadas
Microsoft.Extensions.Logging.Debug.DebugLogger
MVC: sufixo assíncrono cortado dos nomes de ação do controlador
Como parte do endereçamento ASPNET/AspNetCore # 4849, ASP.NET Core MVC apara o sufixo Async dos nomes de ação por padrão. A
partir do ASP.NET Core 3,0, essa alteração afeta o roteamento e a geração de link.
Versão introduzida
3.0
Considere o seguinte controlador MVC ASP.NET Core:
C# ＝ Copiar
public class ProductController : Controller
{
public async IActionResult ListAsync()
{
var model = await DbContext.Products.ToListAsync();
return View(model);
}
}
A ação é roteável via Product/ListAsync . A geração de link requer a especificação do sufixo Async . Por exemplo:
CSHTML ＝ Copiar
<a asp-controller="Product" asp-action="ListAsync">List</a>
Novo comportamento
No ASP.NET Core 3,0, a ação é roteável via Product/List . O código de geração de link deve omitir o sufixo Async . Por exemplo:
CSHTML ＝ Copiar
<a asp-controller="Product" asp-action="List">List</a>
Essa alteração não afeta os nomes especificados usando o atributo [ActionName] . O novo comportamento pode ser desabilitado definindo
MvcOptions.SuppressAsyncSuffixInActionNames como false em Startup.ConfigureServices :
C# ＝ Copiar
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
Por convenção, os métodos .NET assíncronos têm um sufixo Async . No entanto, quando um método define uma ação MVC, não é desejável
usar o sufixo Async .
Ação recomendada
Se seu aplicativo depende de ações do MVC preservando o sufixo Async do nome, escolha uma das seguintes atenuações:
• Use o atributo [ActionName] para preservar o nome original.

• Desabilite a renomeação total definindo MvcOptions.SuppressAsyncSuffixInActionNames como false em Startup.ConfigureServices :
C# ＝ Copiar
services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
Categoria
ASP.NET Core
APIs afetadas
Nenhum
MVC: ferramenta de pré-compilação preterida
No ASP.NET Core 1,1, o pacote Microsoft.AspNetCore.Mvc.Razor.ViewCompilation (ferramenta de pré-compilação MVC) foi introduzido para
adicionar suporte à compilação de tempo de publicação de arquivos Razor (arquivos . cshtml ). No ASP.NET Core 2,1, o SDK do Razor foi
introduzido para expandir os recursos da ferramenta de pré-compilação. O SDK do Razor adicionou suporte para compilação de
compilação e tempo de publicação de arquivos Razor. O SDK verifica a exatidão dos arquivos . cshtml no momento da compilação, ao
mesmo tempo em que melhora o tempo de inicialização do aplicativo. O SDK do Razor está ativado por padrão e nenhum gesto é
necessário para começar a usá-lo.
No ASP.NET Core 3,0, a ferramenta de pré-compilação MVC ASP.NET Core 1,1 de era removida. Versões anteriores do pacote continuarão
recebendo correções importantes de bugs e de segurança na versão do patch.
Versão introduzida
3.0
O pacote Microsoft.AspNetCore.Mvc.Razor.ViewCompilation foi usado para pré-compilar exibições do Razor do MVC.
Novo comportamento
O SDK do Razor oferece suporte nativo a essa funcionalidade. O pacote Microsoft.AspNetCore.Mvc.Razor.ViewCompilation não é mais
atualizado.
O SDK do Razor fornece mais funcionalidade e verifica a exatidão dos arquivos . cshtml no momento da compilação. O SDK também
melhora o tempo de inicialização do aplicativo.
Ação recomendada
Para usuários do ASP.NET Core 2,1 ou posterior, atualize para usar o suporte nativo para pré-compilação no SDK do Razor. Se os bugs ou
os recursos ausentes impedirem a migração para o SDK do Razor, abra um problema em ASPNET/AspNetCore.
Categoria
ASP.NET Core
APIs afetadas
Nenhum
MVC: tipos "Pubternal" alterados para interno
No ASP.NET Core 3,0, todos os tipos "pubternal" no MVC foram atualizados para public em um namespace com suporte ou internal ,
conforme apropriado.
Alterar descrição
Em ASP.NET Core, os tipos "pubternal" são declarados como public , mas residem em um namespace .Internal . Embora esses tipos sejam
public , eles não têm nenhuma política de suporte e estão sujeitos a alterações significativas. Infelizmente, o uso acidental desses tipos foi
comum, resultando em alterações significativas nesses projetos e limitando a capacidade de manter a estrutura.
Versão introduzida
3.0
Alguns tipos no MVC foram public , mas em um namespace .Internal . Esses tipos não tinham nenhuma política de suporte e estavam
sujeitos a alterações significativas.
Novo comportamento
Todos esses tipos são atualizados para serem public em um namespace com suporte ou marcados como internal .
O uso acidental dos tipos "pubternal" é comum, resultando em alterações significativas nesses projetos e limitando a capacidade de manter
a estrutura.
Ação recomendada
Se você estiver usando tipos que se tornaram verdadeiramente public e foram movidos para um novo namespace com suporte, atualize
suas referências para que correspondam aos novos namespaces.
Se você estiver usando tipos que se tornaram marcados como internal , você precisará encontrar uma alternativa. Os tipos de "pubternal"
anteriormente nunca tinham suporte para uso público. Se houver tipos específicos nesses namespaces que são críticos para seus
aplicativos, execute um problema em ASPNET/AspNetCore. Podem ser feitas considerações para fazer os tipos solicitados public .
Categoria
ASP.NET Core
APIs afetadas
Essa alteração inclui tipos nos seguintes namespaces:
• 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: Shim de compatibilidade da API Web removido
A partir do ASP.NET Core 3,0, o pacote Microsoft.AspNetCore.Mvc.WebApiCompatShim não está mais disponível.
Alterar descrição
O pacote Microsoft.AspNetCore.Mvc.WebApiCompatShim (WebApiCompatShim) fornece compatibilidade parcial em ASP.NET Core com a API
Web do ASP.NET 4. x para simplificar a migração de implementações de API Web existentes para ASP.NET Core. No entanto, os aplicativos
que usam o WebApiCompatShim não se beneficiam dos recursos relacionados à API fornecidos em versões recentes de ASP.NET Core.
Esses recursos incluem geração aprimorada de especificação de API aberta, tratamento de erro padronizado e geração de código de
cliente. Para focar melhor os esforços de API em 3,0, o WebApiCompatShim foi removido. Os aplicativos existentes que usam o
WebApiCompatShim devem migrar para o modelo [ApiController] mais recente.
Versão introduzida
3.0
O Shim da compatibilidade da API Web era uma ferramenta de migração. Ele restringe o acesso do usuário à nova funcionalidade
adicionada no ASP.NET Core.
Ação recomendada
Remova o uso desse Shim e migre diretamente para a funcionalidade semelhante no ASP.NET Core em si.
Categoria
ASP.NET Core
APIs afetadas
Microsoft.AspNetCore.Mvc.WebApiCompatShim
Razor: compilação de tempo de execução movida para um pacote
O suporte para a compilação em tempo de execução de exibições do Razor e Razor Pages foi movido para um pacote separado.
Versão introduzida
3.0
A compilação em tempo de execução está disponível sem a necessidade de pacotes adicionais.
Novo comportamento
A funcionalidade foi movida para o pacote Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .
As APIs a seguir estavam disponíveis anteriormente no Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions para dar suporte à

compilação em tempo de execução. As APIs agora estão disponíveis por meio de
Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions .
• RazorViewEngineOptions.FileProviders -> MvcRazorRuntimeCompilationOptions.FileProviders

• RazorViewEngineOptions.AdditionalCompilationReferences -> MvcRazorRuntimeCompilationOptions.AdditionalReferencePaths
Além disso, Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions.AllowRecompilingViewsOnFileChange foi removido. A recompilação em

alterações de arquivo é habilitada por padrão referenciando o pacote Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .
Essa alteração foi necessária para remover a dependência de estrutura compartilhada ASP.NET Core em Roslyn.
Ação recomendada
Aplicativos que exigem compilação em tempo de execução ou recompilação de arquivos Razor devem executar as seguintes etapas:
1. Adicione uma referência ao pacote Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation .
2. Atualize o método Startup.ConfigureServices do projeto para incluir uma chamada para AddMvcRazorRuntimeCompilation . Por
exemplo, em Startup.ConfigureServices :
C# ＝ Copiar
services.AddMvc()
.AddMvcRazorRuntimeCompilation();
Categoria
ASP.NET Core
APIs afetadas
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
Estado da sessão: APIs obsoletas removidas
APIs obsoletas para configurar cookies de sessão foram removidas. Para obter mais informações, consulte ASPNET/comunicados n º 257.
Versão introduzida
3.0
Essa alteração impõe a consistência entre APIs para configurar recursos que usam cookies.
Ação recomendada
Migre o uso das APIs removidas para suas substituições mais recentes. Considere o exemplo a seguir em Startup.ConfigureServices :
C# ＝ Copiar
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;
});
}
Categoria
ASP.NET Core
APIs afetadas
• 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
Estrutura compartilhada: assemblies removidos do Microsoft. AspNetCore. app
A partir do ASP.NET Core 3,0, a estrutura compartilhada ASP.NET Core ( Microsoft.AspNetCore.App ) contém apenas assemblies de terceiros
que são totalmente desenvolvidos, com suporte e podem ser atendidos pela Microsoft.
Alterar descrição
Imagine a alteração como a redefinição de limites para a ASP.NET Core "plataforma". A estrutura compartilhada será criada de origem por
qualquer pessoa por meio do GitHub e continuará a oferecer os benefícios existentes das estruturas compartilhadas do .NET Core para seus
aplicativos. Alguns benefícios incluem tamanho de implantação menor, aplicação de patch centralizada e tempo de inicialização mais
rápido.
Como parte da alteração, algumas alterações significativas importantes são introduzidas em Microsoft.AspNetCore.App .
Versão introduzida
3.0
Projetos referenciados Microsoft.AspNetCore.App por meio de um elemento <PackageReference> no arquivo de projeto.
Além disso, Microsoft.AspNetCore.App continha os seguintes subcomponentes:
• Json.NET ( Newtonsoft.Json )
• Entity Framework Core (assemblies prefixados com Microsoft.EntityFrameworkCore. )
• Roslyn ( Microsoft.CodeAnalysis )
Novo comportamento
Uma referência a Microsoft.AspNetCore.App não requer mais um elemento <PackageReference> no arquivo de projeto. O SDK do .NET Core
dá suporte a um novo elemento chamado <FrameworkReference> , que substitui o uso de <PackageReference> .
Para obter mais informações, consulte ASPNET/AspNetCore # 3612.
Entity Framework Core são fornecidos como pacotes NuGet. Essa alteração alinha o modelo de envio com todas as outras bibliotecas de
acesso a dados no .NET. Ele fornece Entity Framework Core caminho mais simples para continuar inovação enquanto dá suporte a várias
plataformas .NET. A mudança de Entity Framework Core da estrutura compartilhada não tem impacto sobre seu status como uma biblioteca
de serviços desenvolvidos, com suporte e desenvolvido pela Microsoft. A política de suporte do .NET Core continua a cobrir.
Json.NET e Entity Framework Core continuam trabalhando com ASP.NET Core. No entanto, eles não serão incluídos na estrutura
compartilhada.
Para obter mais informações, consulte o futuro do JSON no .NET Core 3,0. Consulte também a lista completa de binários removidos da
estrutura compartilhada.
Essa alteração simplifica o consumo de Microsoft.AspNetCore.App e reduz a duplicação entre pacotes do NuGet e estruturas
compartilhadas.
Para obter mais informações sobre a motivação para essa alteração, consulte esta postagem no blog.
Ação recomendada
Não será necessário que os projetos consumam assemblies em Microsoft.AspNetCore.App como pacotes NuGet. Para simplificar o
direcionamento e o uso da estrutura ASP.NET Core compartilhada, muitos pacotes NuGet fornecidos desde ASP.NET Core 1,0 não são mais
produzidos. As APIs que esses pacotes fornecem ainda estão disponíveis para aplicativos usando um <FrameworkReference> a
Microsoft.AspNetCore.App . Exemplos comuns de API incluem Kestrel, MVC e Razor.
Essa alteração não se aplica a todos os binários referenciados por meio de Microsoft.AspNetCore.App em ASP.NET Core 2. x. As exceções
notáveis incluem:
• as bibliotecas Microsoft.Extensions que continuam a direcionar .NET Standard estarão disponíveis como pacotes NuGet (consulte
https://github.com/aspnet/Extensions).
• APIs produzidas pela equipe de ASP.NET Core que não fazem parte do Microsoft.AspNetCore.App . Por exemplo, os seguintes
componentes estão disponíveis como pacotes NuGet:
◦ Entity Framework Core
◦ APIs que fornecem integração de terceiros
◦ Recursos experimentais
◦ APIs com dependências que não puderam atender aos requisitos para estar na estrutura compartilhada
• Extensões para MVC que mantêm suporte para Json.NET. Uma API será fornecida como um pacote NuGet para dar suporte ao uso do
Json.NET e MVC.
• O cliente do sinalizador .NET continuará a dar suporte a .NET Standard e enviará como um pacote NuGet. Ele é destinado ao uso em
vários tempos de execução do .NET, como Xamarin e UWP.
Para obter mais informações, consulte parar de produzir pacotes para assemblies de estrutura compartilhada em 3,0. Para obter uma
discussão, consulte ASPNET/AspNetCore # 3757.
Categoria
ASP.NET Core
APIs afetadas
• Microsoft.CodeAnalysis
• Microsoft.EntityFrameworkCore
Estrutura compartilhada: Microsoft. AspNetCore. All removido
A partir do ASP.NET Core 3,0, o metapacote Microsoft.AspNetCore.All e a estrutura compartilhada Microsoft.AspNetCore.All

correspondente não são mais produzidos. Este pacote está disponível no ASP.NET Core 2,2 e continuará a receber atualizações de serviço
no ASP.NET Core 2,1.
Versão introduzida
3.0
Os aplicativos podem usar o metapacote Microsoft.AspNetCore.All para direcionar a estrutura compartilhada Microsoft.AspNetCore.All
no .NET Core.
Novo comportamento
O .NET Core 3,0 não inclui uma estrutura compartilhada Microsoft.AspNetCore.All .
O metapacote Microsoft.AspNetCore.All incluía um grande número de dependências externas.
Ação recomendada
Migre seu projeto para usar a estrutura Microsoft.AspNetCore.App . Os componentes que estavam disponíveis anteriormente no
Microsoft.AspNetCore.All ainda estão disponíveis no NuGet. Esses componentes agora são implantados com seu aplicativo, em vez de
serem incluídos na estrutura compartilhada.
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Signalr: HandshakeProtocol. SuccessHandshakeData substituído
O campo HandshakeProtocol. SuccessHandshakeData foi removido e substituído por um método auxiliar que gera uma resposta de
handshake com êxito, dado um IHubProtocol específico.
Versão introduzida
3.0
HandshakeProtocol.SuccessHandshakeData era um campo public static ReadOnlyMemory<byte> .
Novo comportamento
HandshakeProtocol.SuccessHandshakeData foi substituído por um método static GetSuccessfulHandshake(IHubProtocol protocol) que
retorna um ReadOnlyMemory<byte> com base no protocolo especificado.
Campos adicionais foram adicionados à resposta de handshake que são não constantes e mudam dependendo do protocolo selecionado.
Ação recomendada
nenhuma. Esse tipo não é projetado para uso do código do usuário. É public , para que possa ser compartilhado entre o servidor e o
cliente do Signalr. Ele também pode ser usado por clientes do Signalr do cliente escritos em .NET. Os usuários do signalr não devem ser
afetados por essa alteração.
Categoria
ASP.NET Core
APIs afetadas
SuccessHandshakeData
Signalr: métodos HubConnection ResetSendPing e ResetTimeout removidos
Os métodos ResetSendPing e ResetTimeout foram removidos da API do Signalr HubConnection . Esses métodos eram originalmente
destinados apenas ao uso interno, mas foram disponibilizados para o público em ASP.NET Core 2,2. Esses métodos não estarão disponíveis
a partir da versão ASP.NET Core 3,0 Preview 4. Para obter uma discussão, consulte ASPNET/AspNetCore # 8543.
Versão introduzida
3.0
APIs estavam disponíveis.
Novo comportamento
As APIs são removidas.
Esses métodos eram originalmente destinados apenas ao uso interno, mas foram disponibilizados para o público em ASP.NET Core 2,2.
Ação recomendada
Não use esses métodos.
Categoria
ASP.NET Core
APIs afetadas
• HubConnection.ResetSendPing()
• HubConnection.ResetTimeout()
Signalr: construtores HubConnectionContext alterados
Os construtores HubConnectionContext do signalr foram alterados para aceitar um tipo de opções, em vez de vários parâmetros, para a
adição de opções à prova de futuro. Essa alteração substitui dois construtores por um único Construtor que aceita um tipo de opções.
Versão introduzida
3.0
HubConnectionContext tem dois construtores:
C# ＝ Copiar
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);

public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory,
TimeSpan clientTimeoutInterval);
Novo comportamento
Os dois construtores foram removidos e substituídos por um construtor:
C# ＝ Copiar
public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory

loggerFactory)
O novo construtor usa um novo objeto Options. Consequentemente, os recursos de HubConnectionContext podem ser expandidos no
futuro sem fazer mais construtores e alterações significativas.
Ação recomendada
Em vez de usar o Construtor a seguir:
C# ＝ Copiar
HubConnectionContext connectionContext = new HubConnectionContext(

connectionContext,
keepAliveInterval: TimeSpan.FromSeconds(15),
loggerFactory,
clientTimeoutInterval: TimeSpan.FromSeconds(15));
Use o seguinte construtor:
C# ＝ Copiar
HubConnectionContextOptions contextOptions = new HubConnectionContextOptions()

{
KeepAliveInterval = TimeSpan.FromSeconds(15),
ClientTimeoutInterval = TimeSpan.FromSeconds(15)
};
HubConnectionContext connectionContext = new HubConnectionContext(connectionContext, contextOptions, loggerFactory);
Categoria
ASP.NET Core
APIs afetadas
• HubConnectionContext.HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory)

• HubConnectionContext.HubConnectionContext(ConnectionContext, TimeSpan, ILoggerFactory, TimeSpan)
Signalr: nome do pacote de cliente JavaScript alterado
No ASP.NET Core 3,0 Preview 7, o nome do pacote de cliente do sinalizador JavaScript mudou de @aspnet/signalr para
@microsoft/signalr . A alteração de nome reflete o fato de que o Signalr é útil em mais do que apenas ASP.NET Core aplicativos, graças ao
serviço de Signaler do Azure.
Para reagir a essa alteração, altere as referências em seus arquivos Package. JSON , instruções require e instruções ECMAScript import .
Nenhuma API será alterada como parte dessa renomeação.
Versão introduzida
3.0
O pacote do cliente foi nomeado @aspnet/signalr .
Novo comportamento
O pacote do cliente é denominado @microsoft/signalr .
A alteração de nome esclarece que o Signalr é útil além dos aplicativos ASP.NET Core, graças ao serviço do Azure Signalr.
Ação recomendada
Alterne para o novo pacote @microsoft/signalr .
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Signalr: métodos UseSignalR e UseConnections marcados como obsoletos
Os métodos UseConnections e UseSignalR e as classes ConnectionsRouteBuilder e HubRouteBuilder são marcados como obsoletos no
ASP.NET Core 3,0.
Versão introduzida
3.0
O roteamento de Hub do signalr foi configurado usando UseSignalR ou UseConnections .
Novo comportamento
A maneira antiga de configurar o roteamento foi obsoleta e substituída pelo roteamento de ponto de extremidade.
O middleware está sendo movido para o novo sistema de roteamento de ponto de extremidade. A maneira antiga de adicionar o
middleware está sendo obsoleta.
Ação recomendada
Substituir UseSignalR por UseEndpoints :
Código antigo:
C# ＝ Copiar
app.UseSignalR(routes =>
{
routes.MapHub<SomeHub>("/path");
});
Novo código:
C# ＝ Copiar
app.UseEndpoints(endpoints =>
{
endpoints.MapHub<SomeHub>("/path");
});
Categoria
ASP.NET Core
APIs afetadas
• Microsoft.AspNetCore.Builder.ConnectionsAppBuilderExtensions.UseConnections(IApplicationBuilder,
Action<ConnectionsRouteBuilder>)
• Microsoft.AspNetCore.Builder.SignalRAppBuilderExtensions.UseSignalR(IApplicationBuilder, Action<HubRouteBuilder>)
• Microsoft.AspNetCore.Http.Connections.ConnectionsRouteBuilder
• Microsoft.AspNetCore.SignalR.HubRouteBuilder
SPAs: SpaServices e Nodeservices marcados como obsoletos
Todos os conteúdos dos pacotes NuGet a seguir foram desnecessários desde ASP.NET Core 2,1. Consequentemente, os seguintes pacotes
estão sendo marcados como obsoletos:
• Microsoft. AspNetCore. SpaServices

• Microsoft. AspNetCore. Nodeservices
Pelo mesmo motivo, os seguintes módulos NPM estão sendo marcados como preteridos:
• ASPNET-angular
• ASPNET-pré-processamento
• ASPNET-webpack
• ASPNET-webpack – reagir
• tarefa de domínio
Os pacotes anteriores e os módulos NPM serão removidos posteriormente no .NET 5.

Versão introduzida
3.0
Os pacotes preteridos e os módulos NPM foram destinados a integrar ASP.NET Core com várias estruturas de SPA (aplicativo de página
única). Tais estruturas incluem angular, reagir e reagir com Redux.
Novo comportamento
Existe um novo mecanismo de integração no pacote NuGet Microsoft. AspNetCore. SpaServices. Extensions . O pacote permanece a base
dos modelos de projeto angular e reajam desde o ASP.NET Core 2,1.
O ASP.NET Core dá suporte à integração com várias estruturas de SPA (aplicativo de página única), incluindo angular, reagir e reagir com
Redux. Inicialmente, a integração com essas estruturas foi realizada com componentes específicos do ASP.NET Core que manipulavam
cenários como o pré-processamento do lado do servidor e a integração com o webpack. À medida que o tempo passou, os padrões do
setor mudaram. Cada uma das estruturas de SPA lançou suas próprias interfaces de linha de comando padrão. Por exemplo, CLI angular e
Create-reajam-app.
Quando ASP.NET Core 2,1 foi lançado em maio de 2018, a equipe respondeu à alteração nos padrões. Foi fornecida uma maneira mais
nova e mais simples de integrar com o próprio cadeias das estruturas do SPA. O novo mecanismo de integração existe no pacote
Microsoft.AspNetCore.SpaServices.Extensions e permanece a base dos modelos de projeto angular e reajam desde ASP.NET Core 2,1.
Para esclarecer que os componentes mais antigos ASP.NET Core específicos são irrelevantes e não são recomendados:
• O mecanismo de integração anterior ao 2,1 é marcado como obsoleto.

• Os pacotes NPM de suporte são marcados como preteridos.
Ação recomendada
Se você estiver usando esses pacotes, atualize seus aplicativos para usar a funcionalidade:
• No pacote Microsoft.AspNetCore.SpaServices.Extensions .
• Fornecido pelas estruturas SPA que você está usando
Para habilitar recursos como o pré-processamento do lado do servidor e a recarga de módulo quente, consulte a documentação da
estrutura SPA correspondente. A funcionalidade no Microsoft.AspNetCore.SpaServices.Extensions não está obsoleta e continuará a ter
suporte.
Categoria
ASP.NET Core
APIs afetadas
• Microsoft.AspNetCore.Builder.SpaRouteExtensions
• Microsoft.AspNetCore.Builder.WebpackDevMiddleware
• Microsoft.AspNetCore.NodeServices.EmbeddedResourceReader
• Microsoft.AspNetCore.NodeServices.INodeServices
• Microsoft.AspNetCore.NodeServices.NodeServicesFactory
• Microsoft.AspNetCore.NodeServices.NodeServicesOptions
• Microsoft.AspNetCore.NodeServices.StringAsTempFile
• 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.Prerenderer
• Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper
• Microsoft.AspNetCore.SpaServices.Prerendering.RenderToStringResult
• Microsoft.AspNetCore.SpaServices.Webpack.WebpackDevMiddlewareOptions
• Microsoft.Extensions.DependencyInjection.NodeServicesServiceCollectionExtensions
• Microsoft.Extensions.DependencyInjection.PrerenderingServiceCollectionExtensions
SPAs: SpaServices e Nodeservices não retornam mais para o agente do console
Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices não exibirão logs do console, a menos que o log esteja
configurado.
Versão introduzida
3.0
Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices usados para criar automaticamente um agente de log do console
quando o registro não estiver configurado.
Novo comportamento
Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices não exibirão logs do console, a menos que o log esteja
configurado.
Há a necessidade de se alinhar com o modo como outros pacotes de ASP.NET Core implementam o registro em log.
Ação recomendada
Se o comportamento antigo for necessário, para configurar o log do console, adicione services.AddLogging(builder => builder.AddConsole
()) ao seu método Setup.ConfigureServices .
Categoria
ASP.NET Core
APIs afetadas
Nenhum
Estrutura de destino: suporte a .NET Framework Descartado
A partir do ASP.NET Core 3,0, .NET Framework é uma estrutura de destino sem suporte.
Alterar descrição
.NET Framework 4,8 é a última versão principal do .NET Framework. Novos aplicativos de ASP.NET Core devem ser criados no .NET Core. A
partir da versão 3,0 do .NET Core, você pode considerar ASP.NET Core 3,0 como parte do .NET Core.
Os clientes que usam ASP.NET Core com .NET Framework podem continuar de uma maneira totalmente compatível usando a versão 2,1 do
LTS. O suporte e serviço para 2,1 continua até, pelo menos, 21 de agosto de 2021. Essa data é de três anos após a declaração da versão do
LTS de acordo com a política de suporte do .net. O suporte para pacotes ASP.NET Core 2,1 em .NET Framework será estendido
indefinidamente, semelhante à política de serviço para outras estruturas ASP.net baseadas em pacote.
Para obter mais informações sobre como portar do .NET Framework para o .NET Core, consulte portando para o .NET Core.
os pacotes Microsoft.Extensions (como registro em log, injeção de dependência e configuração) e Entity Framework Core não são
afetados. Eles continuarão a dar suporte a .NET Standard.
Para obter mais informações sobre a motivação para essa alteração, consulte a postagem do blog original.
Versão introduzida
3.0
ASP.NET Core aplicativos podem ser executados no .NET Core ou .NET Framework.
Novo comportamento
ASP.NET Core aplicativos só podem ser executados no .NET Core.
Ação recomendada
Execute uma das seguintes ações:
• Mantenha seu aplicativo no ASP.NET Core 2,1.

• Migre seu aplicativo e as dependências para o .NET Core.
Categoria
ASP.NET Core
APIs afetadas
Nenhum
CoreFx
As APIs que relatam versão agora relatam produto e não versão de arquivo
Muitas das APIs que retornam versões no .NET Core agora retornavam a versão do produto em vez da versão do arquivo.
Alterar descrição
No .NET Core 2,2 e em versões anteriores, métodos como Environment.Version, RuntimeInformation.FrameworkDescriptione a caixa de
diálogo Propriedades do arquivo para assemblies do .NET Core refletem a versão do arquivo. A partir do .NET Core 3,0, eles refletem a
versão do produto.
A figura a seguir ilustra a diferença nas informações de versão do assembly System. Runtime. dll para .net Core 2,2 (à esquerda) e do .net
Core 3,0 (à direita), conforme exibido pela caixa de diálogo Propriedades de arquivo do Windows Explorer .
Versão introduzida
3.0
Ação recomendada
nenhuma. Essa alteração deve tornar a detecção de versão intuitiva, em vez de obtuso.
Categoria
CoreFx
APIs afetadas
• Environment.Version
• RuntimeInformation.FrameworkDescription
Instâncias EncoderFallbackBuffer personalizadas não podem retornar recursivamente
As instâncias EncoderFallbackBuffer personalizadas não podem retornar recursivamente. A implementação de

EncoderFallbackBuffer.GetNextChar() deve resultar em uma sequência de caracteres que é conversível para a codificação de destino. Caso
contrário, ocorrerá uma exceção.
Alterar descrição
Durante uma operação de transcodificação de caractere para byte, o tempo de execução detecta sequências UTF-16 mal formadas ou não
conversíveis e fornece esses caracteres para o método EncoderFallbackBuffer.Fallback. O método Fallback determina quais caracteres
devem ser substituídos pelos dados não conversíveis originais, e esses caracteres são drenados chamando
EncoderFallbackBuffer.GetNextChar em um loop.
Em seguida, o tempo de execução tenta transcodificar esses caracteres de substituição para a codificação de destino. Se essa operação for
realizada com sucesso, o tempo de execução continuará transcodificando de onde parou na cadeia de caracteres de entrada original.
No .NET Core Preview 7 e versões anteriores, implementações personalizadas de EncoderFallbackBuffer.GetNextChar() podem retornar
sequências de caracteres que não são conversíveis para a codificação de destino. Se os caracteres substituídos não puderem ser
transcodificados para a codificação de destino, o tempo de execução invocará o método EncoderFallbackBuffer.Fallback mais uma vez com
os caracteres de substituição, esperando que o método EncoderFallbackBuffer.GetNextChar() retorne uma nova sequência de substituição.
Esse processo continua até que o tempo de execução eventualmente Veja uma substituição bem formada, conversível ou até que uma
contagem de recursão máxima seja atingida.
A partir do .NET Core 3,0, implementações personalizadas de EncoderFallbackBuffer.GetNextChar() devem retornar sequências de
caracteres que são conversíveis para a codificação de destino. Se os caracteres substituídos não puderem ser transcodificados para a
codificação de destino, um ArgumentException será lançado. O tempo de execução não fará mais chamadas recursivas na instância
EncoderFallbackBuffer.
Esse comportamento se aplica somente quando todas as três condições a seguir são atendidas:
• O tempo de execução detecta uma sequência UTF-16 mal formada ou uma sequência UTF-16 que não pode ser convertida para a
codificação de destino.
• Um EncoderFallback personalizado foi especificado.
• O EncoderFallback personalizado tenta substituir uma nova sequência UTF-16 mal formada ou não conversível.
Versão introduzida
3.0
Ação recomendada
A maioria dos desenvolvedores não precisam realizar nenhuma ação.
Se um aplicativo usar uma classe EncoderFallback e EncoderFallbackBuffer personalizada, verifique se a implementação de

EncoderFallbackBuffer.Fallback popula o buffer de fallback com dados UTF-16 bem formados que são diretamente conversíveis para a
codificação de destino quando o método Fallback é invocado pela primeira vez pelo appmodel.
Categoria
CoreFx
APIs afetadas
• EncoderFallbackBuffer.Fallback
• EncoderFallbackBuffer.GetNextChar()
Comportamento de análise e formatação de ponto flutuante alterado
A Double análise de ponto flutuante e o comportamento de formatação ( Single pelos tipos e) agora são compatíveis com IEEE.
Alterar descrição
No .NET Core 2,2 e versões anteriores, Formatar com Double.ToString e Single.ToStringe analisar Single.TryParse com, Double.TryParse,
Double.Parse Single.Parsee não são compatíveis com IEEE. Como resultado, é impossível garantir que um valor seja arvoltado com qualquer
cadeia de caracteres de formato padrão ou personalizada com suporte. Para algumas entradas, a tentativa de analisar um valor formatado
pode falhar e, para outros, o valor analisado não é igual ao valor original.
A partir do .NET Core 3,0, as operações de análise e formatação são compatíveis com o IEEE 754. Isso garante que o comportamento dos
tipos de ponto flutuante no .NET corresponda ao de linguagens compatíveis com IEEE, C#como. Para obter mais informações, consulte a
postagem de ponto flutuante e melhorias de formatação no blog do .NET Core 3,0 .
Versão introduzida
3.0
Ação recomendada
A seção "impacto potencial para código existente" das melhorias de análise de ponto flutuante e de formatação na postagem de blog
do .net Core 3,0 sugere alterações no código se você observar uma alteração de comportamento em comparação com os aplicativos .net
Core 2,2 em geral, Isso envolve o uso de uma cadeia de caracteres de formato padrão ou personalizada diferente para impor o
comportamento desejado. Alguns resultados podem não ter uma solução alternativa se eles estavam incorretos anteriormente.
Categoria
CoreFx
APIs afetadas
• Double.ToString
• Single.ToString
• Double.Parse
• Double.TryParse
• Single.Parse
• Single.TryParse
Operações de análise de ponto flutuante não falham mais ou geram uma estourexception
Os métodos de análise de ponto flutuante não lançam mais um OverflowException ou retornam false quando analisam uma cadeia de
caracteres cujo valor numérico está fora do intervalo do Single ou Double tipo de ponto flutuante.
Alterar descrição
No .NET Core 2,2 e versões anteriores, os métodos Double.Parse e Single.Parse geram uma OverflowException para valores que estão fora
do intervalo de seus respectivos tipos. Os métodos Double.TryParse e Single.TryParse retornam false para as representações de cadeia de
caracteres de valores numéricos fora do intervalo.
A partir do .NET Core 3,0, os métodos Double.Parse, Double.TryParse, Single.Parsee Single.TryParse não falham mais ao analisar cadeias de
caracteres numéricas fora do intervalo. Em vez disso, os métodos de análise de Double retornam Double.PositiveInfinity para valores que
excedem Double.MaxValuee retornam Double.NegativeInfinity para valores menores que Double.MinValue. Da mesma forma, os métodos
de análise de Single retornam Single.PositiveInfinity para valores que excedem Single.MaxValuee retornam Single.NegativeInfinity para
valores menores que Single.MinValue.
Essa alteração foi feita para melhorar a conformidade com o IEEE 754:2008.
Versão introduzida
3.0
Ação recomendada
Essa alteração pode afetar o código de uma das duas maneiras:
• Seu código depende do manipulador para que o OverflowException seja executado quando ocorrer um estouro. Nesse caso, você
deve remover a instrução catch e inserir qualquer código necessário em uma instrução If que testa se Double.IsInfinity ou
Single.IsInfinity é true .
• Seu código supõe que os valores de ponto flutuante não são Infinity . Nesse caso, você deve adicionar o código necessário para
verificar se há valores de ponto flutuante de PositiveInfinity e NegativeInfinity .
Categoria
CoreFx
APIs afetadas
• Double.Parse
• Double.TryParse
• Single.Parse
• Single.TryParse
InvalidAsynchronousStateException movido para outro assembly
A InvalidAsynchronousStateException classe foi movida.
Alterar descrição
No .NET Core 2,2 e versões anteriores, a InvalidAsynchronousStateException classe é encontrada no assembly System. ComponentModel.
TypeConverter .
A partir do .NET Core 3,0, ele é encontrado no assembly System. ComponentModel. primitivas .
Versão introduzida
3.0
Ação recomendada
Essa alteração afeta apenas os aplicativos que usam a reflexão para InvalidAsynchronousStateException carregar o chamando um método
Assembly.GetType como ou uma sobrecarga de Activator.CreateInstance que assume que o tipo está em um assembly específico. Se esse
for o caso, o assembly ao qual o assembly referenciado na chamada do método deve ser atualizado para refletir o novo local do assembly
do tipo.
Categoria
CoreFx
APIs afetadas
• Nenhum
O .NET Core 3,0 segue as práticas recomendadas de Unicode ao substituir sequências de bytes UTF-8 malformadas
Quando a classe UTF8Encoding encontra uma sequência de bytes UTF-8 mal formada durante uma operação de transcodificação byte a
caractere, ela substituirá essa sequência por um caractere ' ' (caractere de substituição U + FFFD) na cadeia de caracteres de saída. O .NET
Core 3,0 é diferente das versões anteriores do .NET Core e do .NET Framework seguindo a prática recomendada de Unicode para executar
essa substituição durante a operação de transcodificação.
Isso faz parte de um esforço maior para melhorar a manipulação de UTF-8 em todo o .NET, incluindo os novos tipos
System.Text.Unicode.Utf8 e System.Text.Rune. O tipo UTF8Encoding recebeu um mecanismo de tratamento de erros aprimorado para que
ele produza uma saída consistente com os tipos introduzidos recentemente.
Alterar descrição
A partir do .NET Core 3,0, ao transcodificar bytes em caracteres, a classe UTF8Encoding executa a substituição de caracteres com base nas
práticas recomendadas Unicode. O mecanismo de substituição usado é descrito pelo padrão Unicode, versão 12,0, seg. 3,9 (PDF) no título
intitulado U + FFFD substituição de subpartes do máximo.
Esse comportamento se aplica somente quando a sequência de bytes de entrada contém dados UTF-8 mal formados. Além disso, se a
instância UTF8Encoding tiver sido construída com throwOnInvalidBytes: true (consulte a [documentação do construtor do UTF8Encoding]
(UTF8Encoding(Boolean, Boolean), a instância UTF8Encoding continuará a gerar uma entrada inválida em vez de executar a substituição U +
FFFD.
O seguinte ilustra o impacto dessa alteração com uma entrada de 3 bytes inválida:
Entrada de 3 bytes formada incorretamente Saída antes do .NET Core 3,0 Saída a partir do .NET Core 3,0
[ ED A0 90 ] [ FFFD FFFD ] (saída de 2 caracteres) [ FFFD FFFD FFFD ] (saída de 3 caracteres)
Essa saída de 3 caracteres é a saída preferida, de acordo com a tabela 3-9 do PDF padrão Unicode vinculado anteriormente.
Versão introduzida
3.0
Ação recomendada
Nenhuma ação é necessária na parte do desenvolvedor.
Categoria
CoreFx
APIs afetadas
• UTF8Encoding.GetCharCount
• UTF8Encoding.GetChars
• UTF8Encoding.GetString(Byte[], Int32, Int32)
TypeDescriptionProviderAttribute movido para outro assembly
A TypeDescriptionProviderAttribute classe foi movida.

Alterar descrição
No .NET Core 2,2 e versões anteriores, a TypeDescriptionProviderAttribute classe é encontrada no assembly System. ComponentModel.
TypeConverter .
A partir do .NET Core 3,0, ele é encontrado no assembly System. ObjectModel .
Versão introduzida
3.0
Ação recomendada
Essa alteração afeta apenas os aplicativos que usam a reflexão para TypeDescriptionProviderAttribute carregar o tipo chamando um
método Assembly.GetType como ou uma sobrecarga de Activator.CreateInstance que assume que o tipo está em um assembly específico.
Se esse for o caso, o assembly referenciado na chamada do método deverá ser atualizado para refletir o novo local do assembly do tipo.
Categoria
Windows Forms
APIs afetadas
• Nenhum
O ZipArchiveEntry não lida mais com os arquivos mortos com tamanhos de entrada inconsistentes
Os arquivos zip listam Tamanho compactado e Tamanho descompactado no diretório central e no cabeçalho local. Os próprios dados de
entrada também indicam seu tamanho. No .NET Core 2,2 e versões anteriores, esses valores nunca foram verificados quanto à consistência.
A partir do .NET Core 3,0, eles agora são.
Alterar descrição
No .NET Core 2,2 e versões anteriores, ZipArchiveEntry.Open() o é bem sucedido mesmo que o cabeçalho local desconcorde com o
cabeçalho central do arquivo zip. Os dados são descompactados até que o final do fluxo compactado seja atingido, mesmo que seu
comprimento exceda o tamanho do arquivo descompactado listado no cabeçalho do diretório central/local.
A partir do .NET Core 3,0, ZipArchiveEntry.Open() o método verifica se o cabeçalho local e o cabeçalho central concordam em tamanhos
compactados e não compactados de uma entrada. Se não tiverem, o método lançará um InvalidDataException se o cabeçalho local do
arquivo e/ou os tamanhos da lista do descritor de dados que discordarem com o diretório central do arquivo zip. Ao ler uma entrada, os
dados descompactados são truncados para o tamanho de arquivo descompactado listado no cabeçalho.
Essa alteração foi feita para garantir que um ZipArchiveEntry represente corretamente o tamanho de seus dados e que apenas essa
quantidade de dados seja lida.
Versão introduzida
3.0
Ação recomendada
Empacote novamente qualquer arquivo zip que exiba esses problemas.
Categoria
CoreFx
APIs afetadas
• ZipArchiveEntry.Open()
• ZipFileExtensions.ExtractToDirectory
• ZipFileExtensions.ExtractToFile
• ZipFile.ExtractToDirectory
Criptografia
EnvelopedCms usa como padrão a criptografia AES-256
O algoritmo de criptografia simétrica padrão usado pelo EnvelopedCms foi alterado de TripleDES para AES-256.
Alterar descrição
No .NET Core Preview 7 e versões anteriores, quando EnvelopedCms é usado para criptografar dados sem especificar um algoritmo de
criptografia simétrica por meio de uma sobrecarga de construtor, os dados foram criptografados com o algoritmo
TripleDES/3DES/3DEA/DES3-EDE.
A partir do .NET Core 3,0 Preview 8 (por meio da versão 4.6.0 do pacote NuGet System. Security. Cryptography. Pkcs ), o algoritmo padrão
foi alterado para AES-256 para modernização do algoritmo e para melhorar a segurança das opções padrão. Se um certificado de
destinatário de mensagem tiver uma chave pública Diffie-Hellman (não-EC), a operação de criptografia poderá falhar com um
CryptographicException devido a limitações na plataforma subjacente.
No código de exemplo a seguir, os dados são criptografados com TripleDES se executados no .NET Core 3,0 Preview 7 ou anterior. Se
estiver executando no .NET Core 3,0 Preview 8 ou posterior, ele será criptografado com AES-256.
C# ＝ Copiar
EnvelopedCms cms = new EnvelopedCms(content);

cms.Encrypt(recipient);
return cms.Encode();
Versão introduzida
3,0 Preview 8
Ação recomendada
Se você for afetado negativamente pela alteração, poderá restaurar a criptografia TripleDES especificando explicitamente o identificador de
algoritmo de criptografia em um Construtor EnvelopedCms que inclui um parâmetro do tipo AlgorithmIdentifier, como:
C# ＝ Copiar
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()l
Categoria
Criptografia
APIs afetadas
• EnvelopedCms.EnvelopedCms()
• EnvelopedCms.EnvelopedCms(ContentInfo)
• EnvelopedCms.EnvelopedCms(SubjectIdentifierType, ContentInfo)
O tamanho mínimo para geração de chave RSAOpenSsl aumentou
O tamanho mínimo para gerar novas chaves RSA no Linux aumentou de 384 bits para 512 bits.
Alterar descrição
A partir do .NET Core 3,0, o tamanho mínimo da chave legal relatado LegalKeySizes pela propriedade nas instâncias RSA RSA.Createde
RSAOpenSsl.RSAOpenSsl, e RSACryptoServiceProvider.RSACryptoServiceProvider no Linux aumentou de 384 para 512.
Como resultado, no .NET Core 2,2 e em versões anteriores, uma chamada de método como RSA.Create(384) o é bem sucedido. No .NET
Core 3,0 e versões posteriores, a chamada RSA.Create(384) do método gera uma exceção indicando que o tamanho é muito pequeno.
Essa alteração foi feita porque o OpenSSL, que executa as operações criptográficas no Linux, aumentou seu mínimo entre as versões 1.0.2 e
1.1.0. O .NET Core 3,0 prefere o OpenSSL 1.1. x a 1,0. x e a versão relatada mínima foi gerada para refletir essa nova limitação de
dependência mais alta.
Versão introduzida
3.0
Ação recomendada
Se você chamar qualquer uma das APIs afetadas, certifique-se de que o tamanho de qualquer chave gerada não seja menor do que o
mínimo do provedor.
７ Observação
o RSA de 384 bits já é considerado inseguro (como é o RSA de 512 bits). As recomendações modernas, como a publicação especial do
NIST 800-57 parte 1 revisão 4, sugerem 2048 bits como o tamanho mínimo para chaves geradas recentemente.
Categoria
Criptografia
APIs afetadas
• AsymmetricAlgorithm.LegalKeySizes
• RSA.Create
• RSAOpenSsl.RSAOpenSsl
• RSACryptoServiceProvider.RSACryptoServiceProvider
O .NET Core 3,0 prefere o OpenSSL 1.1. x ao OpenSSL 1.0. x
O .NET Core para Linux, que funciona em várias distribuições do Linux, pode dar suporte a OpenSSL 1.0. x e OpenSSL 1.1. x. .NET Core 2,1
e .NET Core 2,2 Procure 1,0. x primeiro e, em seguida, retorne para 1.1. x; o .NET Core 3,0 procura por 1,1. x primeiro. Essa alteração foi feita
para adicionar suporte para novos padrões de criptografia.
Essa alteração pode afetar as bibliotecas ou os aplicativos que fazem a interoperabilidade de plataforma com os tipos de interoperabilidade
específicos do OpenSSL no .NET Core.
Alterar descrição
No .NET Core 2,2 e versões anteriores, o tempo de execução prefere carregar o OpenSSL 1.0. x acima de 1.1. x. Isso significa que os IntPtr
tipos SafeHandle e para interoperabilidade com OpenSSL são usados com libcrypto. portanto. 1.0.0/libcrypto. portanto. 1.0/libcrypto.
portanto, 10 por preferência.
A partir do .NET Core 3,0, o tempo de execução prefere carregar o OpenSSL 1.1. x em relação ao OpenSSL 1.0 IntPtr . SafeHandle x,
portanto, os tipos e para interoperabilidade com OpenSSL são usados com libcrypto. por isso, 1.1/libcrypto. portanto, 11/libcrypto.
portanto, 1.1.0/libcrypto. portanto. 1.1.1 por preferência. Como resultado, as bibliotecas e os aplicativos que interoperam com o OpenSSL
diretamente podem ter ponteiros incompatíveis com os valores expostos do .NET Core ao atualizar do .NET Core 2,1 ou do .NET Core 2,2.
Versão introduzida
3.0
Ação recomendada
Bibliotecas e aplicativos que fazem operações diretas com o OpenSSL precisam ter cuidado para garantir que estejam usando a mesma
versão do OpenSSL que o tempo de execução do .NET Core.
Todas as bibliotecas ou aplicativos que IntPtr usam SafeHandle ou valores dos tipos de criptografia do .NET Core diretamente com o
OpenSSL devem comparar a versão da biblioteca que usam com SafeEvpPKeyHandle.OpenSslVersion a nova propriedade para garantir que
os ponteiros sejam compatíveis.
Categoria
Criptografia
APIs afetadas
• SafeEvpPKeyHandle.SafeEvpPKeyHandle
• RSAOpenSsl.RSAOpenSsl(IntPtr)
• RSAOpenSsl.RSAOpenSsl(SafeEvpPKeyHandle)
• RSAOpenSsl.DuplicateKeyHandle()
• DSAOpenSsl.DSAOpenSsl(IntPtr)
• DSAOpenSsl.DSAOpenSsl(SafeEvpPKeyHandle)
• DSAOpenSsl.DuplicateKeyHandle()
• ECDsaOpenSsl.ECDsaOpenSsl(IntPtr)
• ECDsaOpenSsl.ECDsaOpenSsl(SafeEvpPKeyHandle)
• ECDsaOpenSsl.DuplicateKeyHandle()
• ECDiffieHellmanOpenSsl.ECDiffieHellmanOpenSsl(IntPtr)
• ECDiffieHellmanOpenSsl.ECDiffieHellmanOpenSsl(SafeEvpPKeyHandle)
• ECDiffieHellmanOpenSsl.DuplicateKeyHandle()
• X509Certificate.Handle
Entity Framework Core

Entity Framework Core alterações significativas
Globalização
A localidade "C" é mapeada para a localidade invariável
O .NET Core 2,2 e versões anteriores dependem do comportamento padrão do ICU, que mapeia a localidade "C" para a localidade
en_US_POSIX. A localidade en_US_POSIX tem um comportamento de agrupamento indesejável, pois não oferece suporte a comparações de
cadeias de caracteres que não diferenciam maiúsculas de minúscula Como algumas distribuições do Linux definem a localidade "C" como a
localidade padrão, os usuários estão apresentando um comportamento inesperado.
Alterar descrição
A partir do .NET Core 3,0, o mapeamento de localidade "C" foi alterado para usar a localidade invariável em vez de en_US_POSIX. A
localidade "C" para mapeamento invariável também é aplicada ao Windows para fins de consistência.
O mapeamento de "C" para a cultura en_US_POSIX causou confusão do cliente, pois o en_US_POSIX não dá suporte a operações de cadeia
de caracteres de classificação/pesquisa sem diferenciação Como a localidade "C" é usada como uma localidade padrão em alguns dos
distribuições do Linux, os clientes tiveram esse comportamento indesejado nesses sistemas operacionais.
Versão introduzida
3.0
Ação recomendada
Nada mais específico do que a conscientização dessa alteração. Essa alteração afeta apenas os aplicativos que usam o mapeamento de
localidade "C".
Categoria
Globalização
APIs afetadas
Todas as APIs de agrupamento e cultura são afetadas por essa alteração.
Rede
Valor padrão de HttpRequestMessage. Version alterado para 1,1
O valor padrão da propriedade System.Net.Http.HttpRequestMessage.Version foi alterado de 2,0 para 1,1.
Versão introduzida
.NET Core 3.0
Alterar descrição
No .NET Core 1,0 até 2,0, o valor padrão da propriedade System.Net.Http.HttpRequestMessage.Version é 1,1. A partir do .NET Core 2,1, ele
foi alterado para 2,1.
A partir do .NET Core 3,0, o número de versão padrão retornado pela propriedade System.Net.Http.HttpRequestMessage.Version é mais
uma vez 1,1.
Ação recomendada
Atualize seu código se ele depender da propriedade System.Net.Http.HttpRequestMessage.Version retornando um valor padrão de 2,0.
Categoria
Rede
APIs afetadas
• System.Net.Http.HttpRequestMessage.Version
Esta página é útil?
 Sim  Não

Net Core2 - 2 para 3

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Net Core2 - 2 para 3

Caricato da

Copyright:

Formati disponibili

Alterações recentes de migração da versão 2,2 para a

APIs antifalsificação obsoletas, CORS, diagnóstico, MVC e roteamento removidas

Os membros obsoletos e as opções de compatibilidade no ASP.NET Core 2,2 foram removidos.

Melhoria da superfície da API ao longo do tempo.

Autenticação: Google + preterido e substituído

Todas as versões. Essa alteração é externa a ASP.NET Core.

Owin com ASP.NET Web Forms e MVC

Para Microsoft.AspNetCore.Authentication.Google versão 2. x, substitua sua chamada existente para AddGoogle em

ASP.NET Core 3,0

adaptada para o ASP.NET Core 1. x, conforme necessário.

Autenticação: Propriedade HttpContext. Authentication removida

A propriedade preterida Authentication em HttpContext foi removida.

Para obter uma discussão, consulte ASPNET/AspNetCore # 6533.

ASP.NET Core APIs 1,0 foram substituídas por métodos de extensão em

Consulte o Guia de migração.

Autenticação: tipos Newtonsoft. JSON substituídos

• Classes derivadas de provedores OAuth, como as de ASPNET-contrib.

A lista a seguir descreve as alterações conhecidas:

• ClaimAction.Run(JObject, ClaimsIdentity, String) se torna ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string

• ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, Func<JObject,String>) se torna MapCustomJson

• ClaimActionCollectionMapExtensions.MapCustomJson(ClaimActionCollection, String, String, Func<JObject,String>) se torna

No ASP.NET Core 3,0, a assinatura de OAuthHandler.ExchangeCodeAsync foi alterada de:

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse>

protected virtual System.Threading.Tasks.Task<Microsoft.AspNetCore.Authentication.OAuth.OAuthTokenResponse>

As cadeias de caracteres code e redirectUri foram passadas como argumentos separados.

OAuthCodeExchangeContext . O novo tipo OAuthCodeExchangeContext é o único argumento passado para OAuthHandler.ExchangeCodeAsync .

Autorização: sobrecarga de addautoria movida para um assembly diferente

os métodos AddAuthorization existiam no Microsoft.AspNetCore.Authorization .

Adicione uma referência a Microsoft.AspNetCore.Authorization.Policy ou use AddAuthorizationCore em vez disso.

Autorização: implementações de IAuthorizationPolicyProvider exigem novo método

Para obter mais informações, consulte ASPNET/AspNetCore # 9759.

As implementações de IAuthorizationPolicyProvider não exigiam um método GetFallbackPolicyAsync .

As implementações de IAuthorizationPolicyProvider exigem um método GetFallbackPolicyAsync .

Adicione o método GetFallbackPolicyAsync às suas implementações de IAuthorizationPolicyProvider .

Caching: Propriedade CompactOnMemoryPressure removida

A versão ASP.NET Core 3,0 removeu as APIs MemoryCacheOptions obsoletas.

a propriedade MemoryCacheOptions.CompactOnMemoryPressure estava disponível.

A propriedade MemoryCacheOptions.CompactOnMemoryPressure foi removida.

Caching: o Microsoft. Extensions. Caching. SqlServer usa o novo pacote SqlClient

O pacote Microsoft.Extensions.Caching.SqlServer usará o novo pacote Microsoft.Data.SqlClient em vez do pacote

consulte apresentando o novo Microsoft. Data. SqlClient.

O pacote Microsoft.Extensions.Caching.SqlServer usou o pacote System.Data.SqlClient .

Microsoft.Extensions.Caching.SqlServer agora está usando o pacote Microsoft.Data.SqlClient .

Esses tipos foram publicamente visíveis, mas sem suporte.

Esses tipos agora são internal .

O escopo internal reflete melhor a política sem suporte.

Tipos de cópia que são usados pelo seu aplicativo ou biblioteca.

Proteção de dados: dataprotection. AzureStorage usa novas APIs de armazenamento do Azure

o Microsoft.AspNetCore.DataProtection.AzureStorage depende das bibliotecas de armazenamento do Azure. Essas bibliotecas renomeam

O pacote referenciou o pacote NuGet WindowsAzure.Storage .

O pacote faz referência ao pacote NuGet Microsoft.Azure.Storage.Blob .

Hospedagem: AspNetCoreModule v1 removido do pacote de hospedagem do Windows

Para obter uma discussão, consulte ASPNET/AspNetCore # 7095.

O ANCM v1 está incluído no pacote de hospedagem do Windows.

O ANCM v1 não está incluído no pacote de hospedagem do Windows.

Use o ANCM V2 com aplicativos ASP.NET Core 3,0.

Essa alteração interromperá ASP.NET Core aplicativos 3,0 que:

Hospedagem: host genérico restringe injeção de construtor de inicialização

ASP.NET Core 3,0:

duplicada de um serviço singleton.

Insira serviços na assinatura do método Startup.Configure . Por exemplo:

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

Hospedagem: tipos IHostingEnvironment e IApplicationLifetime marcados como obsoletos e substituídos