Migração .NET Framework para o .NET Core

Este artigo busca compartilhar os sofrimentos e aprendizados enfrentados durante a migração entre plataformas .Net Framework e .Net Core. Reuni diversos pontos que estão distribuídos entre as documentações da Microsoft com o objetivo de tornar o aprendizado mais eficiente e facilitado.

Por quê migrar?

• Cross Plataform;
• Open source;
• Performance;
• Atualizações.

Por que não migrar?

• Dependência de bibliotecas de terceiros;
• Estabilidade nas bibliotecas existentes;
• Problemas de mensuração ou migração de legados.

É compreensível a dificuldade de migração de projetos legados, em especial os monolíticos, para o .NET Core. Porém é recomendado, a partir do ano de 2020, a criação de projetos apenas em .NET Core.

A Microsoft já anunciou a descontinuação de atualizações nos pacotes .NET Framework, serão implementados apenas melhorias para estabilidade dos pacotes já existentes. Na timeline a seguir podemos visualizar o roadmap anunciado no blog da Microsoft.

Grandes mudanças também são esperadas para o .NET 5. O .NET Core 3 tende a suprir todo o necessário já disponível no .NET Framework 4.8, com uma performance muito melhor. O .NET 5 virá com novas funcionalidades e integrações, conforme a imagem a seguir:

Qual a diferença de Performance?

Segundo Mitchel Sellers, em sua apresentação sobre transições para .NET Core, um estudo de migração apresentou os seguintes dados:

Projeto existente em ASP NET MVC:

• Começou com MVC 3, usando WebMatrix User Accounts;
• Foi estimado em 1500 horas de desenvolvimento, total;
• Possuía 13 controllers, 55 views, 1 banco de dados.

Migrando para o ASP NET Core 1.1

• Transição usando Identity para autenticação;
• Tempo estimado em 140 horas;
• A performance melhorou 61%;
• Consultas retornando dados 500 vezes mais rápido.

Migrado para ASP NET Core 2.0

• Tempo de desenvolvimento estimado em 12 horas;
• A performance melhorou mais 15%.

Diferenças Estruturais

• Não é mais necessário incluir os arquivos no projeto/csproj; Todos os arquivos no diretório são considerados; Reduz o risco de ocorrerem conflitos.
• É possível editar o arquivo csproj diretamente do Visual Studio;
• Referência a outros projetos não são mais feitas com GUID, melhorando a leitura;
• O arquivo Global.asax foi substituído pelo arquivo Startup.cs;
• Configurações migradas do web.config para o appsettings.json
• Injeção de dependência nativa e mais performática;
• Arquivos estáticos armazenados na pasta wwwroot;
• Pasta de packages removida, pacotes referenciados diretamente da pasta raiz do nuget, reduzindo as duplicações e liberando mais memória interna;
• As diretivas HttpHandlers e HttpModules devem ser substituídos por Middlewares.

O .NET Standard

As bibliotecas em .NET Standard fornecem suporte às diferentes plataformas do .NET, assim como apresentamos a seguir. É uma boa forma de começar a migrar suas bibliotecas aos poucos sem impactar no código já existente.

As configurações passadas a seguir podem ser implementadas separadamente em libs .NET Standard compartilhadas ou usadas diretamente nas aplicações desejadas. Na documentação da Microsoft é possível encontrar um pouco mais sobre esse direcionamento Multiplataforma.

Iniciando a Migração

Começando com o clichê, crie sua primeira API com o .NET Core.

File > New > Project > ASP NET Core Web Application > API

Configurações

Você pode implementar as variáveis de configuração no arquivo já criado appsettings.json. Essa variáveis podem estar em qualquer hierarquia, mas o código implementado tem que estar ciente da mesma.

Convenções:

• As chaves não diferenciam maiúsculas de minúsculas. Por exemplo, ConnectionString e connectionstring são tratados como chaves equivalentes.
• Se um valor para a mesma chave for definido pelos mesmos provedores de configuração, ou por outros, o último valor definido na chave será o valor usado.

A interface Configuration permite o acesso à essa configurações e pode ser implementada em qualquer lugar do projeto - sendo resolvida automaticamente pela injeção de dependência nativa e implementada por default na classe inicial Startup.cs.

No exemplo acima é extraído o valor de cadeia de caracteres da configuração com a chave NumberKey. Se NumberKey não for encontrado nas chaves de configuração, será usado o valor padrão 99.

Você pode encontrar mais sobre os provedores também na documentação oficial.

Injeção de dependência

No .NET Core foi centralizado todas as configurações da aplicação na classe Startup. Para facilitar o uso/manutenção e leitura desse arquivo inicial, recomendamos usar uma extensão para configurar sua injeção.

Segue o exemplo abaixo com algumas resoluções da injeção de dependência.

Sobre as opções de injeção, continuam as mesmas opções dos maiores frameworks de injeção:

• Transient: serviços são criados cada vez que solicitados;
• Scoped: serviços são criados em cada request;
• Singleton: serviços são criados apenas uma vez durante a vida da aplicação;

Authorization

Você pode se autenticar com o básico do Authorize e AllowAnonymous attribute, atribuir políticas com regras específicas para o token passar, ou usar um filter com as regras desejadas. Mais informações sobre as formas de autorização podem ser localizadas na documentação oficial.

Com o uso do authorize attribute é possível ainda especificar tipos de usuários específicos para acesso:

É possível fazer a declaração global usando uma política:

Ou ainda pode usar um Middleware ou AuthorizationFilter, lembre-se de ficar atento a ordem de execução no NET Core conforme o diagrama a seguir:

Ordem de execução de filtros

Middlewares

Os handlers no NET Core são representados pelos middlewares, que contém uma implementação muito simples:

Contexto com Entity Framework

O Entity Framework 6 (EF6) não dá suporte ao .NET Core, por isso iremos ver a implementação com o Entity Framework Core. O Entity Framework Core contém implementações que o EF6 não contém, como chaves alternativas, atualizações em lote, entre outros; mas também não possui todos os recursos do EF6.

A Implementação ainda é muito parecida com a EF6. Como no exemplo abaixo - extraído do site oficial da Microsoft - deve-se criar um contexto conforme descrito a seguir:

Você também pode escolher declarar o contexto na classe Startup usando uma extension:

Mais conteúdos auxiliares

A seguir, destaco alguns links úteis para consulta:

• Guia de migração por versões - Microsoft
• Documentando sua aplicação com swagger
• Habilitando o cors no ASP NET Core
• Configurando logs
• Teste de unidade no NET Core
• Testes funcionais no ASP NET Core

Sobre a Autora

Vittoria Zago (LinkedIn) é graduada em Sistemas de Informação pela UNESP Bauru/SP e cursa atualmente o MBA em Arquitetura de Sistemas Distribuídos pela PUC/MG. Trabalha na área de tecnologia desde 2014, hoje atua como desenvolvedora .NET e Scrum Master de uma equipe de desenvolvimento focada em inovação na Paschoalotto em Bauru/SP.