Quero atualizar aplicações .NET legadas, como começar ?
Todo software a partir do momento que é colocado em produção já pode ser considerado um “legado”, esse termo utilizado na área de tecnologia ilustra que aquele software pode não ser mais aderente as últimas atualizações tecnológicas e com o tempo vai ficando cada vez mais obsoleto.
Salvo algumas exceções, não é uma prática comum nas empresas ter esforços para deixar seus softwares constantemente atualizados, primeiro por que isto gera custos, segundo por que “ele está funcionando” ou seja, atende ao que é esperado, e aí vem aquela velha máxima, em time que está ganhando não se mexe, será ?
Por que eu deveria atualizar ?
Se há atualizações da Linguagem ou a atualizações das bibliotecas, isto deve ter uma motivação, e na maioria das vezes são bastante estudadas e técnicas.
Outra motivação é a mudança de paradigma ao longo dos anos, há uma década atrás, a premissa de desenvolvimento era o uso de servidores locais para hospedagem dos sistemas, empresas gastavam fortunas para sustentar um servidor que fosse capaz de suportar a aplicação, além de ter que contar com equipe de suporte, salas climatizadas, e outros custos como licenças caríssimas.
Hoje a realidade é diferente, temos sistemas rodando em nuvem e com escalabilidade quando utilizados conteineres ou serviços escaláveis como Azure Web App´s ou similares, isso pode propiciar maior desempenho e até redução de custos.
Além das melhorias técnicas, há melhorias de segurança, compatibilidade com novas ferramentas e desempenho.
Mas em aplicações legadas, nos deparamos com a incompatibilidade de bibliotecas que foram utilizadas, pois na época em que a aplicação foi feita elas estavam atualizadas (as vezes pode até ter sido usada uma biblioteca desatualizada, quer seja por falta de conhecimento no uso da versão mais nova ou até pela incompatibilidade com outros componentes).
As vezes essa desatualização é tão grave, que não há mais suporte para a versão utilizada.
Sendo assim, o primeiro passo é identificar tudo que terá que ser atualizado, e qual vai ser a estratégia de atuação.
A primeira coisa que devemos verificar é qual é a versão .NET utilizada na aplicação, hoje temos aplicações no mercado utilizando versões distintas de .NET criadas em momentos diferentes.
Versões de aplicações encontradas:
.NET Framework = temos versões 3.x, 4.x assim como temos aplicações Windows Forms, Web Forms, MVC 4, Console Application, Windows Services, etc.
Neste caso a migração pode ser mais complicada, pois alguns tipos não tem mais correspondente utilizando o .NET Core, como é o caso de Windows Forms, Web Forms e Windows Services.
.NET Core = neste caso, temos versões 1.0, 2.x, 3.x e 5.x e 6 que acaba de ser lançada em 9/11/21 já vai virar legado nas futuras atualizações !
Abaixo você pode ver o roadmap que mostra quando serão lançadas futuras versões, um detalhe importante é a diferença entre versões, onde temos “GA” que dá suporte de 18 meses ou “LTS” que dá suporte de 3 anos (Long Term Support). Saiba mais em : .NET and .NET Core official support policy (microsoft.com)
Então a primeira coisa a se fazer é identificar a urgência dessa atualização, pois quanto menor for a versão ou quanto mais antiga ela for, mais trabalho dará para ser migrado.
Escolha no ecossistema de aplicações que terá que atualizar as versões mais antigas ou que perderão o suporte mais rapidamente para que sejam priorizadas.
Outro ponto é que nem tudo poderá ser migrado, já que alguns tipos de projeto não são mais suportados (Windows Forms), estes não terá o que fazer a não ser reescrevê-los com novas tecnologias.
Existe alguma ferramenta para ajudar ?
Sim, há algumas ferramentas que analisam a aplicação e verificam as dependências, uma delas é o .NET Portability Analizer https://docs.microsoft.com/pt-br/dotnet/standard/analyzers/portability-analyzer
Ela permite que verifiquemos a compatibilidade de uma aplicação com a versão atual do .NET
O relatório mostra o percentual de portabilidade para cada assembly incluído na execução.
Apresenta a revisão das bibliotecas e sua compatibilidade também
Já serve de ajuda para começar, mas se quiser estudar caso a caso cada pacote ainda há outras soluções, como o site https://www.fuget.org/ onde pode-se consultar a compatibilidade de cada uma delas.
E agora, como devo começar ?
Mudar a configuração de uma aplicação .NET Framework para Core é um passo bem mais complicado, devido à estrutura de configuração e inicialização do projeto que é bem diferente.
Quando migrei uma aplicação eu optei por criar um projeto vazio, e trazer para dentro todas as suas pastas e baixar os pacotes individualmente, e mudar as aplicações onde não houvesse mais pacotes compatíveis.
Já no caso de uma migração de .NET Core para uma versão mais nova, é possível seguir alguns passos e conseguir realizar a migração, há um roteiro disponível no site da Microsoft. Link: Migrate from ASP.NET Core 1.x to 2.0 | Microsoft Docs.
Lá atrás, muitos desenvolvedores buscavam bibliotecas para fazer aquilo que o .NET agora faz por conta própria, como por exemplo a Injeção de Dependência, em que usavam bibliotecas de terceiros como Autofac e Simple Injector, por exemplo. Eu particularmente prefiro usar tudo que for nativo da plataforma, quando migrei projetos eu removi estas lib´s e fiz nova implementação.
Há também a famosa biblioteca Newtonsoft.Json que era usada em todas as aplicações, mas que a partir do .NET 3.1 passou a ter como rival uma biblioteca própria, nativa do .NET que é a System.Text.Json, que é muito mais rápida e eficiente, mas que em aplicações com algum tipo de configuração específica na biblioteca Newtonsoft vai requerer uma configuração nova.
Outra biblioteca em que eu tive algum tipo de trabalho e precisou de refatoração na implementação foi o AutoMapper, em suas várias versões ela sofreu várias alterações na implementação e também na forma de mapear as entidades, então se tiver uma implementação dela, faça uma boa análise, crie testes de Unidade para garantir que o mapeamento será mantido com as mesmas configurações.
O Swagger também, das versões mais antigas para as atuais, teve mudança pois aderiu ao padrão Open Api, portanto tem diferenças na configuração.
Eu particularmente prefiro usar tudo que seja nativo da linguagem, então bibliotecas que fazem algo que a própria linguagem agora suporta são bem vindas e garantirão que não terá surpresas no futuro quando uma destas bibliotecas der problemas nas atualizações ou for descontinuada.
Conclusão
Ao migrar legados, temos que considerar o tempo que isso vai consumir e se realmente faz sentido essa migração para a aplicação em questão, pois se ela será usada por longos anos ainda, faz total sentido atualizar.
Mas saiba que não existe mágica, vai dar trabalho e muita coisa terá que ser testada para ver se não houve alguma mudança.
Referências
Migrate from ASP.NET Core 1.x to 2.0 | Microsoft Docs
https://dotnet.microsoft.com/platform/support/policy/dotnet-core
