Partilhar via

Alterações significativas no .NET Core 3.0

  • Artigo

Se você estiver migrando para a versão 3.0 do .NET Core, ASP.NET Core ou EF Core, as alterações recentes listadas neste artigo podem afetar seu aplicativo.

ASP.NET Core

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

Membros obsoletos e switches de compatibilidade no ASP.NET Core 2.2 foram removidos.

Versão introduzida

3.0

Razão para a alteração

Melhoria da superfície API ao longo do tempo.

Ao direcionar o .NET Core 2.2, siga as orientações nas mensagens de compilação obsoletas para adotar novas APIs.

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

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

Metodologia

APIs "Pubternal" removidas

Para manter melhor a superfície de API pública do ASP.NET Core, a maioria dos tipos em *.Internal namespaces (referidos como "pubternal" APIs) tornou-se verdadeiramente interna. Os membros nesses namespaces nunca foram feitos para serem suportados como APIs voltadas para o público. As APIs podiam quebrar em versões menores e muitas vezes o faziam. O código que depende dessas APIs é interrompido ao atualizar para o ASP.NET Core 3.0.

Para obter mais informações, consulte dotnet/aspnetcore#4932 e dotnet/aspnetcore#11312.

Versão introduzida

3.0

Comportamento antigo

As APIs afetadas são marcadas com o modificador de public acesso e existem em *.Internal namespaces.

Novo comportamento

As APIs afetadas são marcadas com o modificador de acesso interno e não podem mais ser usadas por código fora desse assembly.

Razão para a alteração

A orientação para essas "pubternal" APIs era que:

  • Pode mudar sem aviso prévio.
  • Não estavam sujeitos a políticas do .NET para evitar alterações de rutura.

Deixar as APIs public (mesmo nos *.Internal namespaces) era confuso para os clientes.

Pare de usar essas "pubternal" APIs. Se você tiver dúvidas sobre APIs alternativas, abra um problema no repositório dotnet/aspnetcore .

Por exemplo, considere o seguinte código de buffer de solicitação HTTP em um projeto ASP.NET Core 2.2. O EnableRewind método de extensão existe no Microsoft.AspNetCore.Http.Internal namespace.

HttpContext.Request.EnableRewind();

Em um projeto ASP.NET Core 3.0, substitua a EnableRewind chamada por uma chamada para o EnableBuffering método de extensão. O recurso de buffer de solicitação funciona como no passado. EnableBuffering chama a API agora internal .

HttpContext.Request.EnableBuffering();

Categoria

ASP.NET Core

APIs afetadas

Todas as APIs nos Microsoft.AspNetCore.* namespaces e Microsoft.Extensions.* que têm um Internal segmento no nome do namespace. Por exemplo:

  • Microsoft.AspNetCore.Authentication.Internal
  • Microsoft.AspNetCore.Builder.Internal
  • Microsoft.AspNetCore.DataProtection.Cng.Internal
  • Microsoft.AspNetCore.DataProtection.Internal
  • Microsoft.AspNetCore.Hosting.Internal
  • Microsoft.AspNetCore.Http.Internal
  • Microsoft.AspNetCore.Mvc.Core.Infrastructure
  • Microsoft.AspNetCore.Mvc.Core.Internal
  • Microsoft.AspNetCore.Mvc.Cors.Internal
  • Microsoft.AspNetCore.Mvc.DataAnnotations.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Json.Internal
  • Microsoft.AspNetCore.Mvc.Formatters.Xml.Internal
  • Microsoft.AspNetCore.Mvc.Internal
  • Microsoft.AspNetCore.Mvc.ModelBinding.Internal
  • Microsoft.AspNetCore.Mvc.Razor.Internal
  • Microsoft.AspNetCore.Mvc.RazorPages.Internal
  • Microsoft.AspNetCore.Mvc.TagHelpers.Internal
  • Microsoft.AspNetCore.Mvc.ViewFeatures.Internal
  • Microsoft.AspNetCore.Rewrite.Internal
  • Microsoft.AspNetCore.Routing.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure
  • Microsoft.AspNetCore.Server.Kestrel.Https.Internal

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

A Google está a começar a encerrar o início de sessão do Google+ para aplicações já a 28 de janeiro de 2019.

Alterar a descrição

ASP.NET 4.x e ASP.NET Core têm usado as APIs de login do Google+ para autenticar usuários da Conta do Google em aplicativos da 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 mitigações e soluções fornecidas abaixo dão conta das mudanças estruturais. Os aplicativos devem verificar se os dados em si ainda satisfazem seus requisitos. Por exemplo, nomes, endereços de e-mail, links de perfil e fotos de perfil podem fornecer valores sutilmente diferentes do que antes.

Versão introduzida

Todas as versões. Esta alteração é externa ao ASP.NET Core.

Owin com ASP.NET Web Forms e MVC

Para Microsoft.Owin a versão 3.1.0 e posteriores, uma mitigação temporária é descrita aqui. Os aplicativos devem concluir os testes com a atenuação para verificar se há alterações no formato de dados. Há planos para lançar Microsoft.Owin a versão 4.0.1 com uma correção. Os aplicativos que usam qualquer versão anterior devem atualizar 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 ao ASP.NET Core 1.x. Os patches de pacote NuGet não são planejados porque o 1.x atingiu o status de fim de vida .

ASP.NET Núcleo 2.x

Para Microsoft.AspNetCore.Authentication.Google a versão 2.x, substitua a chamada existente pelo AddGoogle Startup.ConfigureServices seguinte código:

.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 2.1 e 2.2 de fevereiro incorporaram a reconfiguração anterior como o novo padrão. Nenhum patch está planejado para ASP.NET Core 2.0 desde que ele chegou ao fim da vida útil.

ASP.NET Núcleo 3.0

A atenuação dada para o ASP.NET Core 2.x também pode ser usada para o ASP.NET Core 3.0. Em futuras visualizações 3.0, o Microsoft.AspNetCore.Authentication.Google pacote pode ser removido. Em vez disso, os usuários seriam direcionados para Microsoft.AspNetCore.Authentication.OpenIdConnect . O código a seguir mostra como substituir AddGoogle por AddOpenIdConnect in Startup.ConfigureServices. Esta substituição pode ser usada com o ASP.NET Core 2.0 e posterior e pode ser adaptada para ASP.NET Core 1.x conforme necessário.

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

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 a descrição

Como parte de dotnet/aspnetcore#6504, a propriedade preterida Authentication em HttpContext foi removida. A Authentication propriedade 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 restantes classes/APIs não utilizadas relacionadas com a antiga pilha de autenticação do ASP.NET Core 1.x foram removidas em commit dotnet/aspnetcore@d7a7c65.

Para discussão, consulte dotnet/aspnetcore#6533.

Versão introduzida

3.0

Razão para a alteração

ASP.NET APIs Core 1.0 foram substituídas por métodos de extensão no Microsoft.AspNetCore.Authentication.AuthenticationHttpContextExtensions.

Consulte o guia de migração.

Categoria

ASP.NET Core

APIs afetadas

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

No ASP.NET Core 3.0, Newtonsoft.Json os tipos usados nas APIs de autenticação foram substituídos por System.Text.Json tipos. Exceto nos seguintes casos, o uso básico dos pacotes de autenticação permanece inalterado:

  • Classes derivadas dos provedores OAuth, como as de aspnet-contrib.
  • Implementações avançadas de manipulação de reivindicações.

Para obter mais informações, consulte dotnet/aspnetcore#7105. Para discussão, consulte dotnet/aspnetcore#7289.

Versão introduzida

3.0

Para implementações OAuth derivadas, a alteração mais comum é substituir JObject.Parse por JsonDocument.Parse na CreateTicketAsync substituição, conforme mostrado aqui. JsonDocument implementos IDisposable.

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

Categoria

ASP.NET Core

APIs afetadas

Autenticação: assinatura OAuthHandler ExchangeCodeAsync alterada

No ASP.NET Core 3.0, a assinatura do OAuthHandler.ExchangeCodeAsync foi alterada de:

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

Para:

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 code cordas e redirectUri foram passadas como argumentos separados.

Novo comportamento

Code e RedirectUri são propriedades que OAuthCodeExchangeContext podem ser definidas através do OAuthCodeExchangeContext construtor. O novo OAuthCodeExchangeContext tipo é o único argumento passado para OAuthHandler.ExchangeCodeAsync.

Razão para a alteração

Esta alteração permite que parâmetros adicionais sejam fornecidos de forma ininterrupta. Não há necessidade de criar novas ExchangeCodeAsync sobrecargas.

Construa um OAuthCodeExchangeContext com os valores apropriados redirectUri code. Uma AuthenticationProperties instância deve ser fornecida. Essa única OAuthCodeExchangeContext instância pode ser passada para em OAuthHandler.ExchangeCodeAsync vez de vários argumentos.

Categoria

ASP.NET Core

APIs afetadas

OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)

Autorização: sobrecarga AddAuthorization movida para assembly diferente

AddAuthorization Os principais métodos que costumavam residir em Microsoft.AspNetCore.Authorization foram renomeados para AddAuthorizationCore. Os métodos antigos AddAuthorization ainda existem, mas estão na Microsoft.AspNetCore.Authorization.Policy montagem. Os aplicativos que usam ambos os métodos não devem ter impacto. Observe que Microsoft.AspNetCore.Authorization.Policy agora é fornecido na estrutura compartilhada em vez de um pacote autônomo, conforme discutido em Estrutura compartilhada: assemblies removidos do Microsoft.AspNetCore.App.

Versão introduzida

3.0

Comportamento antigo

AddAuthorization métodos existiam em Microsoft.AspNetCore.Authorization.

Novo comportamento

AddAuthorization existem métodos em Microsoft.AspNetCore.Authorization.Policy. AddAuthorizationCore é o novo nome para os métodos antigos.

Razão para a alteração

AddAuthorization é um nome de método melhor para adicionar todos os serviços comuns necessários para autorização.

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

Categoria

ASP.NET Core

APIs afetadas

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

Autorização: IAllowAnonymous removido de AuthorizationFilterContext.Filters

A partir do ASP.NET Core 3.0, o MVC não adiciona AllowAnonymousFilters para atributos [AllowAnonymous] que foram descobertos em controladores e métodos de ação. Essa alteração é abordada localmente para derivados do AuthorizeAttribute, mas é uma mudança de rutura para IAsyncAuthorizationFilter e IAuthorizationFilter implementações. Essas implementações encapsuladas em um atributo [TypeFilter] são uma maneira popular e suportada de obter autorização fortemente tipada e baseada em atributos quando a configuração e a injeção de dependência são necessárias.

Versão introduzida

3.0

Comportamento antigo

IAllowAnonymous apareceu na coleção AuthorizationFilterContext.Filters . O teste da presença da interface foi uma abordagem válida para substituir ou desativar o filtro em métodos individuais do controlador.

Novo comportamento

IAllowAnonymous não aparece mais na AuthorizationFilterContext.Filters coleção. IAsyncAuthorizationFilter implementações que dependem do comportamento antigo normalmente causam respostas intermitentes HTTP 401 Não Autorizado ou HTTP 403 Proibido.

Razão para a alteração

Uma nova estratégia de roteamento de endpoint foi introduzida no ASP.NET Core 3.0.

Pesquise os metadados do ponto de extremidade para IAllowAnonymous. Por exemplo:

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

Um exemplo dessa técnica é visto neste método HasAllowAnonymous.

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

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

No ASP.NET Core 3.0, um novo GetFallbackPolicyAsync método foi adicionado ao IAuthorizationPolicyProvider. Essa política de fallback é usada pelo middleware de autorização quando nenhuma política é especificada.

Para obter mais informações, consulte dotnet/aspnetcore#9759.

Versão introduzida

3.0

