Formação
Módulo
Proteja um aplicativo Web .NET com a estrutura ASP.NET Core Identity - Training
Saiba como adicionar autenticação e autorização a um aplicativo Web .NET usando a estrutura ASP.NET Core Identity.
Este browser já não é suportado.
Atualize para o Microsoft Edge para tirar partido das mais recentes funcionalidades, atualizações de segurança e de suporte técnico.
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.
Membros obsoletos e switches de compatibilidade no ASP.NET Core 2.2 foram removidos.
3.0
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.
ASP.NET Core
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.DictionaryModelBinder`2(IModelBinder,IModelBinder)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.DoubleModelBinder(System.Globalization.NumberStyles)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FloatModelBinder(System.Globalization.NumberStyles)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormCollectionModelBinder
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.FormFileModelBinder
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.HeaderModelBinder
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.KeyValuePairModelBinder`2(IModelBinder,IModelBinder)
Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder(System.Type)
Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object})
Microsoft.AspNetCore.Mvc.ModelBinding.ModelAttributes(IEnumerable{System.Object},IEnumerable{System.Object})
Microsoft.AspNetCore.Mvc.ModelBinding.ModelBinderFactory(IModelMetadataProvider,IOptions{MvcOptions})
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder(IModelMetadataProvider,IModelBinderFactory,IObjectModelValidator)
Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter
Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(System.Boolean)
Microsoft.AspNetCore.Mvc.Formatters.XmlDataContractSerializerInputFormatter(MvcOptions)
Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter
Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(System.Boolean)
Microsoft.AspNetCore.Mvc.Formatters.XmlSerializerInputFormatter(MvcOptions)
Microsoft.AspNetCore.Mvc.TagHelpers.LinkTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
Microsoft.AspNetCore.Mvc.TagHelpers.ScriptTagHelper(IHostingEnvironment,IMemoryCache,HtmlEncoder,JavaScriptEncoder,IUrlHelperFactory)
Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.RazorPageAdapter(RazorPageBase)
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
Microsoft.AspNetCore.Mvc.LocalRedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToActionResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToPageResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.RedirectToRouteResult.ExecuteResult(ActionContext)
Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder.BindModelAsync(ActionContext,IValueProvider,ParameterDescriptor)
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.
3.0
As APIs afetadas são marcadas com o modificador de public
acesso e existem em *.Internal
namespaces.
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.
A orientação para essas "pubternal" APIs era que:
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();
ASP.NET Core
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
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.
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.
Todas as versões. Esta alteração é externa ao ASP.NET Core.
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.
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 .
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.
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();
ASP.NET Core
Microsoft.AspNetCore.Authentication.Google
A propriedade preterida Authentication
em HttpContext
foi removida.
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.
3.0
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.
ASP.NET Core
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:
Para obter mais informações, consulte dotnet/aspnetcore#7105. Para discussão, consulte dotnet/aspnetcore#7289.
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:
ClaimAction.Run(JsonElement userData, ClaimsIdentity identity, string issuer)
. Todas as implementações derivadas de ClaimAction
são igualmente afetadas.MapCustomJson(this ClaimActionCollection collection, string claimType, Func<JsonElement, string> resolver)
MapCustomJson(this ClaimActionCollection collection, string claimType, string valueType, Func<JsonElement, string> resolver)
JObject
por JsonElement
. A propriedade e RunClaimActions
o User
método foram atualizados para corresponder.JsonDocument
em vez de JObject
. A Response
propriedade foi atualizada para corresponder. OAuthTokenResponse
agora é descartável e será descartado pela OAuthHandler
. A substituição ExchangeCodeAsync
de implementações OAuth derivadas não precisa descartar o JsonDocument
ou OAuthTokenResponse
.JObject
para JsonDocument
.JObject
para JsonElement
.JObject
para JsonElement
. O método de substituição é TwitterHandler.CreateTicketAsync(ClaimsIdentity, AuthenticationProperties, AccessToken, JsonElement).ASP.NET Core
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; }
3.0
As code
cordas e redirectUri
foram passadas como argumentos separados.
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
.
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.
ASP.NET Core
OAuthHandler<TOptions>.ExchangeCodeAsync(String, String)
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.
3.0
AddAuthorization
métodos existiam em Microsoft.AspNetCore.Authorization
.
AddAuthorization
existem métodos em Microsoft.AspNetCore.Authorization.Policy
. AddAuthorizationCore
é o novo nome para os métodos antigos.
AddAuthorization
é um nome de método melhor para adicionar todos os serviços comuns necessários para autorização.
Adicione uma referência ou Microsoft.AspNetCore.Authorization.Policy
use AddAuthorizationCore
em vez disso.
ASP.NET Core
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.
3.0
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.
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.
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.
ASP.NET Core
Nenhuma
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.
3.0
As implementações de IAuthorizationPolicyProvider
não exigiam um GetFallbackPolicyAsync
método.
Implementações de IAuthorizationPolicyProvider
requerem um GetFallbackPolicyAsync
método.
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
.
ASP.NET Core
Microsoft.AspNetCore.Authorization.IAuthorizationPolicyProvider
A versão ASP.NET Core 3.0 removeu as APIs MemoryCacheOptions obsoletas.
Esta alteração é uma continuação do aspnet/Caching#221. Para discussão, consulte dotnet/extensions#1062.
3.0
MemoryCacheOptions.CompactOnMemoryPressure
propriedade estava disponível.
A MemoryCacheOptions.CompactOnMemoryPressure
propriedade foi removida.
A compactação automática do cache causou problemas. Para evitar um comportamento inesperado, o cache só deve ser compactado quando necessário.
Para compactar o cache, faça downcast e chame MemoryCache
Compact
quando necessário.
ASP.NET Core
MemoryCacheOptions.CompactOnMemoryPressure
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.
3.0
O Microsoft.Extensions.Caching.SqlServer
pacote usou o System.Data.SqlClient
pacote.
Microsoft.Extensions.Caching.SqlServer
está agora a utilizar o Microsoft.Data.SqlClient
pacote.
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.
ASP.NET Core
Nenhuma
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.
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.
3.0
Esses tipos eram publicamente visíveis, mas sem suporte.
Estes tipos são agora internal
.
O internal
âmbito de aplicação reflete melhor a política não apoiada.
Copie os tipos usados pelo seu aplicativo ou biblioteca.
ASP.NET Core
Microsoft.AspNetCore.ResponseCaching.Internal.CachedResponse
Microsoft.AspNetCore.ResponseCaching.Internal.CachedVaryByRules
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCacheEntry
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.IResponseCachingPolicyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.MemoryResponseCache
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingContext
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingKeyProvider
Microsoft.AspNetCore.ResponseCaching.Internal.ResponseCachingPolicyProvider
Azure.Extensions.AspNetCore.DataProtection.Blobs
depende 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.
3.0
O pacote fazia referência ao WindowsAzure.Storage
pacote NuGet.
O pacote faz referência ao Microsoft.Azure.Storage.Blob
pacote NuGet.
O pacote faz referência ao Azure.Storage.Blob
pacote NuGet.
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;
ASP.NET Core
Nenhuma
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.
3.0
ANCM V1 está incluído no Windows Hosting Bundle.
ANCM V1 não está incluído no Windows Hosting Bundle.
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:
<AspNetCoreModuleName>AspNetCoreModule</AspNetCoreModuleName>
.<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
o .ASP.NET Core
Nenhuma
Os únicos tipos que o host genérico suporta para Startup
injeção de construtor de classe são IHostEnvironment
, IWebHostEnvironment
e IConfiguration
. As aplicações que utilizam WebHost
não são afetadas.
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:
ASP.NET Core 3.0:
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
, IWebHostEnvironment
e IConfiguration
pode ser injetado. Essa alteração evita problemas de DI, como a criação duplicada de um serviço singleton.
3.0
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)
ASP.NET Core
Nenhuma
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.
3.0
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.
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.
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:
ASPNETCORE_HTTPS_PORT
variável de ambiente para o número de porta apropriado (443 na maioria dos cenários de produção).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.
ASP.NET Core
HttpsPolicyBuilderExtensions.UseHttpsRedirection(IApplicationBuilder)
Foram introduzidos novos tipos para substituir os existentes IHostingEnvironment
e IApplicationLifetime
os tipos.
3.0
Havia dois tipos diferentes IHostingEnvironment
de IApplicationLifetime
Microsoft.Extensions.Hosting
e Microsoft.AspNetCore.Hosting
.
Os tipos antigos foram marcados como obsoletos e substituídos por novos tipos.
Quando Microsoft.Extensions.Hosting
foi introduzido no ASP.NET Core 2.1, alguns tipos como IHostingEnvironment
e IApplicationLifetime
foram copiados 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:
Microsoft.AspNetCore.Hosting.IWebHostEnvironment : IHostEnvironment
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.
ASP.NET Core
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.
3.0
WebHostBuilder
fornece ObjectPoolProvider
por padrão no contêiner DI.
WebHostBuilder
não fornece ObjectPoolProvider
mais por padrão no contêiner DI.
Esta mudança foi feita para fazer com que ASP.NET Core pagasse mais pelo jogo.
Se o componente exigir ObjectPoolProvider
o , ele precisará ser adicionado às suas dependências por meio do IServiceCollection
.
ASP.NET Core
Nenhuma
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.
3.0
As classes podem derivar de DefaultHttpContext
.
As classes não podem derivar de DefaultHttpContext
.
A extensibilidade foi fornecida inicialmente para permitir o HttpContext
agrupamento 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.
ASP.NET Core
Microsoft.AspNetCore.Http.DefaultHttpContext
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.
3.0
Estes campos costumavam ser const
.
Estes campos são agora static readonly
.
A mudança:
Recompile contra 3.0. O código-fonte que utiliza estes campos das seguintes formas já não o pode fazer:
case
em uma switch
declaraçãoconst
Para contornar a alteração de quebra, alterne para usar constantes de nome de cabeçalho autodefinidas ou literais de cadeia de caracteres.
ASP.NET Core
Microsoft.Net.Http.Headers.HeaderNames
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.Features
o .
3.0
Havia três APIs associadas ao corpo de resposta HTTP:
IHttpResponseFeature.Body
IHttpSendFileFeature.SendFileAsync
IHttpBufferingFeature.DisableResponseBuffering
Se você substituir HttpResponse.Body
o , 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.
A motivação é combinar as APIs do corpo de resposta em uma única interface de novo recurso.
Use IHttpResponseBodyFeature
onde você estava usando IHttpResponseFeature.Body
anteriormente , IHttpSendFileFeature
, ou IHttpBufferingFeature
.
ASP.NET Core
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.
3.0
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.
Todas as APIs afetadas usam como SameSiteMode.None
padrã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.
ASP.NET Core
A partir do ASP.NET Core 3.0, as operações de servidor síncrono são desabilitadas por padrão.
AllowSynchronousIO
é uma opção em cada servidor que habilita ou desabilita APIs de E/S síncronas como HttpRequest.Body.Read
, HttpResponse.Body.Write
e Stream.Flush
. Essas APIs têm sido uma 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:
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.
3.0
HttpRequest.Body.Read
, HttpResponse.Body.Write
e Stream.Flush
foram permitidos por defeito.
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.
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;
}
ASP.NET Core
A partir do ASP.NET Core 3.0, a sobrecarga do método IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework) não existe mais.
3.0
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>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder,UIFramework)
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.
3.0
A services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
chamada de método foi a mesma que services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap3);
A services.AddDefaultIdentity<IdentityUser>().AddDefaultUI();
chamada de método é a mesma que services.AddDefaultIdentity<IdentityUser>().AddDefaultUI(UIFramework.Bootstrap4);
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);
ASP.NET Core
Nenhuma
Por padrão, SignInAsync
lança uma exceção para entidades / identidades em que IsAuthenticated
é false
.
3.0
SignInAsync
aceita quaisquer princípios / identidades, incluindo identidades em que IsAuthenticated
é false
.
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.
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.
ASP.NET Core
Nenhuma
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.
3.0
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.
ASP.NET Core
ASP.NET Core 3.0 introduziu um recurso estático de ativos da Web e a Identity UI o adotou.
Como resultado da adoção da interface do usuário de identidade pelo recurso de ativos estáticos da Web:
IdentityUIFrameworkVersion
propriedade em seu arquivo de projeto.3.0
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
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.
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>
ASP.NET Core
IdentityBuilderUIExtensions.AddDefaultUI(IdentityBuilder, UIFramework)
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.
3.0
Os componentes de extensibilidade do peneireiro-das-torres foram criados utilizando IConnectionAdapter
.
Os componentes de extensibilidade do peneireiro-das-torres são criados como middleware.
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.
ASP.NET Core
Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter
O conjunto Microsoft.AspNetCore.Server.Kestrel.Https foi removido.
3.0
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.
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.Microsoft.AspNetCore.Server.Kestrel.Https
ao pacote NuGet.ASP.NET Core
Nenhuma
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.
3.0
Os cabeçalhos do trailer de solicitação seriam adicionados à HttpRequest.Headers
coleção.
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.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.
ASP.NET Core
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.
3.0
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions
biblioteca.ListenOptions.NoDelay
propriedade estava disponível.IConnectionListener
interface foi introduzida Microsoft.AspNetCore.Connections.Abstractions
na biblioteca para expor a funcionalidade mais usada da ...Transport.Abstractions
biblioteca.NoDelay
está agora disponível em opções de transporte (LibuvTransportOptions
e SocketTransportOptions
).SchedulingMode
já não está disponível.ASP.NET Core 3.0 se afastou das APIs "pubternais".
ASP.NET Core
Nenhuma
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.
3.0
Os métodos não foram marcados como Obsolete
.
Os métodos são marcados Obsolete
como .
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.
ASP.NET Core
Microsoft.Extensions.Localization.ResourceManagerWithCultureStringLocalizer
Microsoft.Extensions.Localization.ResourceManagerStringLocalizer.WithCulture
Antes do ASP.NET Core 3.0, DebugLogger
o modificador public
de acesso do era . No ASP.NET Core 3.0, o modificador de acesso mudou para internal
.
3.0
A alteração está a ser feita para:
ConsoleLogger
.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.
ASP.NET Core
Microsoft.Extensions.Logging.Debug.DebugLogger
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.
3.0
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>
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;
});
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:
[ActionName]
atributo para preservar o nome original.MvcOptions.SuppressAsyncSuffixInActionNames
como false
em Startup.ConfigureServices
:services.AddMvc(options =>
{
options.SuppressAsyncSuffixInActionNames = false;
});
ASP.NET Core
Nenhuma
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.
3.0 Pré-visualização 6
Um aplicativo que usa uma biblioteca baseada em 2.2 é compilado com êxito.
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.
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.
ASP.NET Core
Microsoft.AspNetCore.Mvc.JsonResult
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.
3.0
O Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
pacote foi usado para pré-compilar visualizações do MVC Razor.
O SDK do Razor suporta nativamente essa funcionalidade. O Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
pacote não é mais atualizado.
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.
ASP.NET Core
Nenhuma
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.
No ASP.NET Core, os tipos "pubternal" são declarados como public
mas residem em um .Internal
namespace -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.
3.0
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.
Todos esses tipos são atualizados para estarem public
em um namespace suportado ou marcados como internal
.
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
.
ASP.NET Core
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
A partir do ASP.NET Core 3.0, o Microsoft.AspNetCore.Mvc.WebApiCompatShim
pacote não está mais disponível.
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]
.
3.0
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.
ASP.NET Core
Microsoft.AspNetCore.Mvc.WebApiCompatShim
A RazorTemplateEngine
API foi removida e substituída por Microsoft.AspNetCore.Razor.Language.RazorProjectEngine
.
Para discussão, consulte GitHub issue dotnet/aspnetcore#25215.
3.0
Um mecanismo de modelo pode ser criado e usado para analisar e gerar código para arquivos Razor.
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.
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.
RazorProjectEngine projectEngine =
RazorProjectEngine.Create(RazorConfiguration.Default,
RazorProjectFileSystem.Create(@"C:\source\repos\ConsoleApp4\ConsoleApp4"),
builder =>
{
builder.ConfigureClass((document, classNode) =>
{
classNode.ClassName = "MyClassName";
// Can also configure other aspects of the class here.
});
// More configuration can go here
});
RazorProjectItem item = projectEngine.FileSystem.GetItem(
@"C:\source\repos\ConsoleApp4\ConsoleApp4\Example.cshtml",
FileKinds.Legacy);
RazorCodeDocument output = projectEngine.Process(item);
// Things available
RazorSyntaxTree syntaxTree = output.GetSyntaxTree();
DocumentIntermediateNode intermediateDocument =
output.GetDocumentIntermediateNode();
RazorCSharpDocument csharpDocument = output.GetCSharpDocument();
ASP.NET Core
RazorTemplateEngine
RazorTemplateEngineOptions
O suporte para compilação em tempo de execução de visualizações do Razor e Razor Pages foi movido para um pacote separado.
3.0
A compilação em tempo de execução está disponível sem a necessidade de pacotes adicionais.
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.
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:
Adicione uma referência ao Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
pacote.
Atualize o método do Startup.ConfigureServices
projeto para incluir uma chamada para AddRazorRuntimeCompilation
. Por exemplo:
services.AddMvc()
.AddRazorRuntimeCompilation();
ASP.NET Core
Microsoft.AspNetCore.Mvc.Razor.RazorViewEngineOptions
As APIs obsoletas para configurar cookies de sessão foram removidas. Para obter mais informações, consulte aspnet/Announcements#257.
3.0
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;
});
}
ASP.NET Core
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.
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
.
3.0
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:
Newtonsoft.Json
)Microsoft.EntityFrameworkCore.
)Microsoft.CodeAnalysis
)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.
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).Microsoft.AspNetCore.App
. Por exemplo, os seguintes componentes estão disponíveis como pacotes NuGet: 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.
ASP.NET Core
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.
3.0
Os aplicativos podem usar o Microsoft.AspNetCore.All
metapacote para direcionar a Microsoft.AspNetCore.All
estrutura compartilhada no .NET Core.
O .NET Core 3.0 não inclui uma Microsoft.AspNetCore.All
estrutura compartilhada.
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.
ASP.NET Core
Nenhuma
O campo HandshakeProtocol.SuccessHandshakeData foi removido e substituído por um método auxiliar que gera uma resposta de handshake bem-sucedida com um IHubProtocol
arquivo .
3.0
HandshakeProtocol.SuccessHandshakeData
era um public static ReadOnlyMemory<byte>
campo.
HandshakeProtocol.SuccessHandshakeData
foi substituído por um static
GetSuccessfulHandshake(IHubProtocol protocol)
método que retorna um ReadOnlyMemory<byte>
com base no protocolo especificado.
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.
ASP.NET Core
HandshakeProtocol.SuccessHandshakeData
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.
3.0
As APIs estavam disponíveis.
As APIs são removidas.
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.
ASP.NET Core
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.
3.0
HubConnectionContext
tem dois construtores:
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory);
public HubConnectionContext(ConnectionContext connectionContext, TimeSpan keepAliveInterval, ILoggerFactory loggerFactory, TimeSpan clientTimeoutInterval);
Os dois construtores foram removidos e substituídos por um construtor:
public HubConnectionContext(ConnectionContext connectionContext, HubConnectionContextOptions contextOptions, ILoggerFactory loggerFactory)
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);
ASP.NET Core
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.
3.0
O pacote do cliente foi nomeado @aspnet/signalr
.
O pacote do cliente é chamado @microsoft/signalr
.
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
.
ASP.NET Core
Nenhuma
Os métodos UseConnections
e UseSignalR
as classes ConnectionsRouteBuilder
e HubRouteBuilder
são marcados como obsoletos no ASP.NET Core 3.0.
3.0
O roteamento do hub SignalR foi configurado usando UseSignalR
ou UseConnections
.
A antiga maneira de configurar o roteamento foi obsoleta e substituída pelo roteamento de ponto final.
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");
});
ASP.NET Core
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.
3.0
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.
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.
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:
Se estiver a utilizar estes pacotes, atualize as suas aplicações para utilizar a funcionalidade:
Microsoft.AspNetCore.SpaServices.Extensions
No pacote.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.
ASP.NET Core
Microsoft.AspNetCore.NodeServices.HostingModels.INodeInstance
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationException
Microsoft.AspNetCore.NodeServices.HostingModels.NodeInvocationInfo
Microsoft.AspNetCore.NodeServices.HostingModels.NodeServicesOptionsExtensions
Microsoft.AspNetCore.NodeServices.HostingModels.OutOfProcessNodeInstance
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerenderer
Microsoft.AspNetCore.SpaServices.Prerendering.ISpaPrerendererBuilder
Microsoft.AspNetCore.SpaServices.Prerendering.JavaScriptModuleExport
Microsoft.AspNetCore.SpaServices.Prerendering.PrerenderTagHelper
Microsoft.AspNetCore.SpaServices.Prerendering.RenderToStringResult
Microsoft.AspNetCore.SpaServices.Webpack.WebpackDevMiddlewareOptions
Microsoft.Extensions.DependencyInjection.NodeServicesServiceCollectionExtensions
Microsoft.Extensions.DependencyInjection.PrerenderingServiceCollectionExtensions
Microsoft.AspNetCore.SpaServices e Microsoft.AspNetCore.NodeServices não exibirá os logs do console, a menos que o registro em log esteja configurado.
3.0
Microsoft.AspNetCore.SpaServices
e Microsoft.AspNetCore.NodeServices
usado para criar automaticamente um registrador de console quando o registro em log não está configurado.
Microsoft.AspNetCore.SpaServices
e Microsoft.AspNetCore.NodeServices
não exibirá os logs do console, a menos que o registro em log esteja configurado.
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.
ASP.NET Core
Nenhuma
A partir do ASP.NET Core 3.0, o .NET Framework é uma estrutura de destino sem suporte.
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.
3.0
ASP.NET aplicativos principais podem ser executados no .NET Core ou no .NET Framework.
ASP.NET aplicativos principais só podem ser executados no .NET Core.
Efetue uma das seguintes ações:
ASP.NET Core
Nenhuma
Muitas das APIs que retornam versões no .NET Core agora retornam a versão do produto em vez da versão do arquivo.
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 .
3.0
Nenhum. Essa alteração deve tornar a deteção de versão intuitiva em vez de obtusa.
Principais bibliotecas .NET
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.
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:
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.
Principais bibliotecas .NET
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
.
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 .
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.
Principais bibliotecas .NET
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.
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.
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 Infinity
são . Nesse caso, você deve adicionar o código necessário para verificar os valores de vírgula flutuante de PositiveInfinity
e NegativeInfinity
.
Principais bibliotecas .NET
A InvalidAsynchronousStateException classe foi transferida.
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 .
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.
Principais bibliotecas .NET
Nenhum.
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.
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.
3.0
Nenhuma ação é necessária por parte do desenvolvedor.
Principais bibliotecas .NET
A TypeDescriptionProviderAttribute classe foi transferida.
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 .
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.
Windows Forms
Nenhum.
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.
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.
3.0
Reempacote qualquer arquivo zip que exiba esses problemas.
Principais bibliotecas .NET
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.
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.
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.
Principais bibliotecas .NET
Ao chamar um método de extensão que assume um IEnumerable<T>
GroupCollection, você deve desambiguar o tipo usando um cast.
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.
3.0
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);
Principais bibliotecas .NET
Qualquer método de extensão que aceite um IEnumerable<T> é afetado. Por exemplo:
System.Linq.Enumerable
métodos, por exemplo, System.Linq.Enumerable.CountOs 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.
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).
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
Criptografia
O algoritmo de encriptação simétrica padrão usado por EnvelopedCms
mudou de TripleDES para AES-256.
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();
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();
Criptografia
O tamanho mínimo para gerar novas chaves RSA no Linux aumentou de 384 bits para 512 bits.
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.
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.
Criptografia
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.
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.
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.
Criptografia
O CryptoStream.Dispose método, que é usado para concluir CryptoStream
operações, não tenta mais transformar o bloco final durante a leitura.
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.
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.
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.
Criptografia
Alterações significativas do Entity Framework Core
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.
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.
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".
Globalização
Todas as APIs de agrupamento e cultura são afetadas por essa alteração.
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.
3.0
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
ManifestResourceName
LogicalName
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>
MSBuild
N/A
O valor padrão da System.Net.Http.HttpRequestMessage.Version propriedade foi alterado de 2.0 para 1.1.
3.0
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.
Rede
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.
.NET Core 3.0
Windows Presentation Foundation
O tipo de dados ao System.Windows.DataObject arrastar texto de um controle de editor de texto era DataFormats.StringFormat.
O tipo de dados ao System.Windows.DataObject arrastar texto de um controle de editor de texto é DataFormats.Text ou DataFormats.UnicodeText.
Esta mudança é uma mudança comportamental.
A mudança não foi intencional.
Essa alteração foi revertida no .NET 7. Atualize para o .NET 7 ou posterior.
Comentários do .NET
O .NET é um projeto código aberto. Selecione um link para fornecer comentários:
Formação
Módulo
Proteja um aplicativo Web .NET com a estrutura ASP.NET Core Identity - Training
Saiba como adicionar autenticação e autorização a um aplicativo Web .NET usando a estrutura ASP.NET Core Identity.
Documentação
Alterações significativas no .NET Core 3.1 - .NET
Lista as alterações recentes na versão 3.1 do .NET Core e do ASP.NET Core.
Alterações significativas no .NET 5 - .NET
Navegue até as alterações recentes no .NET 5.
Alterações significativas no .NET 6
Navegue até as alterações mais recentes no .NET 6.