ASP.NET Core 3.0 - Quais são as novidades ?

Depois de mais de dois anos desde o lançamento do .NET Core 2.0 em agosto de 2017, o .NET Core 3.0 foi lançado como a próxima versão principal do .NET Core.

Seu uso em produção esta liberado deste julho de 2019, quando foi lançada a Preview 7 do .NET Core 3.0. A próxima versão do suporte a longo prazo (LTS) será o .NET Core 3.1 com previsão para novembro de 2019.

Para desenvolver usando o .NET Core 3.0, você precisa de uma versão atualizada do Visual Studio 2019. Não existe suporte para ele no Visual Studio 2017.

Como complemento do .NET Core 3.0, o .NET Standard 2.1 também está sendo lançado. Em comparação com o .NET Standard 2.0, o .NET Standard 2.1 inclui novas classes e métodos que foram adicionados ao .NET Core 3.0, possibilitando que as bibliotecas de classes de plataforma cruzada também os usem.

Apesar disso, ainda é uma boa ideia escrever suas bibliotecas para o .NET Standard 2.0 sempre que possível, pois isso as tornará disponível para diferentes runtimes da plataforma .NET, como por exemplo, o .NET Framework que não oferece suporte ao .NET Standard 2.1 e versões anteriores do .NET Core.

O .NET Core 3.0 é o primeiro runtime da plataforma .NET a oferecer suporte total à versão 8.0 da linguagem C#.

As chamadas Ferramentas Globais do .NET Core também podem ser instaladas como ferramentas locais no .NET Core 3.0. Essas ferramentas são utilitários de linha de comando que podem ser facilmente instalados e executados usando o comando dotnet.

Eles foram originalmente introduzidos com o .NET Core 2.1, mas só podiam ser instalados globalmente, o que os tornou sempre disponíveis na linha de comando.

No .NET Core 3.0, eles também podem ser instalados localmente como parte de um projeto ou solução do .NET Core e, como tal, estarão disponíveis para todos os desenvolvedores que trabalham no mesmo repositório de código.

Recursos específicos do Windows

Desde que o desenvolvimento do .NET framework parou com a versão 4.8, o .NET Core 3.0 tem um grande foco nos recursos específicos do Windows que anteriormente não eram suportados.

O objetivo é tornar o .NET Core um caminho a seguir para desenvolvedores do Windows que atualmente usam o .NET framework. Ao contrário de quase todas as outras partes do .NET Core até agora, esses novos recursos não serão multiplataforma e só funcionarão no Windows porque eles dependem muito dos serviços fornecidos pelo sistema operacional.

1 - Windows Desktop

O novo recurso mais proeminente no .NET Core 3.0 é o suporte ao desenvolvimento de aplicativos desktop para Windows usando o Windows Forms ou o WPF (Windows Presentation Foundation).

Ambos os modelos de aplicativos são totalmente compatíveis com seus equivalentes do .NET Framework. Portanto, qualquer aplicativo existente do .NET Framework que os utilize pode ser portado para o .NET Core, a menos que dependa de algum outro recurso que não seja suportado no .NET Core, como o .NET Remoting ou recursos avançados de WCF, por exemplo.

A portabilidade de aplicativos .NET Framework existentes para o .NET Core não é simples e requer algumas alterações no código-fonte e testes posteriores. Por isso, faz sentido apenas para aplicativos que ainda estão sendo desenvolvidos ativamente.

Além disso, os designers do Visual Studio 2019 ainda não funcionam em projetos do .NET Core. Para usá-los, é necessário um projeto .NET Framework complementar que compartilhe os arquivos com o projeto .NET Core. Esta solução alternativa é necessária apenas temporariamente, pois o suporte para designers será adicionado a versões futuras do Visual Studio 2019.

Embora o Windows Forms e o WPF no .NET Core 3.0 sejam apenas portas do .NET framework, há dois novos recursos que vale a pena mencionar:

