Novidades no ASP.NET Core 3.0

Este artigo destaca as alterações mais significativas no ASP.NET Core 3.0 com links para a documentação relevante.

Blazor

Blazoré uma nova estrutura no ASP.NET Core para criar interface do usuário da Web interativa do lado do cliente com o .NET:

  • Crie interfaces do usuário interativas avançadas usando C# em vez de JavaScript.
  • Compartilhe a lógica de aplicativo do lado do cliente e do servidor gravada no .NET.
  • Renderize a interface do usuário, como HTML e CSS para suporte amplo de navegadores, incluindo navegadores móveis.

Blazor cenários com suporte da estrutura:

  • Componentes de interface do usuário reutilizáveis Razor (componentes)
  • Roteamento do lado do cliente
  • Layouts de componente
  • Suporte para injeção de dependência
  • Formulários e validação
  • Fornecer Razor componentes em Razor bibliotecas de classes
  • Interoperabilidade do JavaScript

Para obter mais informações, consulte Introdução ao ASP.NET Core Blazor.

Blazor Server

Blazor desacopla a lógica de renderização de componentes de como as atualizações da interface do usuário são aplicadas. Blazor Serverfornece suporte para hospedar Razor componentes no servidor em um ASP.NET Core aplicativo. As atualizações da interface do usuário são tratadas em uma SignalR conexão. Blazor Servertem suporte no ASP.NET Core 3.0.

Blazor WebAssembly (versão prévia)

Blazor Os aplicativos também podem ser executados diretamente no navegador usando um runtime do .NET baseado em WebAssembly. Blazor WebAssemblyestá em versão prévia e não tem suporte no ASP.NET Core 3.0. Blazor WebAssemblyterá suporte em uma versão futura do ASP.NET Core.

Componentes Razor

Blazor os aplicativos são construídos com base em componentes. Os componentes são partes autossu contidas da interface do usuário, como uma página, uma caixa de diálogo ou um formulário. Os componentes são classes normais do .NET que definem a lógica de renderização da interface do usuário e manipuladores de eventos do lado do cliente. Você pode criar aplicativos Web interativos e rich sem JavaScript.

Os Blazor componentes no normalmente são baseados em Razor sintaxe, uma combinação natural de HTML e C#. Razor os componentes são Razor semelhantes às exibições pages e MVC, já que ambos usam Razor . Ao contrário de páginas e exibições, que se baseiam em um modelo de solicitação-resposta, os componentes são usados especificamente para lidar com a composição da interface do usuário.

gRPC

gRPC:

  • É uma estrutura RPC (chamada de procedimento remoto) popular e de alto desempenho.

  • Oferece uma abordagem de contrato de primeira opinião para o desenvolvimento de API.

  • Usa tecnologias modernas como:

    • HTTP/2 para transporte.
    • Buffers de protocolo como a linguagem de descrição da interface.
    • Formato de serialização binária.
  • Fornece recursos como:

    • Autenticação
    • Fluxo bidirecional e controle de fluxo.
    • Cancelamento e tempos-tempo.

A funcionalidade gRPC no ASP.NET Core 3.0 inclui:

  • Grpc.AspNetCore:uma estrutura ASP.NET Core para hospedar serviços gRPC. O gRPC no ASP.NET Core integra-se aos recursos ASP.NET Core padrão, como registro em log, DI (injeção de dependência), autenticação e autorização.
  • Grpc.Net.Client:um cliente gRPC para .NET Core que se baseia no conhecido HttpClient .
  • Grpc.Net.ClientFactory:integração do cliente gRPC ao HttpClientFactory .

Para obter mais informações, consulte Introdução ao gRPC no .NET.

SignalR

Consulte Atualizar código SignalR para obter instruções de migração. SignalR agora usa System.Text.Json para serializar/desseerializar mensagens JSON. Consulte Alternar para Newtonsoft.Jspara obter instruções para restaurar o Newtonsoft.Json serializador baseado em .