Comportamento antigo

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

Novo comportamento

Implementações de IAuthorizationPolicyProvider requerem um GetFallbackPolicyAsync método.

Razão para a alteração

Um novo método era necessário para o novo AuthorizationMiddleware usar quando nenhuma política é especificada.

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

Categoria

ASP.NET Core

APIs afetadas

Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider

Cache: propriedade CompactOnMemoryPressure removida

A versão ASP.NET Core 3.0 removeu as APIs MemoryCacheOptions obsoletas.

Alterar a descrição

Esta alteração é uma continuação do aspnet/Caching#221. Para discussão, consulte dotnet/extensions#1062.

Versão introduzida

3.0

Comportamento antigo

MemoryCacheOptions.CompactOnMemoryPressure propriedade estava disponível.

Novo comportamento

A MemoryCacheOptions.CompactOnMemoryPressure propriedade foi removida.

Razão para a alteração

A compactação automática do cache causou problemas. Para evitar um comportamento inesperado, o cache só deve ser compactado quando necessário.

Para compactar o cache, faça downcast e chame MemoryCache Compact quando necessário.

Categoria

ASP.NET Core

APIs afetadas

MemoryCacheOptions.CompactOnMemoryPressure

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

O Microsoft.Extensions.Caching.SqlServer pacote usará o novo Microsoft.Data.SqlClient pacote em vez do System.Data.SqlClient pacote. Esta alteração pode causar ligeiras alterações comportamentais. Para obter mais informações, consulte Apresentando o novo Microsoft.Data.SqlClient.

Versão introduzida

3.0

Comportamento antigo

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

Novo comportamento

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

Razão para a alteração

Microsoft.Data.SqlClient é um novo pacote construído a partir do System.Data.SqlClient. É onde todo o trabalho de novos recursos será feito a partir de agora.

Os clientes não precisam se preocupar com essa alteração de quebra, a menos que estejam usando tipos retornados Microsoft.Extensions.Caching.SqlServer pelo pacote e convertendo-os em System.Data.SqlClient tipos. Por exemplo, se alguém estivesse convertendo um DbConnection para o tipo SqlConnection antigo, precisaria alterar a conversão para o novo Microsoft.Data.SqlClient.SqlConnection tipo.

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

Caching: os tipos "pubternal" do ResponseCaching foram alterados para internos

No ASP.NET Core 3.0, os tipos "pubternais" foram ResponseCaching alterados para internal.

Além disso, implementações padrão de IResponseCachingPolicyProvider e IResponseCachingKeyProvider não são mais adicionadas aos serviços como parte do AddResponseCaching método.

Alterar a descrição

No ASP.NET Core, os tipos "pubternal" são declarados como public mas residem em um namespace sufixo com .Internal. Embora esses tipos sejam públicos, eles não têm política de suporte e estão sujeitos a alterações de rutura. Infelizmente, o uso acidental desses tipos tem sido comum, resultando em alterações de quebra nesses projetos e limitando a capacidade de manter a estrutura.

Versão introduzida

3.0

Comportamento antigo

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

Novo comportamento

Estes tipos são agora internal.

Razão para a alteração

O internal âmbito de aplicação reflete melhor a política não apoiada.

Copie os tipos usados pelo seu aplicativo ou biblioteca.

Categoria

ASP.NET Core

APIs afetadas

Proteção de dados: DataProtection.Blobs usa novas APIs de armazenamento do Azure

Azure.Extensions.AspNetCore.DataProtection.Blobsdepende das bibliotecas de Armazenamento do Azure. Essas bibliotecas renomearam seus assemblies, pacotes e namespaces. A partir do ASP.NET Core 3.0, Azure.Extensions.AspNetCore.DataProtection.Blobs usa as novas Azure.Storage.APIs e pacotes prefixados.

Para perguntas sobre as APIs de Armazenamento do Azure, use https://github.com/Azure/azure-storage-net. Para discussão sobre esta questão, consulte dotnet/aspnetcore#19570.

Versão introduzida

3.0

Comportamento antigo

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

Novo comportamento

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

Razão para a alteração

Essa alteração permite Azure.Extensions.AspNetCore.DataProtection.Blobs migrar para os pacotes de Armazenamento do Azure recomendados.

Se você ainda precisar usar as APIs de Armazenamento do Azure mais antigas com o ASP.NET Core 3.0, adicione uma dependência direta ao pacote WindowsAzure.Storage ou Microsoft.Azure.Storage. Este pacote pode ser instalado junto com as novas Azure.Storage APIs.

Em muitos casos, a atualização envolve apenas a alteração das using instruções para usar os novos namespaces:

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

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

Hospedagem: AspNetCoreModule V1 removido do Windows Hosting Bundle

A partir do ASP.NET Core 3.0, o Windows Hosting Bundle não conterá AspNetCoreModule (ANCM) V1.

O ANCM V2 é compatível com versões anteriores do ANCM OutOfProcess e é recomendado para uso com aplicativos ASP.NET Core 3.0.

Para discussão, consulte dotnet/aspnetcore#7095.

Versão introduzida

3.0

Comportamento antigo

ANCM V1 está incluído no Windows Hosting Bundle.

Novo comportamento

ANCM V1 não está incluído no Windows Hosting Bundle.

Razão para a alteração

O ANCM V2 é compatível com versões anteriores do ANCM OutOfProcess e é recomendado para uso com aplicativos ASP.NET Core 3.0.

Use o ANCM V2 com aplicativos ASP.NET Core 3.0.

Se o ANCM V1 for necessário, ele pode ser instalado usando o ASP.NET Core 2.1 ou 2.2 Windows Hosting Bundle.

Essa alteração interromperá ASP.NET aplicativos Core 3.0 que:

  • Optou explicitamente por usar ANCM V1 com <AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>.
  • Tenha um arquivo web.config personalizado com <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />o .

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

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

Os únicos tipos que o host genérico suporta para Startup injeção de construtor de classe são IHostEnvironment, IWebHostEnvironmente IConfiguration. As aplicações que utilizam WebHost não são afetadas.

Alterar a descrição

Antes do ASP.NET Core 3.0, a Startup injeção do construtor podia ser usada para tipos arbitrários no construtor da classe. No ASP.NET Core 3.0, a pilha da Web foi recolocada na biblioteca de host genérica. Você pode ver a alteração no arquivo de Program.cs dos modelos:

ASP.NET Core 2.x:

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

ASP.NET Core 3.0:

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

Host usa um contêiner de injeção de dependência (DI) para criar o aplicativo. WebHost usa dois contêineres: um para o host e outro para o aplicativo. Como resultado, o Startup construtor não suporta mais a injeção de serviço personalizado. Apenas IHostEnvironment, IWebHostEnvironmente IConfiguration pode ser injetado. Essa alteração evita problemas de DI, como a criação duplicada de um serviço singleton.

Versão introduzida

3.0

Razão para a alteração

Essa alteração é uma consequência da replataforma da pilha da Web na biblioteca de host genérica.

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

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

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

Hospedagem: redirecionamento HTTPS habilitado para aplicativos fora de processo do IIS

A versão 13.0.19218.0 do ASP.NET Core Module (ANCM) para hospedagem via IIS fora do processo habilita um recurso de redirecionamento HTTPS existente para aplicativos ASP.NET Core 3.0 e 2.2.

Para discussão, consulte dotnet/AspNetCore#15243.

Versão introduzida

3.0

Comportamento antigo

O modelo de projeto ASP.NET Core 2.1 introduziu pela primeira vez o suporte para métodos de middleware HTTPS como UseHttpsRedirection e UseHsts. Habilitar o redirecionamento HTTPS exigiu a adição de configuração, já que os aplicativos em desenvolvimento não usam a porta padrão 443. O HSTS (HTTP Strict Transport Security) estará ativo somente se a solicitação já estiver usando HTTPS. Localhost é ignorado por padrão.

Novo comportamento

No ASP.NET Core 3.0, o cenário HTTPS do IIS foi aprimorado. Com o aprimoramento, um aplicativo pode descobrir as portas HTTPS do servidor e fazer UseHttpsRedirection o trabalho por padrão. O componente em processo realizou a descoberta de porta com o IServerAddresses recurso, que afeta apenas os aplicativos ASP.NET Core 3.0 porque a biblioteca em processo é versionada com a estrutura. O componente fora do processo foi alterado para adicionar automaticamente a variável de ASPNETCORE_HTTPS_PORT ambiente. Essa alteração afetou os aplicativos ASP.NET Core 2.2 e 3.0 porque o componente fora de processo é compartilhado globalmente. ASP.NET aplicativos Core 2.1 não são afetados porque usam uma versão anterior do ANCM por padrão.

O comportamento anterior foi modificado no ASP.NET Core 3.0.1 e 3.1.0 Preview 3 para reverter as alterações de comportamento no ASP.NET Core 2.x. Essas alterações afetam apenas os aplicativos fora de processo do IIS.

Como detalhado acima, a instalação do ASP.NET Core 3.0.0 teve o efeito colateral de também ativar o UseHttpsRedirection middleware em aplicativos ASP.NET Core 2.x. Uma alteração foi feita no ANCM no ASP.NET Core 3.0.1 e 3.1.0 Preview 3 de modo que instalá-los não tem mais esse efeito em aplicativos ASP.NET Core 2.x. A ASPNETCORE_HTTPS_PORT variável de ambiente que o ANCM preencheu no ASP.NET Core 3.0.0 foi alterada para ASPNETCORE_ANCM_HTTPS_PORT no ASP.NET Core 3.0.1 e 3.1.0 Preview 3. UseHttpsRedirection também foi atualizado nessas versões para entender as variáveis novas e antigas. ASP.NET Core 2.x não será atualizado. Como resultado, ele reverte para o comportamento anterior de ser desativado por padrão.

Razão para a alteração

Funcionalidade melhorada do ASP.NET Core 3.0.

Nenhuma ação é necessária se você quiser que todos os clientes usem HTTPS. Para permitir que alguns clientes usem HTTP, execute uma das seguintes etapas:

  • Remova as chamadas de e UseHsts para UseHttpsRedirection o Startup.Configure método do seu projeto e reimplante o aplicativo.

  • No arquivo web.config , defina a ASPNETCORE_HTTPS_PORT variável de ambiente como uma cadeia de caracteres vazia. Essa alteração pode ocorrer diretamente no servidor sem reimplantar o aplicativo. Por exemplo:

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

UseHttpsRedirection ainda pode ser:

  • Ativado manualmente no ASP.NET Core 2.x definindo a ASPNETCORE_HTTPS_PORT variável de ambiente para o número de porta apropriado (443 na maioria dos cenários de produção).
  • Desativada no ASP.NET Core 3.x definindo ASPNETCORE_ANCM_HTTPS_PORT com um valor de string vazio. Esse valor é definido da mesma forma que o exemplo anterior ASPNETCORE_HTTPS_PORT .

As máquinas que executam aplicativos ASP.NET Core 3.0.0 devem instalar o tempo de execução do ASP.NET Core 3.0.1 antes de instalar o ANCM do ASP.NET Core 3.1.0 Preview 3. Isso garante que UseHttpsRedirection continue a operar conforme o esperado para os aplicativos ASP.NET Core 3.0.

No Serviço de Aplicativo do Azure, o ANCM é implantado em um cronograma separado do tempo de execução devido à sua natureza global. O ANCM foi implantado no Azure com essas alterações depois que ASP.NET Core 3.0.1 e 3.1.0 foram implantados.

Categoria

ASP.NET Core

APIs afetadas

HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)

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

Foram introduzidos novos tipos para substituir os existentes IHostingEnvironment e IApplicationLifetime os tipos.

Versão introduzida

3.0

Comportamento antigo