O Windows Forms aprimorou o suporte para telas high DPI. Como não é totalmente compatível com o comportamento de high DPI no .NET Framework, requer testes adicionais e alterações potenciais no código-fonte.

O Windows Forms e o WPF suportam ilhas XAML, ou seja, a capacidade de hospedar controles UWP (Universal Windows Platform) dentro de um aplicativo Windows Forms ou WPF. Isso é particularmente útil para (embora não limitado a) hospedar controles UWP, como WebView, Map Control, MediaPlayerElement e InkCanvas.

Para simplificar a implantação dos aplicativos desktop do Windows desenvolvidos no .NET Core 3.0, o novo formato de pacote de aplicativos MSIX pode ser usado. É um sucessor das tecnologias de implantação anteriores do Windows, como MSI, APPX e ClickOnce, que podem ser usadas para publicar os aplicativos na Microsoft Store ou para distribuí-los separadamente. Um modelo dedicado de Projeto de Empacotamento de Aplicativo do Windows no Visual Studio está disponível para gerar o pacote de distribuição para o seu aplicativo.

2 - Suporte para componentes COM

A importância dos componentes COM (Component Object Model) diminuiu com o aumento da adoção do .NET framework. No entanto, ainda existem aplicativos que dependem dele, por exemplo a automação em vários produtos do Microsoft Office.

Os aplicativos .NET Core 3.0 no Windows podem atuar nas duas funções COM:

1- Como cliente COM, a ativação de componentes COM existentes, por exemplo, para automatizar um aplicativo do Microsoft Office.

2- Como servidor COM, implementando um componente COM que pode ser usado por outros clientes COM.

Entity Framework

O Entity Framework é a biblioteca de acesso a dados da Microsoft para .NET. Como parte do .NET Core, uma versão completamente nova do Entity Framework foi desenvolvida a partir do zero : o Entity Framework Core.

Embora sua API pareça familiar para quem já usou o Entity Framework original, ela não é compatível com o código-fonte nem possui um recurso equivalente a ele. Portanto, qualquer código existente usando o Entity Framework precisa ser reescrito para usar o Entity Framework Core.

Para facilitar a portabilidade de aplicativos Windows existentes usando o Entity Framework para .NET Core, o .NET Core 3.0 inclui uma porta do Entity Framework original, além de uma nova versão do Entity Framework Core.

Entity Framework 6.3 para .NET Core

A versão do Entity Framework 6.3 no .NET Core se destina principalmente à portabilidade de aplicativos existentes. Novos aplicativos devem usar o Entity Framework Core, que ainda está em desenvolvimento ativo.

Atualmente, as ferramentas para o Entity Framework são suportadas apenas no Visual Studio 2019 no Windows. O suporte do designer será adicionado em uma atualização posterior do Visual Studio 2019. Até lá, os modelos só podem ser editados a partir de um projeto .NET Framework semelhante à abordagem necessária para os designers do Windows Forms e WPF.

No entanto, os aplicativos desenvolvidos com o Entity Framework 6.3 para .NET Core podem ser executados em qualquer plataforma, o que o torna adequado para transportar não apenas aplicativos de área de trabalho do Windows, mas também aplicativos da Web, tornando-os multiplataforma no processo.

Infelizmente, novos provedores são necessários para o .NET Core. Atualmente, apenas o provedor do SQL Server está disponível. Não há suporte para tipos espaciais do SQL Server e o SQL Server Compact está disponível ou planejado.

Entity Framework Core 3.0

Uma nova versão do Entity Framework Core também está incluída no .NET Core 3.0. Entre seus novos recursos, os mais importantes são os aprimoramentos no LINQ, que o tornam mais robusto e eficiente, porque agora grandes partes das consultas são executadas no servidor de banco de dados e não no aplicativo cliente.

Como parte dessa alteração, a avaliação de consultas no lado cliente como fallback quando a geração de consultas no servidor falhou, foi removida.