Nos clientes JavaScript e .NET para SignalR , foi adicionado suporte para reconexão automática. Por padrão, o cliente tenta se reconectar imediatamente e tentar novamente após 2, 10 e 30 segundos, se necessário. Se o cliente se reconectar com êxito, ele receberá uma nova ID de conexão. A reconexão automática é aceitação:

const connection = new signalR.HubConnectionBuilder()
    .withUrl("/chathub")
    .withAutomaticReconnect()
    .build();

Os intervalos de reconexão podem ser especificados passando uma matriz de durações baseadas em milissegundos:

.withAutomaticReconnect([0, 3000, 5000, 10000, 15000, 30000])
//.withAutomaticReconnect([0, 2000, 10000, 30000]) The default intervals.

Uma implementação personalizada pode ser passada para controle total dos intervalos de reconexão.

Se a reconexão falhar após o último intervalo de reconexão:

  • O cliente considera que a conexão está offline.
  • O cliente para de tentar se reconectar.

Durante as tentativas de reconexão, atualize a interface do usuário do aplicativo para notificar o usuário de que a reconexão está sendo tentada.

Para fornecer comentários da interface do usuário quando a conexão é interrompida, a API do cliente foi SignalR expandida para incluir os seguintes manipuladores de eventos:

  • onreconnecting: oferece aos desenvolvedores a oportunidade de desabilitar a interface do usuário ou de permitir que os usuários saibam que o aplicativo está offline.
  • onreconnected: oferece aos desenvolvedores a oportunidade de atualizar a interface do usuário depois que a conexão é restabelecida.

O código a seguir onreconnecting usa para atualizar a interface do usuário ao tentar se conectar:

connection.onreconnecting((error) => {
    const status = `Connection lost due to error "${error}". Reconnecting.`;
    document.getElementById("messageInput").disabled = true;
    document.getElementById("sendButton").disabled = true;
    document.getElementById("connectionStatus").innerText = status;
});

O código a seguir onreconnected usa para atualizar a interface do usuário na conexão:

connection.onreconnected((connectionId) => {
    const status = `Connection reestablished. Connected.`;
    document.getElementById("messageInput").disabled = false;
    document.getElementById("sendButton").disabled = false;
    document.getElementById("connectionStatus").innerText = status;
});

SignalR 3.0 e posterior fornece um recurso personalizado para manipuladores de autorização quando um método de hub requer autorização. O recurso é uma instância do HubInvocationContext . O HubInvocationContext inclui o:

  • HubCallerContext
  • Nome do método de hub que está sendo invocado.
  • Argumentos para o método de hub.

Considere o exemplo a seguir de um aplicativo de sala de chat permitindo a entrada de várias organizações por meio Azure Active Directory. Qualquer pessoa com um conta Microsoft pode entrar no chat, mas somente os membros da organização própria podem proibir usuários ou exibir históricos de chat dos usuários. O aplicativo pode restringir determinada funcionalidade de usuários específicos.

public class DomainRestrictedRequirement :
    AuthorizationHandler<DomainRestrictedRequirement, HubInvocationContext>,
    IAuthorizationRequirement
{
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
        DomainRestrictedRequirement requirement,
        HubInvocationContext resource)
    {
        if (context.User?.Identity?.Name == null)
        {
            return Task.CompletedTask;
        }

        if (IsUserAllowedToDoThis(resource.HubMethodName, context.User.Identity.Name))
        {
            context.Succeed(requirement);
        }

        return Task.CompletedTask;
    }

    private bool IsUserAllowedToDoThis(string hubMethodName, string currentUsername)
    {
        if (hubMethodName.Equals("banUser", StringComparison.OrdinalIgnoreCase))
        {
            return currentUsername.Equals("bob42@jabbr.net", StringComparison.OrdinalIgnoreCase);
        }

        return currentUsername.EndsWith("@jabbr.net", StringComparison.OrdinalIgnoreCase));
    }
}