Havia dois tipos diferentes IHostingEnvironment de IApplicationLifetime Microsoft.Extensions.Hosting e Microsoft.AspNetCore.Hosting.

Novo comportamento

Os tipos antigos foram marcados como obsoletos e substituídos por novos tipos.

Razão para a alteração

Quando Microsoft.Extensions.Hosting foi introduzido no ASP.NET Core 2.1, alguns tipos como IHostingEnvironment e IApplicationLifetime foram copiados do Microsoft.AspNetCore.Hosting. Algumas alterações ASP.NET Core 3.0 fazem com que os aplicativos incluam os Microsoft.Extensions.Hosting namespaces e Microsoft.AspNetCore.Hosting . Qualquer uso desses tipos duplicados causa um erro de compilador de "referência ambígua" quando ambos os namespaces são referenciados.

Substituiu todos os usos dos tipos antigos pelos tipos recém-introduzidos, conforme abaixo:

Tipos obsoletos (aviso):

Novos tipos:

Os métodos new IHostEnvironment IsDevelopment e IsProduction extension estão no Microsoft.Extensions.Hosting namespace. Esse namespace pode precisar ser adicionado ao seu projeto.

Categoria

ASP.NET Core

APIs afetadas

Hospedagem: ObjectPoolProvider removido das dependências do WebHostBuilder

Como parte de tornar o ASP.NET Core mais pago pelo jogo, o ObjectPoolProvider foi removido do conjunto principal de dependências. Componentes específicos que ObjectPoolProvider dependem agora adicioná-lo eles mesmos.

Para discussão, consulte dotnet/aspnetcore#5944.

Versão introduzida

3.0

Comportamento antigo

WebHostBuilder fornece ObjectPoolProvider por padrão no contêiner DI.

Novo comportamento

WebHostBuilder não fornece ObjectPoolProvider mais por padrão no contêiner DI.

Razão para a alteração

Esta mudança foi feita para fazer com que ASP.NET Core pagasse mais pelo jogo.

Se o componente exigir ObjectPoolProvidero , ele precisará ser adicionado às suas dependências por meio do IServiceCollection.

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

HTTP: Extensibilidade DefaultHttpContext removida

Como parte das melhorias de desempenho do ASP.NET Core 3.0, a extensibilidade do DefaultHttpContext foi removida. A classe é agora sealed. Para obter mais informações, consulte dotnet/aspnetcore#6504.

Se os testes de unidade usarem Mock<DefaultHttpContext>, use Mock<HttpContext> ou new DefaultHttpContext() em vez disso.

Para discussão, consulte dotnet/aspnetcore#6534.

Versão introduzida

3.0

Comportamento antigo

As classes podem derivar de DefaultHttpContext.

Novo comportamento

As classes não podem derivar de DefaultHttpContext.

Razão para a alteração

A extensibilidade foi fornecida inicialmente para permitir o HttpContextagrupamento do , mas introduziu complexidade desnecessária e impediu outras otimizações.

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

HTTP: Constantes HeaderNames alteradas para somente leitura estática

A partir do ASP.NET Core 3.0 Preview 5, os campos foram Microsoft.Net.Http.Headers.HeaderNames alterados de const para static readonly.

Para discussão, consulte dotnet/aspnetcore#9514.

Versão introduzida

3.0

Comportamento antigo

Estes campos costumavam ser const.

Novo comportamento

Estes campos são agora static readonly.

Razão para a alteração

A mudança:

  • Impede que os valores sejam incorporados através dos limites de montagem, permitindo correções de valor conforme necessário.
  • Permite verificações de igualdade de referência mais rápidas.

Recompile contra 3.0. O código-fonte que utiliza estes campos das seguintes formas já não o pode fazer:

  • Como um argumento de atributo
  • Como um case em uma switch declaração
  • Ao definir outro const

Para contornar a alteração de quebra, alterne para usar constantes de nome de cabeçalho autodefinidas ou literais de cadeia de caracteres.

Categoria

ASP.NET Core

APIs afetadas

Microsoft.Net.Http.Headers.HeaderNames

HTTP: Alterações na infraestrutura do corpo de resposta

A infraestrutura que suporta um corpo de resposta HTTP foi alterada. Se você estiver usando HttpResponse diretamente, não precisará fazer nenhuma alteração no código. Leia mais se você estiver empacotando, substituindo HttpResponse.Body ou acessando HttpContext.Featureso .

Versão introduzida

3.0

Comportamento antigo

Havia três APIs associadas ao corpo de resposta HTTP:

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

Novo comportamento

Se você substituir HttpResponse.Bodyo , ele substituirá o inteiro IHttpResponseBodyFeature por um wrapper em torno de seu fluxo determinado usando StreamResponseBodyFeature para fornecer implementações padrão para todas as APIs esperadas. A configuração do fluxo original reverte essa alteração.

Razão para a alteração

A motivação é combinar as APIs do corpo de resposta em uma única interface de novo recurso.

Use IHttpResponseBodyFeature onde você estava usando IHttpResponseFeature.Bodyanteriormente , IHttpSendFileFeature, ou IHttpBufferingFeature.

Categoria

ASP.NET Core

APIs afetadas

SameSite é uma opção para cookies que pode ajudar a mitigar alguns ataques de falsificação de solicitação entre sites (CSRF). Quando essa opção foi inicialmente introduzida, padrões inconsistentes foram usados em várias APIs principais ASP.NET. A inconsistência levou a resultados confusos. A partir do ASP.NET Core 3.0, esses padrões estão melhor alinhados. Você deve optar por esse recurso por componente.

Versão introduzida

3.0

Comportamento antigo

Semelhante ASP.NET APIs Core usavam valores padrão SameSiteMode diferentes. Um exemplo da inconsistência é visto em HttpResponse.Cookies.Append(String, String) e HttpResponse.Cookies.Append(String, String, CookieOptions), que não foram para SameSiteMode.None e SameSiteMode.Lax, respectivamente.

Novo comportamento

Todas as APIs afetadas usam como SameSiteMode.Nonepadrão .

Razão para a alteração

O valor padrão foi alterado para criar SameSite um recurso de aceitação.

Cada componente que emite cookies precisa decidir se SameSite é apropriado para seus cenários. Revise o uso das APIs afetadas e reconfigure SameSite conforme necessário.

Categoria

ASP.NET Core

APIs afetadas

HTTP: E/S síncrona desabilitada em todos os servidores

A partir do ASP.NET Core 3.0, as operações de servidor síncrono são desabilitadas por padrão.

Alterar a 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.Writee Stream.Flush. Essas APIs têm sido uma fonte de fome de threads e travamentos de aplicativos. 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

Espere 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 AllowSynchronousIO opção que controla esse comportamento e o padrão para todos eles agora falseé .

O comportamento também pode ser substituído por solicitação como uma atenuação temporária. Por exemplo:

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 DisposeAsync API.

Para discussão, consulte dotnet/aspnetcore#7644.

Versão introduzida

3.0

Comportamento antigo

HttpRequest.Body.Read, HttpResponse.Body.Writee Stream.Flush foram permitidos por defeito.

Novo comportamento

Essas APIs síncronas não são permitidas por padrão:

Espere 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.

Razão para a alteração

Essas APIs síncronas têm sido uma fonte de fome de threads e travamentos de aplicativos. A partir do ASP.NET Core 3.0 Preview 3, as operações síncronas são desabilitadas por padrão.

Use as versões assíncronas dos métodos. O comportamento também pode ser substituído por solicitação como uma atenuação temporária.

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

Categoria

ASP.NET Core

APIs afetadas

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

Razão para a alteração

Essa mudança foi resultado da adoção do recurso de ativos da Web estáticos.

Chame IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder) em vez da sobrecarga que leva dois argumentos. Se você estiver usando o Bootstrap 3, adicione também a seguinte linha a um <PropertyGroup> elemento no arquivo de projeto:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Categoria

ASP.NET Core

APIs afetadas

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)

Identidade: Versão padrão do Bootstrap da interface do usuário alterada

A partir do ASP.NET Core 3.0, a interface do usuário do Identity assume como padrão o uso da versão 4 do Bootstrap.

Versão introduzida

3.0

Comportamento antigo

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

Novo comportamento

A services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(); chamada de método é a mesma que services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);

Razão para a alteração

O Bootstrap 4 foi lançado durante ASP.NET período de tempo do Core 3.0.

Você será afetado por essa alteração se usar a interface do usuário de identidade padrão e a tiver adicionado, Startup.ConfigureServices conforme mostrado no exemplo a seguir:

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

Efetue uma das seguintes ações:

  • Migre seu aplicativo para usar o Bootstrap 4 usando o guia de migração.

  • Atualização Startup.ConfigureServices para impor o uso do Bootstrap 3. Por exemplo:

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

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

Identidade: SignInAsync lança exceção para identidade não autenticada

Por padrão, SignInAsync lança uma exceção para entidades / identidades em que IsAuthenticated é false.

Versão introduzida

3.0

Comportamento antigo

SignInAsync aceita quaisquer princípios / identidades, incluindo identidades em que IsAuthenticated é false.

Novo comportamento

Por padrão, SignInAsync lança uma exceção para entidades / identidades em que IsAuthenticated é false. Há um novo sinalizador para suprimir esse comportamento, mas o comportamento padrão foi alterado.

Razão para a alteração

O comportamento antigo era problemático porque, por padrão, esses princípios eram rejeitados pela [Authorize] / RequireAuthenticatedUser().

No ASP.NET Core 3.0 Preview 6, há um RequireAuthenticatedSignIn sinalizador que AuthenticationOptions é true por padrão. Defina esse sinalizador como false para restaurar o comportamento antigo.

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

Identity: SignInManager construtor aceita novo parâmetro

A partir do ASP.NET Core 3.0, um novo IUserConfirmation<TUser> parâmetro foi adicionado ao SignInManager construtor. Para obter mais informações, consulte dotnet/aspnetcore#8356.

Versão introduzida

3.0

Razão para a alteração

A motivação para a mudança foi adicionar suporte para novos fluxos de e-mail / confirmação na Identidade.

Se estiver construindo manualmente um SignInManager, forneça uma implementação ou IUserConfirmation pegue uma da injeção de dependência para fornecer.

Categoria

ASP.NET Core

APIs afetadas

SignInManager<TUser>

Identidade: a interface do usuário usa o recurso de ativos da Web estáticos

ASP.NET Core 3.0 introduziu um recurso estático de ativos da Web e a Identity UI o adotou.

Alterar a descrição

Como resultado da adoção da interface do usuário de identidade pelo recurso de ativos estáticos da Web:

  • A seleção da estrutura é realizada usando a IdentityUIFrameworkVersion propriedade em seu arquivo de projeto.
  • O Bootstrap 4 é a estrutura de interface do usuário padrão para a interface do usuário do Identity. O Bootstrap 3 chegou ao fim da vida útil e você deve considerar a migração para uma versão suportada.

Versão introduzida

3.0

Comportamento antigo

A estrutura de interface do usuário padrão para a interface do usuário de identidade era o Bootstrap 3. A estrutura da interface do usuário pode ser configurada usando um parâmetro para a chamada do AddDefaultUI método .Startup.ConfigureServices

Novo comportamento

A estrutura de interface do usuário padrão para Identity UI é Bootstrap 4. A estrutura da interface do usuário deve ser configurada em seu arquivo de projeto, em vez de na chamada de AddDefaultUI método.

Razão para a alteração

A adoção do recurso de ativos da Web estáticos exigiu que a configuração da estrutura da interface do usuário fosse movida para o MSBuild. A decisão sobre qual estrutura incorporar é uma decisão de tempo de construção, não uma decisão de tempo de execução.

Revise a interface do usuário do site para garantir que os novos componentes do Bootstrap 4 sejam compatíveis. Se necessário, use a IdentityUIFrameworkVersion propriedade MSBuild para reverter para o Bootstrap 3. Adicione a propriedade a um <PropertyGroup> elemento em seu arquivo de projeto:

<IdentityUIFrameworkVersion>Bootstrap3</IdentityUIFrameworkVersion>

Categoria

ASP.NET Core

APIs afetadas

IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)

Peneireiro-das-torres: Adaptadores de ligação removidos

Como parte do movimento para mover APIs "pubternal" para public, o conceito de um IConnectionAdapter foi removido do Kestrel. Os adaptadores de conexão estão sendo substituídos por middleware de conexão (semelhante ao middleware HTTP no pipeline ASP.NET Core, mas para conexões de nível inferior). HTTPS e log de conexão foram movidos de adaptadores de conexão para middleware de conexão. Esses métodos de extensão devem continuar a funcionar perfeitamente, mas os detalhes da implementação mudaram.

Para obter mais informações, consulte dotnet/aspnetcore#11412. Para discussão, consulte dotnet/aspnetcore#11475.

Versão introduzida

3.0

Comportamento antigo

Os componentes de extensibilidade do peneireiro-das-torres foram criados utilizando IConnectionAdapter.

Novo comportamento

Os componentes de extensibilidade do peneireiro-das-torres são criados como middleware.

Razão para a alteração

Esta alteração destina-se a fornecer uma arquitetura de extensibilidade mais flexível.

Converta todas as implementações de para usar o novo padrão de IConnectionAdapter middleware, conforme mostrado aqui.

Categoria

ASP.NET Core

APIs afetadas

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

Kestrel: Montagem HTTPS vazia removida

O conjunto Microsoft.AspNetCore.Server.Kestrel.Https foi removido.

Versão introduzida

3.0

Razão para a alteração

No ASP.NET Core 2.1, o conteúdo do foi movido Microsoft.AspNetCore.Server.Kestrel.Https para Microsoft.AspNetCore.Server.Kestrel.Core. Essa alteração foi feita de forma ininterrupta usando [TypeForwardedTo] atributos.

  • As bibliotecas que fazem referência a Microsoft.AspNetCore.Server.Kestrel.Https 2.0 devem atualizar todas as dependências do ASP.NET Core para 2.1 ou posterior. Caso contrário, eles podem quebrar quando carregados em um aplicativo ASP.NET Core 3.0.
  • Os aplicativos e bibliotecas direcionados ao ASP.NET Core 2.1 e posterior devem remover quaisquer referências diretas Microsoft.AspNetCore.Server.Kestrel.Https ao pacote NuGet.

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

Peneireiro-das-torres: Solicitar cabeçalhos de reboque movidos para nova coleção

Em versões anteriores, o Kestrel adicionava cabeçalhos de trailer em partes HTTP/1.1 à coleção de cabeçalhos de solicitação quando o corpo da solicitação era lido até o final. Esse comportamento causou preocupações sobre a ambiguidade entre cabeçalhos e trailers. Foi tomada a decisão de transferir 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 assim que todo o corpo da solicitação for lido.

Os trailers HTTP/2 estão disponíveis assim que 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 estão sempre disponíveis se você ler o corpo da solicitação até o final. Os reboques marcam o fim da carroçaria.

Versão introduzida

3.0

Comportamento antigo

Os cabeçalhos do trailer de solicitação seriam adicionados à HttpRequest.Headers coleção.

Novo comportamento

Os cabeçalhos de trailer de solicitação não estão presentes na HttpRequest.Headers coleção. Use os seguintes métodos de extensão para HttpRequest acessá-los:

  • GetDeclaredTrailers() - Obtém o cabeçalho de solicitação "Trailer" que lista quais trailers esperar após o corpo.
  • SupportsTrailers() - Indica se o pedido suporta a receção de cabeçalhos de reboque.
  • CheckTrailersAvailable() - Determina se a solicitação suporta trailers e se eles estão disponíveis para leitura.
  • GetTrailer(string trailerName) - Obtém o cabeçalho à direita solicitado da resposta.

Razão para a alteração

Os trailers são uma característica fundamental em cenários como o gRPC. Mesclar os trailers para solicitar cabeçalhos foi confuso para os usuários.

Use os métodos de extensão relacionados ao reboque para HttpRequest acessar os reboques.

Categoria

ASP.NET Core

APIs afetadas

HttpRequest.Headers

Peneireiro-das-torres: Retiradas e tornadas públicas as abstrações de transporte

Como parte do afastamento das APIs "pubternais", as APIs da camada de transporte Kestrel são expostas como uma interface pública na Microsoft.AspNetCore.Connections.Abstractions biblioteca.

Versão introduzida

3.0

Comportamento antigo

  • Abstrações relacionadas ao transporte estavam disponíveis na Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions biblioteca.
  • A ListenOptions.NoDelay propriedade estava disponível.

Novo comportamento

  • A IConnectionListener interface foi introduzida Microsoft.AspNetCore.Connections.Abstractions na biblioteca para expor a funcionalidade mais usada da ...Transport.Abstractions biblioteca.
  • O NoDelay está agora disponível em opções de transporte (LibuvTransportOptions e SocketTransportOptions).
  • SchedulingMode já não está disponível.

Razão para a alteração

ASP.NET Core 3.0 se afastou das APIs "pubternais".

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

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 de localização, especialmente ao criar sua própria IStringLocalizer implementação. Esses itens dão ao usuário a impressão de que uma IStringLocalizer instância é "por idioma, por recurso". Na realidade, as instâncias devem ser apenas "por recurso". A língua pesquisada é determinada pelo momento da CultureInfo.CurrentUICulture execução. Para eliminar a fonte de confusão, as APIs foram marcadas como obsoletas no ASP.NET Core 3.0. As APIs serão removidas em uma versão futura.

Para contextualizar, consulte dotnet/aspnetcore#3324. Para discussão, consulte dotnet/aspnetcore#7756.

Versão introduzida

3.0

Comportamento antigo

Os métodos não foram marcados como Obsolete.

Novo comportamento

Os métodos são marcados Obsoletecomo .

Razão para a alteração

As APIs representaram um caso de uso que não é recomendado. Houve confusão sobre o design da localização.

A recomendação é usar ResourceManagerStringLocalizer em vez disso. 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

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

Logging: classe DebugLogger tornada interna

Antes do ASP.NET Core 3.0, DebugLoggero modificador publicde acesso do era . No ASP.NET Core 3.0, o modificador de acesso mudou para internal.

Versão introduzida

3.0

Razão para a alteração

A alteração está a ser feita para:

  • Impor consistência com outras implementações do registrador, como ConsoleLogger.
  • Reduza a superfície da API.

Use o método de extensão para habilitar o AddDebug ILoggingBuilder log de depuração. DebugLoggerProvider também public ainda está 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 de nomes de ação do controlador

Como parte do endereçamento dotnet/aspnetcore#4849, ASP.NET Core MVC corta 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 links.

Versão introduzida

3.0

Comportamento antigo

Considere o seguinte ASP.NET controlador MVC principal:

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

A ação é encaminhada via Product/ListAsync. A geração de links requer a especificação do sufixo Async . Por exemplo:

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

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

Essa alteração não afeta os nomes especificados usando o [ActionName] atributo. O novo comportamento pode ser desativado definindo MvcOptions.SuppressAsyncSuffixInActionNames em false Startup.ConfigureServices:

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

Razão para a alteração

Por convenção, os métodos .NET assíncronos são sufixados com Async. No entanto, quando um método define uma ação MVC, é indesejável usar o sufixo Async .

Se seu aplicativo depender de ações MVC preservando o sufixo do Async nome, escolha uma das seguintes atenuações:

  • Use o [ActionName] atributo para preservar o nome original.
  • Desative totalmente a renomeação definindo MvcOptions.SuppressAsyncSuffixInActionNames como false em Startup.ConfigureServices:
services.AddMvc(options =>
{
   options.SuppressAsyncSuffixInActionNames = false;
});

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

MVC: JsonResult movido para Microsoft.AspNetCore.Mvc.Core

JsonResult mudou-se para a Microsoft.AspNetCore.Mvc.Core assembleia. Este tipo costumava ser definido em Microsoft.AspNetCore.Mvc.Formatters.Json. Um atributo de nível de assembly [TypeForwardedTo] foi adicionado para Microsoft.AspNetCore.Mvc.Formatters.Json resolver esse problema para a maioria dos usuários. Os aplicativos que usam bibliotecas de terceiros podem encontrar problemas.

Versão introduzida

3.0 Pré-visualização 6

Comportamento antigo

Um aplicativo que usa uma biblioteca baseada em 2.2 é compilado com êxito.

Novo comportamento

Um aplicativo que usa uma biblioteca baseada em 2.2 falha na compilação. É fornecido um erro que contém uma variação do seguinte texto:

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

Para obter um exemplo desse problema, consulte dotnet/aspnetcore#7220.

Razão para a alteração

Alterações no nível da plataforma na composição do ASP.NET Core, conforme descrito em aspnet/Announcements#325.

As bibliotecas compiladas com base na versão 2.2 do podem ter de Microsoft.AspNetCore.Mvc.Formatters.Json ser recompiladas para resolver o problema de todos os consumidores. Se for afetado, entre em contato com o autor da biblioteca. Solicite a recompilação da biblioteca para direcionar ASP.NET Core 3.0.

Categoria

ASP.NET Core

APIs afetadas

Microsoft.AspNetCore.Mvc.JsonResult

MVC: Ferramenta de pré-compilação preterida

No ASP.NET Core 1.1, o Microsoft.AspNetCore.Mvc.Razor.ViewCompilation pacote (ferramenta de pré-compilação MVC) foi introduzido para adicionar suporte para compilação em 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 e compilação em tempo de publicação de arquivos Razor. O SDK verifica a correção dos arquivos .cshtml no momento da compilação enquanto 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 da era ASP.NET Core 1.1 foi removida. As versões anteriores do pacote continuarão recebendo bugs importantes e correções de segurança na versão do patch.

Versão introduzida

3.0

Comportamento antigo

O Microsoft.AspNetCore.Mvc.Razor.ViewCompilation pacote foi usado para pré-compilar visualizações do MVC Razor.

Novo comportamento

O SDK do Razor suporta nativamente essa funcionalidade. O Microsoft.AspNetCore.Mvc.Razor.ViewCompilation pacote não é mais atualizado.

Razão para a alteração

O Razor SDK fornece mais funcionalidade e verifica a correção dos arquivos .cshtml no momento da compilação. O SDK também melhora o tempo de inicialização do aplicativo.

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 bugs ou recursos ausentes impedirem a migração para o SDK do Razor, abra um problema em dotnet/aspnetcore.

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

MVC: Tipos "pubternais" alterados para internos

No ASP.NET Core 3.0, todos os tipos "pubternais" no MVC foram atualizados para estarem public em um namespace suportado ou internal conforme apropriado.

Alterar a descrição

No ASP.NET Core, os tipos "pubternal" são declarados como public mas residem em um .Internalnamespace -sufixo. Embora esses tipos sejam public, eles não têm política de suporte e estão sujeitos a alterações de quebra. Infelizmente, o uso acidental desses tipos tem sido comum, resultando em alterações de quebra nesses projetos e limitando a capacidade de manter a estrutura.

Versão introduzida

3.0

Comportamento antigo

Alguns tipos no MVC estavam public apenas em um .Internal namespace. Esses tipos não tinham política de suporte e estavam sujeitos a alterações de rutura.

Novo comportamento

Todos esses tipos são atualizados para estarem public em um namespace suportado ou marcados como internal.

Razão para a alteração

O uso acidental dos tipos "pubternal" tem sido comum, resultando em mudanças significativas nesses projetos e limitando a capacidade de manter a estrutura.