Somente a projeção da parte Select final da consulta ainda pode ser executada no cliente. Isso pode quebrar aplicativos existentes. Portanto, é necessário teste completo dos aplicativos existentes ao atualizar para o Entity Framework Core 3.0.

Além disso, o Entity Framework Core 3.0 agora inclui suporte ao Cosmos DB (implementado em sua API SQL) e tira proveito dos novos recursos de linguagem no C# 8.0 (fluxos assíncronos). Como resultado, agora ele tem como alvo o .NET Standard 2.1 em vez do .NET Standard 2.0 e, portanto, não pode mais ser usado com o .NET Framework ou versões mais antigas do .NET Core.

ASP.NET Core

O ASP.NET Core é provavelmente o modelo de aplicativo mais usado no .NET Core, pois todos os tipos de aplicativos e serviços da Web são baseados nele. Como o Entity Framework Core, sua versão mais recente funciona apenas no .NET Core 3.0 e não é suportada no .NET framework.

Para tornar os aplicativos menores por padrão e reduzir o número de dependências, várias bibliotecas foram removidas do SDK básico e agora devem ser adicionadas manualmente quando necessário:

O roteamento endpoint, que foi introduzido pela primeira vez no .NET Core 2.2, foi aprimorado ainda mais. Sua principal vantagem é uma melhor interação entre o roteamento e o middleware. Agora, a rota efetiva é determinada antes da execução do middleware.

Isso permite que o middleware inspecione a rota durante seu processamento. Isso é especialmente útil para implementar autorização, configuração CORS e funcionalidades transversais semelhantes às do middleware.

Provavelmente, o novo recurso mais aguardado no ASP.NET Core 3.0 é o Blazor. No .NET Core 3.0, apenas o Blazor do lado do servidor está pronto para produção.

O Blazor possibilita a interatividade do lado do cliente em um navegador sem nenhum código JavaScript. Se necessário, o JavaScript ainda pode ser chamado (por exemplo, para usar APIs do navegador, como geolocalização e notificações).

Todo o outro código é escrito em .NET. No Blazor do lado do servidor, esse código é executado no servidor e manipula a marcação no navegador usando o SignalR. Para que isso funcione, é necessária uma conexão constante entre o navegador e o servidor. O cenário offline não é suportado.

O Blazor do lado do cliente ainda está em Previw e será lançado em um momento não anunciado no futuro. Como o nome indica, todo o código é executado no cliente no navegador, como nos SPAs baseados em JavaScript (aplicativos de página única). O código .NET é compilado no WebAssembly para que os navegadores possam executá-lo.

Worker Service Template

O Worker Service é um novo modelo de projeto para um aplicativo ASP.NET Core que hospeda processos em segundo plano de longa execução em vez de responder a solicitações de clientes. Existem classes de suporte disponíveis para integrar melhor esses aplicativos ao sistema operacional de hospedagem:

Suporte para gRPC

O gRPC é um protocolo RPC (chamada de procedimento remoto) moderno e de alto desempenho, desenvolvido pelo Google e suportado em vários idiomas e em várias plataformas. Ele usa HTTP/2 para transferência e Buffers de Protocolo (também conhecido como Protobuf) para serialização binária fortemente tipada. Isso a torna uma ótima alternativa ao WCF (Windows Communication Foundation), que possui suporte limitado apenas no .NET Core:

Embora a Web API possa ser usada para implementar um serviço REST, o gRPC é mais adequado para cenários de chamada de procedimento remoto, que foram o caso de uso mais comum para serviços WCF. Seus benefícios de desempenho são mais óbvios quando são necessárias muitas chamadas RPC e grandes cargas úteis.

Embora uma biblioteca de gRPC para C# esteja disponível há algum tempo, o .NET Core 3.0 e o Visual Studio 2019 agora incluem suporte de primeira classe com modelos de projeto e ferramentas para facilitar o desenvolvimento.