No código anterior, DomainRestrictedRequirement serve como um IAuthorizationRequirement personalizado. Como o HubInvocationContext parâmetro de recurso está sendo passado, a lógica interna pode:

  • Inspecione o contexto no qual o Hub está sendo chamado.
  • Tomar decisões sobre como permitir que o usuário execute métodos individuais do Hub.

Os métodos de Hub individuais podem ser marcados com o nome da política que o código verifica em tempo de executar. À medida que os clientes tentam chamar métodos de Hub individuais, o DomainRestrictedRequirement manipulador executa e controla o acesso aos métodos. Com base na maneira como os DomainRestrictedRequirement controles acessam:

  • Todos os usuários conectados podem chamar o SendMessage método .
  • Somente os usuários que entraram com um @jabbr.net endereço de email podem exibir históricos dos usuários.
  • bob42@jabbr.net pode proibir usuários da sala de chat.
[Authorize]
public class ChatHub : Hub
{
    public void SendMessage(string message)
    {
    }

    [Authorize("DomainRestricted")]
    public void BanUser(string username)
    {
    }

    [Authorize("DomainRestricted")]
    public void ViewUserHistory(string username)
    {
    }
}

A criação DomainRestricted da política pode envolver:

  • Em Startup.cs, adicionando a nova política.
  • Forneça o requisito DomainRestrictedRequirement personalizado como um parâmetro.
  • DomainRestrictedRegistrar-se com o middleware de autorização.
services
    .AddAuthorization(options =>
    {
        options.AddPolicy("DomainRestricted", policy =>
        {
            policy.Requirements.Add(new DomainRestrictedRequirement());
        });
    });

SignalR os hubs usam o Roteamento de Ponto de Extremidade. SignalR A conexão de hub foi feita explicitamente:

app.UseSignalR(routes =>
{
    routes.MapHub<ChatHub>("hubs/chat");
});

Na versão anterior, os desenvolvedores precisavam ligar controladores, páginas e hubs em uma Razor variedade de locais. A conexão explícita resulta em uma série de segmentos de roteamento quase idênticos:

app.UseSignalR(routes =>
{
    routes.MapHub<ChatHub>("hubs/chat");
});

app.UseRouting(routes =>
{
    routes.MapRazorPages();
});

SignalR Os hubs 3.0 podem ser roteados por meio do roteamento de ponto de extremidade. Com o roteamento de ponto de extremidade, normalmente todo o roteamento pode ser configurado em UseRouting :

app.UseRouting(routes =>
{
    routes.MapRazorPages();
    routes.MapHub<ChatHub>("hubs/chat");
});

ASP.NET Core 3.0 SignalR adicionado:

Streaming de cliente para servidor. Com o streaming de cliente para servidor, os métodos do lado do servidor podem assumir instâncias de um IAsyncEnumerable<T> ou ChannelReader<T> . No exemplo de C# a seguir, o UploadStream método no Hub receberá um fluxo de cadeias de caracteres do cliente:

public async Task UploadStream(IAsyncEnumerable<string> stream)
{
    await foreach (var item in stream)
    {
        // process content
    }
}

Os aplicativos cliente .NET podem passar uma IAsyncEnumerable<T> ChannelReader<T> instância ou como o stream argumento do UploadStream método de Hub acima.

Depois que o for loop for concluído e a função local sair, a conclusão do fluxo será enviada:

async IAsyncEnumerable<string> clientStreamData()
{
    for (var i = 0; i < 5; i++)
    {
        var data = await FetchSomeData();
        yield return data;
    }
}

await connection.SendAsync("UploadStream", clientStreamData());

Os aplicativos cliente JavaScript usam o SignalR Subject (ou um assunto RxJS) para o stream argumento do UploadStream método de Hub acima.

let subject = new signalR.Subject();
await connection.send("StartStream", "MyAsciiArtStream", subject);

O código JavaScript pode usar o subject.next método para lidar com cadeias de caracteres à medida que elas são capturadas e prontas para serem enviadas ao servidor.

subject.next("example");
subject.complete();

Usando um código como os dois trechos anteriores, as experiências de streaming em tempo real podem ser criadas.

Nova serialização JSON