Se você estiver usando tipos que se tornaram verdadeiros public e foram movidos para um novo namespace suportado, atualize suas referências para corresponder aos novos namespaces.

Se você estiver usando tipos que ficaram marcados como internal, precisará encontrar uma alternativa. Os tipos anteriormente "pubternais" nunca foram suportados para uso público. Se houver tipos específicos nesses namespaces que são críticos para seus aplicativos, registre um problema em dotnet/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: Correção de compatibilidade de API da Web removida

A partir do ASP.NET Core 3.0, o Microsoft.AspNetCore.Mvc.WebApiCompatShim pacote não está mais disponível.

Alterar a descrição

O Microsoft.AspNetCore.Mvc.WebApiCompatShim pacote (WebApiCompatShim) fornece compatibilidade parcial no ASP.NET Core com ASP.NET 4.x Web API 2 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 enviados nas versões recentes do ASP.NET Core. Tais recursos incluem geração melhorada de especificações de API aberta, tratamento de erros padronizado e geração de código de cliente. Para concentrar melhor os esforços da API na versão 3.0, WebApiCompatShim foi removido. Os aplicativos existentes que usam o WebApiCompatShim devem migrar para o modelo mais recente [ApiController] .

Versão introduzida

3.0

Razão para a alteração

O shim de compatibilidade da API Web era uma ferramenta de migração. Ele restringe o acesso do usuário a novas funcionalidades adicionadas no ASP.NET Core.

Remova o uso desse shim e migre diretamente para a funcionalidade semelhante no próprio ASP.NET Core.

Categoria

ASP.NET Core

APIs afetadas

Microsoft.AspNetCore.Mvc.WebApiCompatShim

Razor: API RazorTemplateEngine removida

A RazorTemplateEngine API foi removida e substituída por Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.

Para discussão, consulte GitHub issue dotnet/aspnetcore#25215.

Versão introduzida

3.0

Comportamento antigo

Um mecanismo de modelo pode ser criado e usado para analisar e gerar código para arquivos Razor.

Novo comportamento

RazorProjectEngine pode ser criado e fornecido o mesmo tipo de informação para RazorTemplateEngine analisar e gerar código para arquivos Razor. RazorProjectEngine também fornece níveis extras de configuração.

Razão para a alteração

RazorTemplateEngine estava demasiado ligada às implementações existentes. Esse acoplamento apertado levou a mais perguntas ao tentar configurar corretamente um pipeline de análise/geração do Razor.

Use RazorProjectEngine em vez de RazorTemplateEngine. Considere os exemplos a seguir.