Alterações no modelo de implantação

O .NET Core suporta dois modelos de implantação:

As implantações dependentes de framework exigem que uma versão compatível do runtime do .NET Core seja instalada no computador de destino. Isso permite que o pacote de implantação seja menor porque precisa conter apenas o código do aplicativo compilado e dependências de terceiros. Todos eles são independentes de plataforma, portanto, um único pacote de implantação pode ser criado para todas as plataformas.

As implantações independentes incluem adicionalmente o runtime completo do .NET Core. Dessa forma, o computador de destino não precisa ter oruntime do .NET Core pré-instalado. Como resultado, o pacote de implantação é muito maior e específico para uma plataforma.

Antes do .NET Core 3.0, apenas implantações independentes incluíam um executável. As implantações dependentes de framework precisavam ser executadas com a ferramenta de linha de comando dotnet. No .NET Core 3.0, as implantações dependentes framework também podem incluir um executável para uma plataforma de destino específica.

Além disso, no .NET Core 3.0, implantações autônomas suportam o assembly trimming ou corte de assembly. Isso pode ser usado para diminuir o pacote de implantação, incluindo apenas os assemblies do runtime do .NET Core que são usados pelo aplicativo. No entanto, os assemblies acessados dinamicamente (através do Reflection) não podem ser detectadas automaticamente, o que pode causar a quebra do aplicativo devido a uma assembly ausente.

O projeto pode ser configurado manualmente para incluir esses assemblies, mas essa abordagem exige que o pacote de implantação seja completamente testado para garantir que nenhum assembly necessário esteja faltando.

Melhorias no tempo de inicialização

No campo do desempenho, os seguintes recursos se concentram na redução do tempo de inicialização do aplicativo:

O compilador JIT (just-in-time) de duas camadas está disponível há algum tempo, mas com o .NET Core 3.0, ele é ativado por padrão, embora ainda possa ser desativado. Para melhorar o tempo de inicialização, o JIT de duas camadas executa uma compilação de qualidade mais rápida primeiro e faz uma segunda passagem mais lenta com qualidade total depois, quando o aplicativo já estiver em execução.

Imagens prontas para execução introduzem a compilação AOT (antecipada) no .NET Core. Esses pacotes de implantação são maiores porque incluem um binário nativo ao lado dos assemblies regulares de IL (idioma intermediário) que ainda são necessários. Como não há necessidade de compilação JIT antes da inicialização, o aplicativo pode iniciar ainda mais rápido. Por enquanto, não há suporte à segmentação cruzada para a criação de imagens prontas para execução, portanto, elas devem ser construídas na plataforma de destino.

Conclusão

Um exame mais detalhado do .NET Core 3.0 deixa claro que o .NET Core está amadurecendo.

Como não há mais desenvolvimento planejado para a .NET Framework, o .NET Core agora é a implementação .NET mais avançada. É multiplataforma e mais eficiente que a .NET Framework.

A maioria dos recursos do .NET framework agora também estão incluídos no .NET Core.

Para os recursos que não estão planejados para serem suportados no .NET Core, existem alternativas disponíveis: para Web Forms, há o Blazor; para WCF e .NET Remoting, há a Web API e gRPC; para o Workflow Foundation, existem os Aplicativos de Lógica do Azure.

Agora é a hora de começar a portar os projetos da estrutura .NET que você ainda está desenvolvendo ativamente, se ainda não o fez. Dessa forma, você estará pronto quando o .NET 5 chegar, como o runtime unificado do .NET, até o final de 2020.

"Louvai ao SENHOR, porque ele é bom; porque a sua benignidade dura para sempre.
Louvai ao Deus dos deuses; porque a sua benignidade dura para sempre.
Louvai ao Senhor dos senhores; porque a sua benignidade dura para sempre."
Salmos 136:1-3