o ASP.NET Core 3,0 agora usa System.Text.Json por padrão para serialização JSON:

  • Lê e grava JSON de forma assíncrona.
  • É otimizado para texto UTF-8.
  • Geralmente um desempenho maior do que o Newtonsoft.Json .

para adicionar o Json.NET ao ASP.NET Core 3,0, consulte adicionar Newtonsoft.Jssuporte ao formato Json baseado em.

Novas Razor diretivas

A lista a seguir contém novas Razor diretivas:

  • @attribute: A @attribute diretiva aplica o atributo fornecido à classe da página ou exibição gerada. Por exemplo, @attribute [Authorize].
  • @implements: A @implements diretiva implementa uma interface para a classe gerada. Por exemplo, @implements IDisposable.

IdentityO Server4 dá suporte à autenticação e autorização para APIs Web e SPAs

o ASP.NET Core 3,0 oferece autenticação em aplicativos de página única (SPAs) usando o suporte para autorização da API web. ASP.NET Core Identitypara autenticar e armazenar usuários, é combinado com Identity Server4 para implementar o OpenID Conexão.

IdentityServer4 é um OpenID Conexão e a estrutura OAuth 2,0 para ASP.NET Core 3,0. Ele habilita os seguintes recursos de segurança:

  • AaaS (autenticação como serviço)
  • Logon único/logoff (SSO) em vários tipos de aplicativos
  • Controle de acesso para APIs
  • Gateway de Federação

Para obter mais informações, consulte a Identity documentação do Server4 ou autenticação e autorização para Spas.

Autenticação de certificado e Kerberos

A autenticação de certificado requer:

  • Configurando o servidor para aceitar certificados.
  • Adicionar o middleware de autenticação no Startup.Configure .
  • Adicionando o serviço de autenticação de certificado no Startup.ConfigureServices .
public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(
        CertificateAuthenticationDefaults.AuthenticationScheme)
            .AddCertificate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

As opções de autenticação de certificado incluem a capacidade de:

  • Aceite certificados autoassinados.
  • Verificar revogação de certificado.
  • Verifique se o certificado proffered tem os sinalizadores de uso corretos.

Uma entidade de usuário padrão é construída a partir das propriedades do certificado. A entidade de usuário contém um evento que permite complementar ou substituir a entidade de segurança. Para obter mais informações, consulte Configurar a autenticação de certificado ASP.NET Core.

a autenticação Windows foi estendida para Linux e macOS. em versões anteriores, Windows autenticação era limitada ao IIS e HTTP.sys. no ASP.NET Core 3,0, Kestrel o tem a capacidade de usar negotiate, Kerberose NTLM em Windows, Linux e macOS para hosts Windows ingressados no domínio. Kestrelo suporte desses esquemas de autenticação é fornecido pelo pacote Microsoft. AspNetCore. authentication. negotiate NuGet . Assim como acontece com os outros serviços de autenticação, configure o aplicativo de autenticação de todo e configure o serviço:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication(NegotiateDefaults.AuthenticationScheme)
        .AddNegotiate();
    // Other service configuration removed.
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseAuthentication();
    // Other app configuration removed.
}

Requisitos do host:

  • hosts de Windows devem ter nomes de entidade de serviço (SPNs) adicionados à conta de usuário que hospeda o aplicativo.
  • Os computadores Linux e macOS devem ser ingressados no domínio.
    • Os SPNs devem ser criados para o processo da Web.
    • Os arquivos keytab devem ser gerados e configurados no computador host.

Para obter mais informações, consulte Configurar a autenticação do Windows no ASP.NET Core.

Alterações de modelo

Os modelos de interface do usuário da Web ( Razor páginas, MVC com controlador e exibições) têm o seguinte removido:

o modelo de Angular atualizado para usar o Angular 8.

O Razor modelo de biblioteca de classes (RCL) usa como padrão o Razor desenvolvimento de componentes por padrão. uma nova opção de modelo no Visual Studio fornece suporte de modelo para páginas e exibições. Ao criar um RCL a partir do modelo em um shell de comando, passe a --support-pages-and-views opção ( dotnet new razorclasslib --support-pages-and-views ).