Criar e configurar o RazorProjectEngine
RazorProjectEngine projectEngine =
    RazorProjectEngine.Create(RazorConfiguration.Default,
        RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
        builder =>
        {
            builder.ConfigureClass((document, classNode) =>
            {
                classNode.ClassName = "MyClassName";

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

            // More configuration can go here
        });
Gerar código para um arquivo Razor
RazorProjectItem item = projectEngine.FileSystem.GetItem(
    @"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
    FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);

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

Categoria

ASP.NET Core

APIs afetadas

  • RazorTemplateEngine
  • RazorTemplateEngineOptions

Razor: compilação de tempo de execução movida para um pacote

O suporte para compilação em tempo de execução de visualizações do Razor e Razor Pages foi movido para um pacote separado.

Versão introduzida

3.0

Comportamento antigo

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 Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions anteriormente para dar suporte à compilação em tempo de execução. As APIs agora estão disponíveis via Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation.MvcRazorRuntimeCompilationOptions.

  • RazorViewEngineOptions.FileProviders é agora MvcRazorRuntimeCompilationOptions.FileProviders
  • RazorViewEngineOptions.AdditionalCompilationReferences é agora 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 fazendo referência ao Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation pacote.

Razão para a alteração

Essa mudança foi necessária para remover a dependência da estrutura compartilhada do ASP.NET Core no Roslyn.

Os 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 Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation pacote.

  2. Atualize o método do Startup.ConfigureServices projeto para incluir uma chamada para AddRazorRuntimeCompilation. Por exemplo:

    services.AddMvc()
    .AddRazorRuntimeCompilation();

Categoria

ASP.NET Core

APIs afetadas

Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions

Estado da sessão: APIs obsoletas removidas

As APIs obsoletas para configurar cookies de sessão foram removidas. Para obter mais informações, consulte aspnet/Announcements#257.

Versão introduzida

3.0

Razão para a alteração

Essa alteração impõe consistência entre APIs para configurar recursos que usam cookies.

Migre o uso das APIs removidas para suas substituições mais recentes. Considere o seguinte exemplo em Startup.ConfigureServices:

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

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

Categoria

ASP.NET Core

APIs afetadas

Estrutura compartilhada: assemblies removidos do Microsoft.AspNetCore.App

A partir do ASP.NET Core 3.0, a estrutura compartilhada do ASP.NET Core (Microsoft.AspNetCore.App) contém apenas assemblies primários que são totalmente desenvolvidos, suportados e passíveis de manutenção pela Microsoft.

Alterar a descrição

Pense na mudança como a redefinição de limites para a "plataforma" ASP.NET Core. A estrutura compartilhada poderá ser criada por qualquer pessoa via 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 centralizada de patches e tempo de inicialização mais rápido.

Como parte da mudança, algumas mudanças de quebra notáveis são introduzidas no Microsoft.AspNetCore.App.

Versão introduzida

3.0

Comportamento antigo

Projetos referenciados Microsoft.AspNetCore.App através de um <PackageReference> elemento 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 <PackageReference> elemento no arquivo de projeto. O SDK do .NET Core oferece suporte a um novo elemento chamado <FrameworkReference>, que substitui o uso do <PackageReference>.

Para obter mais informações, consulte dotnet/aspnetcore#3612.

O Entity Framework Core é fornecido como pacotes NuGet. Essa alteração alinha o modelo de envio com todas as outras bibliotecas de acesso a dados no .NET. Ele fornece ao Entity Framework Core o caminho mais simples para continuar inovando enquanto oferece suporte às várias plataformas .NET. A mudança do Entity Framework Core para fora da estrutura compartilhada não tem impacto em seu status como uma biblioteca desenvolvida, suportada e passível de manutenção pela Microsoft. A política de suporte do .NET Core continua a cobri-lo.

Json.NET e o Entity Framework Core continuam a trabalhar com o ASP.NET Core. No entanto, não serão incluídos no quadro partilhado.

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.

Razão para a alteração

Essa alteração simplifica o consumo e Microsoft.AspNetCore.App reduz a duplicação entre pacotes NuGet e estruturas compartilhadas.

Para obter mais informações sobre a motivação para essa mudança, consulte esta postagem no blog.

A partir do ASP.NET Core 3.0, não é mais necessário que os projetos consumam assemblies como Microsoft.AspNetCore.App pacotes NuGet. Para simplificar a segmentação e o uso da estrutura compartilhada do ASP.NET Core, muitos pacotes NuGet enviados 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> to 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 via Microsoft.AspNetCore.App ASP.NET Core 2.x. Exceções notáveis incluem:

  • Microsoft.Extensions as bibliotecas que continuam a direcionar o .NET Standard estão disponíveis como pacotes NuGet (consulte https://github.com/dotnet/extensions).
  • APIs produzidas pela equipe ASP.NET Core que não fazem parte do Microsoft.AspNetCore.App. Por exemplo, os seguintes componentes estão disponíveis como pacotes NuGet:
  • Extensões para MVC que mantêm o suporte para Json.NET. Uma API é fornecida como um pacote NuGet para dar suporte ao uso de Json.NET e MVC. Consulte o guia de migração do ASP.NET Core para obter mais detalhes.
  • O cliente SignalR .NET continua a oferecer suporte ao .NET Standard e é fornecido como um pacote NuGet. Destina-se ao uso em muitos tempos de execução do .NET, como Xamarin e UWP.

Para obter mais informações, consulte Parar de produzir pacotes para assemblies de estrutura compartilhados na versão 3.0. Para discussão, consulte dotnet/aspnetcore#3757.

Categoria

ASP.NET Core

APIs afetadas

Estrutura compartilhada: Microsoft.AspNetCore.All removido

A partir do ASP.NET Core 3.0, o Microsoft.AspNetCore.All metapacote e a estrutura compartilhada correspondente Microsoft.AspNetCore.All não são mais produzidos. Este pacote está disponível no ASP.NET Core 2.2 e continuará a receber atualizações de manutenção no ASP.NET Core 2.1.

Versão introduzida

3.0

Comportamento antigo

Os aplicativos podem usar o Microsoft.AspNetCore.All metapacote para direcionar a Microsoft.AspNetCore.All estrutura compartilhada no .NET Core.

Novo comportamento

O .NET Core 3.0 não inclui uma Microsoft.AspNetCore.All estrutura compartilhada.

Razão para a alteração

O Microsoft.AspNetCore.All metapacote incluía um grande número de dependências externas.

Migre seu projeto para usar a Microsoft.AspNetCore.App estrutura. Os componentes que estavam disponíveis anteriormente ainda Microsoft.AspNetCore.All 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

Nenhuma

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 bem-sucedida com um IHubProtocolarquivo .

Versão introduzida

3.0

Comportamento antigo

HandshakeProtocol.SuccessHandshakeData era um public static ReadOnlyMemory<byte> campo.

Novo comportamento

HandshakeProtocol.SuccessHandshakeData foi substituído por um static GetSuccessfulHandshake(IHubProtocol protocol) método que retorna um ReadOnlyMemory<byte> com base no protocolo especificado.

Razão para a alteração

Campos adicionais foram adicionados à resposta de handshake que não são constantes e mudam dependendo do protocolo selecionado.

Nenhum. Esse tipo não foi projetado para uso a partir do código do usuário. É public, para que possa ser compartilhado entre o servidor SignalR e o cliente. Ele também pode ser usado por clientes SignalR clientes escritos em .NET. Os usuários do SignalR não devem ser afetados por essa alteração.

Categoria

ASP.NET Core

APIs afetadas

HandshakeProtocol.SuccessHandshakeData

SignalR: Métodos HubConnection ResetSendPing e ResetTimeout removidos

Os ResetSendPing métodos e ResetTimeout foram removidos da API do SignalR HubConnection . Estes métodos destinavam-se originalmente apenas a uso interno, mas foram tornados públicos no 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 discussão, consulte dotnet/aspnetcore#8543.

Versão introduzida

3.0

Comportamento antigo

As APIs estavam disponíveis.

Novo comportamento

As APIs são removidas.

Razão para a alteração

Estes métodos destinavam-se originalmente apenas a uso interno, mas foram tornados públicos no ASP.NET Core 2.2.

Não use esses métodos.

Categoria

ASP.NET Core

APIs afetadas

SignalR: HubConnectionContext construtores alterados

Os construtores HubConnectionContext do SignalR mudaram para aceitar um tipo de opções, em vez de vários parâmetros, para opções de adição preparadas para o futuro. Essa alteração substitui dois construtores por um único construtor que aceita um tipo de opções.

Versão introduzida

3.0

Comportamento antigo

HubConnectionContext tem dois construtores:

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:

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

Razão para a alteração

O novo construtor usa um novo objeto options. Consequentemente, as características do podem ser expandidas HubConnectionContext no futuro sem fazer mais construtores e quebrar mudanças.

Em vez de usar o seguinte construtor:

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

Use o seguinte construtor:

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

SignalR: Nome do pacote do cliente JavaScript alterado

No ASP.NET Core 3.0 Preview 7, o nome do pacote do cliente JavaScript do SignalR foi alterado de @aspnet/signalr para @microsoft/signalr. A mudança de nome reflete o fato de que o SignalR é útil em mais do que apenas aplicativos ASP.NET Core, graças ao Serviço SignalR do Azure.

Para reagir a essa alteração, altere as referências em seus arquivos package.json , require instruções e instruções ECMAScript import . Nenhuma API será alterada como parte dessa renomeação.

Para discussão, consulte dotnet/aspnetcore#11637.

Versão introduzida

3.0

Comportamento antigo

O pacote do cliente foi nomeado @aspnet/signalr.

Novo comportamento

O pacote do cliente é chamado @microsoft/signalr.

Razão para a alteração

A alteração de nome esclarece que o SignalR é útil além dos aplicativos ASP.NET Core, graças ao Serviço Azure SignalR.

Mude para o novo pacote @microsoft/signalr.

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

SignalR: Métodos UseSignalR e UseConnections marcados como obsoletos

Os métodos UseConnections e UseSignalR as classes ConnectionsRouteBuilder e HubRouteBuilder são marcados como obsoletos no ASP.NET Core 3.0.

Versão introduzida

3.0

Comportamento antigo

O roteamento do hub SignalR foi configurado usando UseSignalR ou UseConnections.

Novo comportamento

A antiga maneira de configurar o roteamento foi obsoleta e substituída pelo roteamento de ponto final.

Razão para a alteração

O middleware está sendo movido para o novo sistema de roteamento de pontos finais. A maneira antiga de adicionar middleware está sendo obsoleta.

Substitua UseSignalR por UseEndpoints:

Código antigo:

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

Novo código:

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

Categoria

ASP.NET Core

APIs afetadas

SPAs: SpaServices e NodeServices marcados como obsoletos

O conteúdo dos seguintes pacotes NuGet tem sido desnecessário desde ASP.NET Core 2.1. Consequentemente, os seguintes pacotes estão sendo marcados como obsoletos:

Pelo mesmo motivo, os seguintes módulos npm estão sendo marcados como obsoletos:

Os pacotes anteriores e os módulos npm serão removidos posteriormente no .NET 5.

Versão introduzida

3.0

Comportamento antigo

Os pacotes preteridos e os módulos npm destinavam-se a integrar ASP.NET Core com várias estruturas de Single-Page App (SPA). Tais estruturas incluem Angular, React e React with Redux.

Novo comportamento

Existe um novo mecanismo de integração no pacote NuGet Microsoft.AspNetCore.SpaServices.Extensions . O pacote continua sendo a base dos modelos de projeto Angular e React desde ASP.NET Core 2.1.

Razão para a alteração

ASP.NET Core suporta integração com várias estruturas de aplicativo de página única (SPA), incluindo Angular, React e React com Redux. Inicialmente, a integração com essas estruturas foi realizada com componentes específicos do ASP.NET Core que lidavam com cenários como pré-renderização do lado do servidor e integração com Webpack. Com o passar do tempo, os padrões da indústria mudaram. Cada uma das estruturas SPA lançou suas próprias interfaces de linha de comando padrão. Por exemplo, Angular CLI e create-react-app.

Quando o ASP.NET Core 2.1 foi lançado em maio de 2018, a equipe respondeu à mudança nos padrões. Foi fornecida uma forma mais recente e mais simples de integração com as próprias cadeias de ferramentas das estruturas SPA. O novo mecanismo de integração existe no pacote Microsoft.AspNetCore.SpaServices.Extensions e continua sendo a base dos modelos de projeto Angular e React desde ASP.NET Core 2.1.

Para esclarecer que os componentes mais antigos ASP.NET específicos do Core são irrelevantes e não recomendados:

  • O mecanismo de integração pré-2.1 está marcado como obsoleto.
  • Os pacotes npm de suporte são marcados como obsoletos.

Se estiver a utilizar estes pacotes, atualize as suas aplicações para utilizar a funcionalidade:

  • Microsoft.AspNetCore.SpaServices.Extensions No pacote.
  • Fornecido pelas estruturas de SPA que você está usando

Para habilitar recursos como pré-renderização do lado do servidor e recarga de módulo quente, consulte a documentação da estrutura SPA correspondente. A funcionalidade em Microsoft.AspNetCore.SpaServices.Extensions não está obsoleta e continuará a ser suportada.

Categoria

ASP.NET Core

APIs afetadas

SPAs: SpaServices e NodeServices não voltam mais para o registrador de console

Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices não exibirá os logs do console, a menos que o registro em log esteja configurado.

Versão introduzida

3.0

Comportamento antigo

Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices usado para criar automaticamente um registrador de console quando o registro em log não está configurado.

Novo comportamento

Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices não exibirá os logs do console, a menos que o registro em log esteja configurado.

Razão para a alteração

Há uma necessidade de alinhamento com a forma como outros pacotes ASP.NET Core implementam o registro.

Se o comportamento antigo for necessário, para configurar o log do console, adicione services.AddLogging(builder => builder.AddConsole()) ao seu Setup.ConfigureServices método.

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

Estrutura de destino: o suporte ao .NET Framework caiu

A partir do ASP.NET Core 3.0, o .NET Framework é uma estrutura de destino sem suporte.

Alterar a descrição

O .NET Framework 4.8 é a última versão principal do .NET Framework. Novos aplicativos ASP.NET Core devem ser criados no .NET Core. A partir da versão do .NET Core 3.0, você pode pensar no ASP.NET Core 3.0 como parte do .NET Core.

Os clientes que usam o ASP.NET Core com .NET Framework podem continuar de forma totalmente suportada usando a versão 2.1 LTS. O suporte e a manutenção para a versão 2.1 continuam até, pelo menos, 21 de agosto de 2021. Esta data é de três anos após a declaração da versão LTS de acordo com a Política de Suporte do .NET. O suporte para pacotes ASP.NET Core 2.1 no .NET Framework se estenderá indefinidamente, semelhante à política de manutenção para outras estruturas de ASP.NET baseadas em pacotes.

Para obter mais informações sobre a portabilidade do .NET Framework para o .NET Core, consulte Portabilidade para o .NET Core.

Microsoft.Extensions pacotes (como registro, injeção de dependência e configuração) e o Entity Framework Core não são afetados. Eles continuarão a oferecer suporte ao .NET Standard.

Para obter mais informações sobre a motivação para essa mudança, consulte a postagem original do blog.

Versão introduzida

3.0

Comportamento antigo

ASP.NET aplicativos principais podem ser executados no .NET Core ou no .NET Framework.

Novo comportamento

ASP.NET aplicativos principais só podem ser executados no .NET Core.

Efetue uma das seguintes ações:

  • Mantenha seu aplicativo no ASP.NET Core 2.1.
  • Migre seu aplicativo e dependências para o .NET Core.

Categoria

ASP.NET Core

APIs afetadas

Nenhuma

Principais bibliotecas .NET

APIs que relatam a versão agora relatam o produto e não a versão do arquivo

Muitas das APIs que retornam versões no .NET Core agora retornam a versão do produto em vez da versão do arquivo.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, métodos como Environment.Version, RuntimeInformation.FrameworkDescriptione a caixa de diálogo de propriedades de 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 para o assembly System.Runtime.dll para .NET Core 2.2 (à esquerda) e .NET Core 3.0 (à direita), conforme exibido pela caixa de diálogo de propriedades do arquivo do Windows Explorer .

Diferença nas informações sobre a versão do produto

Versão introduzida

3.0

Nenhum. Essa alteração deve tornar a deteção de versão intuitiva em vez de obtusa.

Categoria

Principais bibliotecas .NET

APIs afetadas

As instâncias personalizadas de EncoderFallbackBuffer não podem retornar recursivamente

As instâncias personalizadas EncoderFallbackBuffer não podem retornar recursivamente. A implementação de deve resultar em uma sequência de caracteres que é conversível para a codificação de EncoderFallbackBuffer.GetNextChar() destino. Caso contrário, ocorrerá uma exceção.

Alterar a descrição

Durante uma operação de transcodificação caractere para byte, o tempo de execução deteta sequências UTF-16 mal formadas ou não conversíveis e fornece esses caracteres para o EncoderFallbackBuffer.Fallback método. O Fallback método determina quais caracteres devem ser substituídos pelos dados não conversíveis originais, e esses caracteres são drenados chamando EncoderFallbackBuffer.GetNextChar 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 bem-sucedida, o tempo de execução continuará a transcodificação de onde parou na cadeia de caracteres de entrada original.

Anteriormente, implementações personalizadas de podem retornar sequências de caracteres que não são conversíveis para a codificação de EncoderFallbackBuffer.GetNextChar() destino. Se os caracteres substituídos não puderem ser transcodificados para a codificação de destino, o tempo de execução invocará o EncoderFallbackBuffer.Fallback método mais uma vez com os caracteres de substituição, esperando que o EncoderFallbackBuffer.GetNextChar() método retorne uma nova sequência de substituição. Esse processo continua até que o tempo de execução eventualmente veja uma substituição conversível bem formada, ou até que uma contagem máxima de recursão seja atingida.

A partir do .NET Core 3.0, implementações personalizadas de devem retornar sequências de caracteres que são conversíveis para a codificação de EncoderFallbackBuffer.GetNextChar() 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 EncoderFallbackBuffer instância.

Esse comportamento só se aplica quando todas as três das seguintes condições são atendidas:

  • O tempo de execução deteta 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 costume EncoderFallback foi especificado.
  • O costume EncoderFallback tenta substituir uma nova sequência UTF-16 mal formada ou não conversível.

Versão introduzida

3.0

A maioria dos desenvolvedores não precisa tomar nenhuma ação.

Se um aplicativo usa uma classe e EncoderFallbackBuffer personalizadaEncoderFallback, certifique-se de que a implementação de preenche o buffer de fallback com dados UTF-16 bem formados que são diretamente convertíveis para a codificação de destino quando o Fallback método é invocado EncoderFallbackBuffer.Fallback pela primeira vez pelo tempo de execução.

Categoria

Principais bibliotecas .NET

APIs afetadas

Formatação de ponto flutuante e comportamento de análise alterados

O comportamento de análise e formatação de ponto flutuante (pelos Double Single e tipos) agora é compatível com IEEE. Isso garante que o comportamento dos tipos de ponto flutuante no .NET corresponda ao de outras linguagens compatíveis com IEEE. Por exemplo, double.Parse("SomeLiteral") deve sempre corresponder ao que o C# produz para double x = SomeLiteral.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, a formatação com e Single.ToStringe a análise com , Double.TryParse, Single.Parsee Single.TryParse não são compatíveis com Double.ToString Double.ParseIEEE. Como resultado, é impossível garantir que um valor será de ida e volta com qualquer cadeia de caracteres de formato padrão ou personalizado suportado. Para algumas entradas, a tentativa de analisar um valor formatado pode falhar e, para outras, 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 de ponto flutuante são compatíveis com IEEE 754.

A tabela a seguir mostra dois trechos de código e como a saída muda entre o .NET Core 2.2 e o .NET Core 3.1.

Trechos de código Saída no .NET Core 2.2 Saída no .NET Core 3.1
Console.WriteLine((-0.0).ToString()); 0 0-
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

Para obter mais informações, consulte a postagem do blog Análise de ponto flutuante e melhorias de formatação no .NET Core 3.0 .

Versão introduzida

3.0

A seção Impacto potencial no código existente da postagem do blog Análise de ponto flutuante e formatação no .NET Core 3.0 sugere algumas alterações que você pode fazer no seu código se quiser manter o comportamento anterior.

  • Para algumas diferenças na formatação, você pode obter um comportamento equivalente ao comportamento anterior especificando uma cadeia de caracteres de formato diferente.
  • Para diferenças na análise, não há nenhum mecanismo para voltar ao comportamento anterior.

Categoria

Principais bibliotecas .NET

APIs afetadas

As operações de análise de ponto flutuante não falham mais nem geram uma OverflowException

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 Double tipo ou ponto flutuante.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, os Double.Parse métodos e Single.Parse lançam um OverflowException para valores que estão fora do intervalo de seu respetivo tipo. Os Double.TryParse métodos 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 Double.Parsemétodos , Single.ParseDouble.TryParse, e não Single.TryParse falham mais ao analisar cadeias de caracteres numéricas fora do intervalo. Em vez disso, os Double métodos de análise retornam Double.PositiveInfinity para valores que excedem Double.MaxValue, e retornam Double.NegativeInfinity para valores que são menores que Double.MinValue. Da mesma forma, os Single métodos de análise retornam Single.PositiveInfinity para valores que excedem Single.MaxValue, e retornam Single.NegativeInfinity para valores que são menores que Single.MinValue.

Esta alteração foi feita para melhorar a conformidade com o IEEE 754:2008.

Versão introduzida

3.0

Essa alteração pode afetar seu código de duas maneiras:

  • Seu código depende do manipulador para ser OverflowException executado quando ocorre um estouro. Nesse caso, você deve remover a catch instrução e colocar qualquer código necessário em uma instrução que testa If se Double.IsInfinity ou Single.IsInfinity é true.

  • Seu código pressupõe que os valores de ponto flutuante não Infinitysão . Nesse caso, você deve adicionar o código necessário para verificar os valores de vírgula flutuante de PositiveInfinity e NegativeInfinity.

Categoria

Principais bibliotecas .NET

APIs afetadas

InvalidAsynchronousStateException movido para outro assembly

A InvalidAsynchronousStateException classe foi transferida.

Alterar a 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.Primitives .

Versão introduzida

3.0

Essa alteração afeta apenas os aplicativos que usam reflexão para carregar o InvalidAsynchronousStateException chamando um método como Assembly.GetType ou uma sobrecarga de Activator.CreateInstance que pressupõe que o tipo está em um assembly específico. Se esse for o caso, atualize o assembly referenciado na chamada de método para refletir o novo local de assembly do tipo.

Categoria

Principais bibliotecas .NET

APIs afetadas

Nenhum.

A substituição de sequências de bytes UTF-8 mal formadas segue as diretrizes do Unicode

Quando a UTF8Encoding classe encontra uma sequência de bytes UTF-8 mal formada durante uma operação de transcodificação byte-para-caracteres, ela substitui essa sequência por um caractere ' ' (U+FFFD REPLACEMENT CHARACTER) na cadeia de caracteres de saída. O .NET Core 3.0 difere das versões anteriores do .NET Core e do .NET Framework seguindo a prática recomendada do 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, inclusive pelos novos System.Text.Unicode.Utf8 e System.Text.Rune tipos. O UTF8Encoding tipo recebeu uma mecânica melhorada de tratamento de erros para que produza resultados consistentes com os tipos recém-introduzidos.

Alterar a descrição

A partir do .NET Core 3.0, ao transcodificar bytes em caracteres, a classe executa a UTF8Encoding substituição de caracteres com base nas práticas recomendadas do Unicode. O mecanismo de substituição utilizado é descrito pelo The Unicode Standard, Versão 12.0, Sec. 3.9 (PDF) no título intitulado U+FFFD Substitution of Maximal Subparts.

Esse comportamento só se aplica quando a sequência de bytes de entrada contém dados UTF-8 mal formados. Além disso, se a UTF8Encoding instância tiver sido construída com throwOnInvalidBytes: true, a UTF8Encoding instância continuará a lançar entradas inválidas em vez de executar a substituição U+FFFD. Para obter mais informações sobre o UTF8Encoding construtor, consulte UTF8Encoding(Boolean, Boolean).

A tabela a seguir ilustra o impacto dessa alteração com uma entrada inválida de 3 bytes:

Entrada de 3 bytes mal formada Saída antes do .NET Core 3.0 Saída começando com .NET Core 3.0
[ ED A0 90 ] [ FFFD FFFD ] (saída de 2 caracteres) [ FFFD FFFD FFFD ] (saída de 3 caracteres)

A 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

Nenhuma ação é necessária por parte do desenvolvedor.

Categoria

Principais bibliotecas .NET

APIs afetadas

TypeDescriptionProviderAttribute movido para outro assembly

A TypeDescriptionProviderAttribute classe foi transferida.

Alterar a 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

Essa alteração afeta apenas os aplicativos que usam reflexão para carregar o TypeDescriptionProviderAttribute tipo chamando um método como Assembly.GetType ou uma sobrecarga de Activator.CreateInstance que pressupõe que o tipo está em um assembly específico. Se esse for o caso, o assembly referenciado na chamada de método deve ser atualizado para refletir o novo local de assembly do tipo.

Categoria

Windows Forms

APIs afetadas

Nenhum.

ZipArchiveEntry não lida mais com arquivos com tamanhos de entrada inconsistentes

Os arquivos zip listam o tamanho compactado e o tamanho não compactado no diretório central e no cabeçalho local. Os próprios dados de entrada também indicam o seu tamanho. No .NET Core 2.2 e versões anteriores, esses valores nunca foram verificados quanto à consistência. Começando com o .NET Core 3.0, eles agora são.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, ZipArchiveEntry.Open() é bem-sucedido mesmo se o cabeçalho local discordar do 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 não compactado listado no diretório central/cabeçalho local.

A partir do .NET Core 3.0, o método verifica se o cabeçalho local e o cabeçalho central concordam com os ZipArchiveEntry.Open() tamanhos compactados e não compactados de uma entrada. Se isso não acontecer, o método lançará um InvalidDataException cabeçalho local do arquivo e/ou tamanhos de lista de descritores de dados que discordam do diretório central do arquivo zip. Ao ler uma entrada, os dados descompactados são truncados para o tamanho de arquivo não compactado listado no cabeçalho.

Essa alteração foi feita para garantir que um ZipArchiveEntry representa corretamente o tamanho de seus dados e que apenas essa quantidade de dados é lida.

Versão introduzida

3.0

Reempacote qualquer arquivo zip que exiba esses problemas.

Categoria

Principais bibliotecas .NET

APIs afetadas

FieldInfo.SetValue lança exceção para campos estáticos somente de inicialização

A partir do .NET Core 3.0, uma exceção é lançada quando você tenta definir um valor em um campo estático InitOnly chamando System.Reflection.FieldInfo.SetValue.

Alterar a descrição

No .NET Framework e em versões do .NET Core anteriores à 3.0, você pode definir o valor de um campo estático que é constante depois que ele é inicializado (somente leitura em C#) chamando System.Reflection.FieldInfo.SetValue. No entanto, definir esse campo dessa maneira resultou em um comportamento imprevisível com base na estrutura de destino e nas configurações de otimização.

No .NET Core 3.0 e versões posteriores, quando você chama SetValue um campo estático, InitOnly uma System.FieldAccessException exceção é lançada.

Gorjeta

Um InitOnly campo é aquele que só pode ser definido no momento em que é declarado ou no construtor para a classe que contém. Em outras palavras, é constante depois de inicializado.

Versão introduzida

3.0

Inicialize campos estáticos InitOnly em um construtor estático. Isto aplica-se a tipos dinâmicos e não dinâmicos.

Como alternativa, você pode remover o FieldAttributes.InitOnly atributo do campo e, em seguida, chamar FieldInfo.SetValue.

Categoria

Principais bibliotecas .NET

APIs afetadas

Passar GroupCollection para métodos de extensão tomando IEnumerable<T> requer desambiguação

Ao chamar um método de extensão que assume um IEnumerable<T> GroupCollection, você deve desambiguar o tipo usando um cast.

Alterar a descrição

A partir do .NET Core 3.0, System.Text.RegularExpressions.GroupCollection implementa além dos IEnumerable<KeyValuePair<String,Group>> outros tipos que implementa, incluindo IEnumerable<Group>. Isso resulta em ambiguidade ao chamar um método de extensão que usa um IEnumerable<T>arquivo . Se você chamar esse método de extensão em uma GroupCollection instância, por exemplo, Enumerable.Countverá o seguinte erro do compilador:

CS1061: 'GroupCollection' não contém uma definição para 'Count' e nenhum método de extensão acessível 'Count' aceitando um primeiro argumento do tipo 'GroupCollection' pode ser encontrado (você está faltando uma diretiva de uso ou uma referência de assembly?)

Em versões anteriores do .NET, não havia ambiguidade nem erro de compilador.

Versão introduzida

3.0

Razão para a alteração

Esta foi uma mudança de rutura não intencional. Como já é assim há algum tempo, não pretendemos revertê-lo. Além disso, essa mudança seria, por si só, uma rutura.

Por GroupCollection exemplo, desambiguar chamadas para métodos de extensão que aceitam um IEnumerable<T> com um elenco.

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

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

Categoria

Principais bibliotecas .NET

APIs afetadas

Qualquer método de extensão que aceite um IEnumerable<T> é afetado. Por exemplo:

Criptografia

A sintaxe "BEGIN TRUSTED CERTIFICATE" não é mais suportada para certificados raiz no Linux

Os certificados raiz no Linux e em outros sistemas Unix-like (mas não macOS) podem ser apresentados de duas formas: o cabeçalho PEM padrão BEGIN CERTIFICATE e o cabeçalho PEM específico BEGIN TRUSTED CERTIFICATE do OpenSSL. A última sintaxe permite a configuração adicional que causou problemas de compatibilidade com a classe do System.Security.Cryptography.X509Certificates.X509Chain .NET Core. BEGIN TRUSTED CERTIFICATE o conteúdo do certificado raiz não é mais carregado pelo mecanismo de cadeia a partir do .NET Core 3.0.

Alterar a descrição

Anteriormente, as sintaxes e BEGIN TRUSTED CERTIFICATE as BEGIN CERTIFICATE sintaxes eram usadas para preencher a lista de confiança raiz. Se a BEGIN TRUSTED CERTIFICATE sintaxe foi usada e opções adicionais foram especificadas no arquivo, X509Chain pode ter relatado que a confiança de cadeia foi explicitamente proibida (X509ChainStatusFlags.ExplicitDistrust). No entanto, se o certificado também foi especificado com a BEGIN CERTIFICATE sintaxe em um arquivo carregado anteriormente, a confiança de cadeia foi permitida.

A partir do .NET Core 3.0, BEGIN TRUSTED CERTIFICATE o conteúdo não é mais lido. Se o certificado também não for especificado por meio de uma sintaxe padrão BEGIN CERTIFICATE , informará X509Chain que a raiz não é confiável (X509ChainStatusFlags.UntrustedRoot).

Versão introduzida

3.0

A maioria dos aplicativos não é afetada por essa alteração, mas os aplicativos que não conseguem ver ambas as fontes de certificado raiz devido a problemas de permissões podem enfrentar erros inesperados UntrustedRoot após a atualização.

Muitas distribuições Linux (ou distros) gravam certificados raiz em dois locais: um diretório de um certificado por arquivo e uma concatenação de um arquivo. Em algumas distros, o diretório one-certificate-per-file usa a BEGIN TRUSTED CERTIFICATE sintaxe enquanto a concatenação de arquivos usa a sintaxe padrão BEGIN CERTIFICATE . Certifique-se de que todos os certificados raiz personalizados sejam adicionados como BEGIN CERTIFICATE em pelo menos um desses locais e que ambos os locais possam ser lidos pelo seu aplicativo.

O diretório típico é /etc/ssl/certs/ e o arquivo concatenado típico é /etc/ssl/cert.pem. Use o comando openssl version -d para determinar a raiz específica da plataforma, que pode diferir de /etc/ssl/. Por exemplo, no Ubuntu 18.04, o diretório é /usr/lib/ssl/certs/ e o arquivo é /usr/lib/ssl/cert.pem. No entanto, /usr/lib/ssl/certs/ é um link simbólico para /etc/ssl/certs/ e /usr/lib/ssl/cert.pem não existe.

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

Categoria

Criptografia

APIs afetadas

O padrão EnvelopedCms é a criptografia AES-256

O algoritmo de encriptação simétrica padrão usado por EnvelopedCms mudou de TripleDES para AES-256.

Alterar a descrição

Em 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 são criptografados com o algoritmo TripleDES/3DES/3DEA/DES3-EDE.

A partir do .NET Core 3.0 (via 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 pode falhar devido CryptographicException 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 2.2 ou anterior. Se estiver sendo executado no .NET Core 3.0 ou posterior, ele será criptografado com AES-256.

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

Versão introduzida

3.0

Se você for afetado negativamente pela alteração, poderá restaurar a criptografia TripleDES especificando explicitamente o identificador do algoritmo de criptografia em um EnvelopedCms construtor que inclua um parâmetro do tipo AlgorithmIdentifier, como:

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();

Categoria

Criptografia

APIs afetadas

O tamanho mínimo para a geração de chaves RSAOpenSsl aumentou

O tamanho mínimo para gerar novas chaves RSA no Linux aumentou de 384 bits para 512 bits.

Alterar a descrição

A partir do .NET Core 3.0, o tamanho mínimo da chave legal relatado LegalKeySizes pela propriedade em instâncias RSA de RSA.Create, RSAOpenSsle RSACryptoServiceProvider no Linux aumentou de 384 para 512.

Como resultado, no .NET Core 2.2 e versões anteriores, uma chamada de método como RSA.Create(384) bem-sucedida. No .NET Core 3.0 e versões posteriores, a chamada RSA.Create(384) de método lança uma exceção indicando que o tamanho é muito pequeno.

Esta alteração foi feita porque o OpenSSL, que executa as operações criptográficas no Linux, aumentou o seu mínimo entre as versões 1.0.2 e 1.1.0. O .NET Core 3.0 prefere OpenSSL 1.1.x a 1.0.x, e a versão mínima relatada foi aumentada para refletir essa nova limitação de dependência mais alta.

Versão introduzida

3.0

Se você chamar qualquer uma das APIs afetadas, verifique se o tamanho das chaves geradas não é inferior ao mínimo do provedor.

Nota

O RSA de 384 bits já é considerado inseguro (assim como o RSA de 512 bits). Recomendações modernas, como a Publicação Especial NIST 800-57 Parte 1 Revisão 4, sugerem 2048 bits como o tamanho mínimo para chaves recém-geradas.

Categoria

Criptografia

APIs afetadas

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 Linux, pode suportar OpenSSL 1.0.x e OpenSSL 1.1.x. O .NET Core 2.1 e o .NET Core 2.2 procuram primeiro o 1.0.x e, em seguida, voltam para o 1.1.x; o .NET Core 3.0 procura o 1.1.x primeiro. Esta alteração foi feita para adicionar suporte para novos padrões criptográficos.

Essa alteração pode afetar bibliotecas ou aplicativos que fazem interoperabilidade de plataforma com os tipos de interoperabilidade específicos do OpenSSL no .NET Core.

Alterar a descrição

No .NET Core 2.2 e versões anteriores, o tempo de execução prefere carregar o OpenSSL 1.0.x em vez do 1.1.x. Isso significa que os IntPtr e SafeHandle tipos para interoperabilidade com OpenSSL são usados com libcrypto.so.1.0.0 / libcrypto.so.1.0 / libcrypto.so.10 por preferência.

A partir do .NET Core 3.0, o tempo de execução prefere carregar o OpenSSL 1.1.x em vez do OpenSSL 1.0.x, então os IntPtr tipos e SafeHandle para interoperabilidade com o OpenSSL são usados com libcrypto.so.1.1 / libcrypto.so.11 / libcrypto.so.1.1.0 / libcrypto.so.1.1.1 por preferência. Como resultado, bibliotecas e aplicativos que interoperam diretamente com o OpenSSL podem ter ponteiros incompatíveis com os valores expostos ao .NET Core ao atualizar do .NET Core 2.1 ou .NET Core 2.2.

Versão introduzida

3.0

Bibliotecas e aplicativos que fazem operações diretas com o OpenSSL precisam ter cuidado para garantir que estão usando a mesma versão do OpenSSL que o tempo de execução do .NET Core.

Todas as bibliotecas ou aplicativos que usam IntPtr ou SafeHandle valores dos tipos criptográficos do .NET Core diretamente com o OpenSSL devem comparar a versão da biblioteca que usam com a nova SafeEvpPKeyHandle.OpenSslVersion propriedade para garantir que os ponteiros sejam compatíveis.

Categoria

Criptografia

APIs afetadas

CryptoStream.Dispose transforma o bloco final somente ao escrever

O CryptoStream.Dispose método, que é usado para concluir CryptoStream operações, não tenta mais transformar o bloco final durante a leitura.

Alterar a descrição

Em versões anteriores do .NET, se um usuário executasse uma leitura incompleta ao usar CryptoStream no Read modo, o Dispose método poderia lançar uma exceção (por exemplo, ao usar AES com preenchimento). A exceção foi lançada porque o bloco final foi tentado para ser transformado, mas os dados estavam incompletos.

No .NET Core 3.0 e versões posteriores, Dispose não é mais possível transformar o bloco final durante a leitura, o que permite leituras incompletas.

Razão para a alteração

Essa alteração permite leituras incompletas do fluxo de criptografia quando uma operação de rede é cancelada, sem a necessidade de capturar uma exceção.

Versão introduzida

3.0

A maioria das aplicações não deve ser afetada por esta alteração.

Se o seu aplicativo já detetou uma exceção em caso de leitura incompleta, você pode excluir esse catch bloco. Se seu aplicativo usou a transformação do bloco final em cenários de hash, talvez seja necessário garantir que todo o fluxo seja lido antes de ser descartado.

Categoria

Criptografia

APIs afetadas

Entity Framework Core

Alterações significativas do Entity Framework Core

Globalização

A localidade "C" é mapeada para a localidade invariante

O .NET Core 2.2 e versões anteriores dependem do comportamento padrão da UTI, que mapeia a localidade "C" para a localidade en_US_POSIX. A localidade en_US_POSIX tem um comportamento de agrupamento indesejável, porque não oferece suporte a comparações de cadeia de caracteres que diferenciam maiúsculas de minúsculas. Como algumas distribuições Linux definem a localidade "C" como a localidade padrão, os usuários estavam enfrentando um comportamento inesperado.

Alterar a descrição

A partir do .NET Core 3.0, o mapeamento de localidade "C" foi alterado para usar a localidade Invariant em vez de en_US_POSIX. A localidade "C" para mapeamento Invariante também é aplicada ao Windows para consistência.

O mapeamento de "C" para en_US_POSIX cultura causou confusão no cliente, porque en_US_POSIX não suporta operações de classificação/pesquisa de cadeia de caracteres sem diferenciação de maiúsculas e minúsculas. Como a localidade "C" é usada como uma localidade padrão em algumas das distros Linux, os clientes experimentaram esse comportamento indesejado nesses sistemas operacionais.

Versão introduzida

3.0

Nada mais específico do que a consciência dessa mudança. Essa alteração afeta apenas 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.

MSBuild

Alteração de nome de arquivo de manifesto de recurso

A partir do .NET Core 3.0, no caso padrão, o MSBuild gera um nome de arquivo de manifesto diferente para arquivos de recurso.

Versão introduzida

3.0

Alterar a descrição

Antes do .NET Core 3.0, se nenhum , ou metadados foram especificados para um EmbeddedResource item no arquivo de projeto, o MSBuild gerou um nome de arquivo de manifesto no padrão <RootNamespace>.<ResourceFilePathFromProjectRoot>.resources.DependentUpon ManifestResourceNameLogicalName Se RootNamespace não estiver definido no arquivo de projeto, o padrão será o nome do projeto. Por exemplo, o nome de manifesto gerado para um arquivo de recurso chamado Form1.resx no diretório raiz do projeto foi MyProject.Form1.resources.

A partir do .NET Core 3.0, se um arquivo de recurso for colocalizado com um arquivo de origem com o mesmo nome (por exemplo, Form1.resx e Form1.cs), o MSBuild usará informações de tipo do arquivo de origem para gerar o nome do arquivo de manifesto no padrão <Namespace>.<ClassName>.resources. O namespace e o nome da classe são extraídos do primeiro tipo no arquivo de origem colocalizado. Por exemplo, o nome de manifesto gerado para um arquivo de recurso chamado Form1.resx que é colocalizado com um arquivo de origem chamado Form1.cs é MyNamespace.Form1.resources. A principal coisa a observar é que a primeira parte do nome do arquivo é diferente das versões anteriores do .NET Core (MyNamespace em vez de MyProject).

Nota

Se você tiver LogicalName, ManifestResourceName, ou DependentUpon metadados especificados em um EmbeddedResource item no arquivo de projeto, essa alteração não afetará esse arquivo de recurso.

Essa alteração de quebra foi introduzida com a EmbeddedResourceUseDependentUponConvention adição da propriedade aos projetos .NET Core. Por padrão, os arquivos de recursos não são explicitamente listados em um arquivo de projeto .NET Core, portanto, eles não DependentUpon têm metadados para especificar como nomear o arquivo .resources gerado. Quando EmbeddedResourceUseDependentUponConvention é definido como true, que é o padrão, o MSBuild procura um arquivo de origem colocalizado e extrai um namespace e um nome de classe desse arquivo. Se você definir EmbeddedResourceUseDependentUponConvention como false, o MSBuild gerará o nome do manifesto de acordo com o comportamento anterior, que combina RootNamespace e o caminho do arquivo relativo.

Na maioria dos casos, nenhuma ação é necessária por parte do desenvolvedor, e seu aplicativo deve continuar a funcionar. No entanto, se essa alteração quebrar seu aplicativo, você poderá:

  • Altere seu código para esperar o novo nome de manifesto.

  • Desative a nova convenção de nomenclatura definindo EmbeddedResourceUseDependentUponConvention como false no arquivo de projeto.

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

Categoria

MSBuild

APIs afetadas

N/A

Rede

Valor padrão de HttpRequestMessage.Version alterado para 1.1

O valor padrão da System.Net.Http.HttpRequestMessage.Version propriedade foi alterado de 2.0 para 1.1.

Versão introduzida

3.0

Alterar a descrição

No .NET Core 1.0 a 2.0, o System.Net.Http.HttpRequestMessage.Version valor padrão da propriedade é 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 System.Net.Http.HttpRequestMessage.Version versão padrão retornado pela propriedade é novamente 1.1.

Atualize seu código se depender da System.Net.Http.HttpRequestMessage.Version propriedade que retorna um valor padrão de 2.0.

Categoria

Rede

APIs afetadas

WPF

Comportamento alterado de arrastar e soltar em editores de texto

O .NET Core 3.0 introduziu uma alteração na forma como os controles do editor de texto criam um System.Windows.DataObject ao arrastar texto para outro controle. A alteração desativou a conversão automática, fazendo com que a operação mantenha os dados como DataFormats.Text ou DataFormats.UnicodeText em vez de convertê-los em DataFormats.StringFormat.

Versão introduzida

.NET Core 3.0

Categoria

Windows Presentation Foundation

Comportamento anterior

O tipo de dados ao System.Windows.DataObject arrastar texto de um controle de editor de texto era DataFormats.StringFormat.

Novo comportamento

O tipo de dados ao System.Windows.DataObject arrastar texto de um controle de editor de texto é DataFormats.Text ou DataFormats.UnicodeText.

Tipo de mudança de rutura

Esta mudança é uma mudança comportamental.

Razão para a alteração

A mudança não foi intencional.

Essa alteração foi revertida no .NET 7. Atualize para o .NET 7 ou posterior.

APIs afetadas

Consulte também