Host Genérico

os modelos ASP.NET Core 3,0 usam Host genérico do .NET ASP.NET Core . Versões anteriores usadas WebHostBuilder . o uso do Host genérico do .net Core ( HostBuilder ) fornece uma melhor integração de aplicativos ASP.NET Core com outros cenários de servidor que não são específicos da web. Para obter mais informações, consulte HostBuilder substitui WebHostBuilder.

Configuração do host

antes do lançamento do ASP.NET Core 3,0, as variáveis de ambiente prefixadas com ASPNETCORE_ foram carregadas para a configuração de host do host da Web. No 3,0, AddEnvironmentVariables é usado para carregar variáveis de ambiente prefixadas com DOTNET_ para a configuração de host com CreateDefaultBuilder .

Alterações na injeção de construtor de inicialização

O host genérico só dá suporte aos seguintes tipos para Startup injeção de construtor:

Todos os serviços ainda podem ser injetados diretamente como argumentos para o Startup.Configure método. Para obter mais informações, consulte injeção de construtor de inicialização de restrict de host genérico (ASPNET/comunicados #353).

Kestrel

  • Kestrel a configuração foi atualizada para a migração para o host genérico. No 3,0, Kestrel o é configurado no Web host Builder fornecido pelo ConfigureWebHostDefaults .
  • os adaptadores de conexão foram removidos do Kestrel e substituídos pelo middleware de conexão, que é semelhante ao middleware HTTP no pipeline de ASP.NET Core, mas para conexões de nível inferior.
  • A Kestrel camada de transporte foi exposta como uma interface pública no Connections.Abstractions .
  • A ambiguidade entre cabeçalhos e trailers foi resolvida movendo os cabeçalhos à direita para uma nova coleção.
  • APIs de e/s síncronas, como HttpRequest.Body.Read , são uma fonte comum de consumo de thread que leva a falhas de aplicativo. No 3,0, AllowSynchronousIO é desabilitado por padrão.

Para obter mais informações, consulte Migrar do ASP.NET Core 2.2 para 3.0.

HTTP/2 habilitado por padrão

O HTTP/2 é habilitado por padrão no Kestrel para pontos de extremidade HTTPS. O suporte a HTTP/2 para IIS ou HTTP.sys é habilitado quando suportado pelo sistema operacional.

EventCounters na solicitação

A hospedagem EventSource, Microsoft.AspNetCore.Hosting , emite os seguintes novos EventCounter tipos relacionados a solicitações de entrada:

  • requests-per-second
  • total-requests
  • current-requests
  • failed-requests

Roteamento de ponto de extremidade

O roteamento de ponto de extremidade, que permite que as estruturas (por exemplo, MVC) funcionem bem com o middleware, seja aprimorado:

  • A ordem do middleware e dos pontos de extremidade é configurável no pipeline de processamento de solicitação do Startup.Configure .
  • os pontos de extremidade e o middleware compõem-se bem com outras tecnologias baseadas em ASP.NET Core, como verificações de integridade.
  • Os pontos de extremidade podem implementar uma política, como CORS ou autorização, tanto no middleware quanto no MVC.
  • Filtros e atributos podem ser colocados em métodos em controladores.

Para obter mais informações, consulte Roteamento no ASP.NET Core.

Verificações de Integridade

As verificações de integridade usam o roteamento de ponto de extremidade com o host genérico. No Startup.Configure , chame MapHealthChecks no construtor de ponto de extremidade com a URL do ponto de extremidade ou o caminho relativo:

app.UseEndpoints(endpoints =>
{
    endpoints.MapHealthChecks("/health");
});

Os pontos de extremidade de verificações de integridade podem:

  • Especifique um ou mais hosts/portas permitidos.
  • Exigir autorização.
  • Exigir CORS.

Para obter mais informações, consulte os seguintes artigos:

Pipes em HttpContext

Agora é possível ler o corpo da solicitação e gravar o corpo da resposta usando a System.IO.Pipelines API. O HttpRequest.BodyReader property fornece um PipeReader que pode ser usado para ler o corpo da solicitação. O HttpResponse.BodyWriter property fornece um PipeWriter que pode ser usado para gravar o corpo da resposta. HttpRequest.BodyReader é um problema do HttpRequest.Body fluxo. HttpResponse.BodyWriter é um problema do HttpResponse.Body fluxo.

Relatório de erros aprimorado no IIS

Erros de inicialização ao hospedar ASP.NET Core aplicativos no IIS agora produzem dados de diagnóstico mais completos. Esses erros são relatados ao log de Windows log de eventos com rastreamentos de pilha sempre que aplicável. Além disso, todos os avisos, erros e exceções sem correção são registrados no log de Windows eventos.

Serviço de Trabalho e SDK de Trabalho

O .NET Core 3.0 apresenta o novo modelo de aplicativo do Serviço de Trabalho. Esse modelo fornece um ponto de partida para escrever serviços de execução longa no .NET Core.

Para obter mais informações, consulte:

Aprimoramentos de middleware de headers encaminhados

Nas versões anteriores do ASP.NET Core, chamar e era problemático quando implantado em um Linux do Azure ou atrás de qualquer proxy reverso diferente UseHsts UseHttpsRedirection do IIS. A correção para versões anteriores está documentada em Encaminhar o esquema para Linux e proxies reversos não IIS.

Esse cenário é corrigido no ASP.NET Core 3.0. O host habilita o Middleware de Headers Encaminhados quando a ASPNETCORE_FORWARDEDHEADERS_ENABLED variável de ambiente é definida como true . ASPNETCORE_FORWARDEDHEADERS_ENABLED é definido como true em nossas imagens de contêiner.

Melhorias de desempenho

ASP.NET Core 3.0 inclui muitas melhorias que reduzem o uso de memória e melhoram a taxa de transferência:

  • Redução no uso de memória ao usar o contêiner de injeção de dependência interna para serviços com escopo.
  • Redução nas alocações em toda a estrutura, incluindo cenários de middleware e roteamento.
  • Redução no uso de memória para conexões WebSocket.
  • Melhorias de taxa de transferência e redução de memória para conexões HTTPS.
  • Novo serializador JSON otimizado e totalmente assíncrono.
  • Redução no uso de memória e melhorias na taxa de transferência na análise de formulário.

ASP.NET Core 3.0 é executado somente no .NET Core 3.0

A partir ASP.NET Core 3.0, o .NET Framework não é mais uma estrutura de destino com suporte. Os projetos destinados .NET Framework podem continuar de maneira totalmente suportada usando a versão ltS do .NET Core 2.1 LTS. A maioria ASP.NET Core pacotes relacionados ao 2.1.x terá suporte indefinidamente, além do período LTS de três anos para o .NET Core 2.1.

Para obter informações de migração, consulte Porportar seu código .NET Framework para o .NET Core.

Usar a estrutura ASP.NET Core compartilhada

O ASP.NET Core estrutura compartilhada 3.0, contida no metapacote Microsoft.AspNetCore.App, não requer mais um elemento explícito no arquivo <PackageReference /> de projeto. A estrutura compartilhada é referenciada automaticamente ao usar Microsoft.NET.Sdk.Web o SDK no arquivo de projeto:

<Project Sdk="Microsoft.NET.Sdk.Web">

Assemblies removidos da estrutura ASP.NET Core compartilhada

Os assemblies mais importantes removidos da estrutura compartilhada ASP.NET Core 3.0 são:

Para ver uma lista completa dos assemblies removidos da estrutura compartilhada, consulte Assemblies sendo removidos do Microsoft.AspNetCore.App 3.0. Para obter mais informações sobre a motivação para essa alteração, consulte Alterações significativas no Microsoft.AspNetCore.App no 3.0 e Uma primeira análise das alterações que vêm no ASP.NET Core 3.0.