Cinco anos e meio atrás eu criei um projeto rápido chamado “Recast” com a intenção de poder ouvir episódios de podcast antigos que tinham saído dos respectivos feeds ou áudios quaisquer que estivessem na internet mas não disponíveis como podcast. Recentemente o Github me avisou que havia um problema de segurança em um dos pacotes NuGet que eu estava usando no Recast. Eu uso essa app desde aquela época, e ela atendeu meu requisito. Tenho conseguido ouvir podcasts melhor com ela. Até áudio longo de WhatsApp que eu quero ouvir eu transformo em podcast (dica: baixe o áudio, converta online pra mp3, coloque no OneDrive e peça o link público do mp3). Eu não tinha a menor intenção de dar manutenção em código ASP.NET MVC e .NET Framework, então assumi o desafio de migrá-lo. Esse post explica como foi e o que fiz.

Aviso: gostaria de deixar claro que esse é um projeto simples, ou seja, não assuma que projetos maiores vão ser assim tão fáceis.

Levei menos de três horas para migrar tudo. Os passos foram:

1. Criar dois projetos novos de ASP.NET Core com .NET Core e .NET Standard;
2. Copiar os arquivos dos projetos antigos antigos para os novos;
3. Corrigir os erros e incompatibilidades.
4. Instalar as dependências via NuGet;

Os passos 2 a 4 fiz de maneira iterativa. Ia copiando, corrigindo os erros e instalando as dependências.

Criando o projeto de ASP.NET Core

Usei o mesmo nome, que era Recast.WebApp. Fiz via linha de comando. O projeto web é um projeto ASP.NET Core 2.1 e o projeto de VB fiz com .NET Standard 2.0.

Usando o mesmo nome fica muito facilitado para mover os arquivos, os valores antigos para as dlls, namespaces, etc, são mantidos.

O que tive que mudar

Fui copiando aos poucos e em paralelo corrigindo os erros e instalando as dependências que faltavam.

O projeto padrão do ASP.NET Core foi uma excelente base para o trabalho. É impressionante como as pessoas que o projetaram conseguiram ao mesmo tempo criar um framework web novo, que inova em diversos sentidos, e ao mesmo tempo facilitaram tanto a migração.

Alguns pontos interessantes:

• O projeto de VB com .NET Standard funcionou sem alteração nenhuma no código VB.
• Os arquivos razor (.cshtml) tiveram alterações parciais. Uma grande parte do código foi mantida. Um ponto que piorou no Razor novo é que não é possível usar section em partials.
• Como os componente NuGet foram atualizados também, houve alguma quebra de compatibilidade.
  • O AutoMapper foi um exemplo, mas a alteração foi bastante simples.
  • Outro exemplo foi a API para o Azure Storage. Ela não mudou tanto em si, mas agora é toda assíncrona, e isso deu mais trabalho. Todos os métodos passaram a ter que retornar Tasks, inclusive nos controllers. Foi onde surgiram mais bugs. Como o projeto não tinha testes tive que testar tudo na mão. Por sorte a aplicação era pequena.
• Foi muito legal poder usar as novas funcionalidades do C#, então o código ficou mais simples em diversos pontos (interpolação de strings FTW!).
• Escolhi não usar o suporte a bundling do ASP.NET Core. Inclui manualmente as referências dos artefatos de frontend nos arquivos Razor. Ficou bastante simples e não deu nenhum trabalho. Na verdade acabou por simplificar o trabalho, deixá-lo mais objetivo. Não faz sentido usar tudo aquilo para um projeto desta simplicidade. Dito isso, o frontend ficou absolutamente idêntico ao da versão anterior.
• A configuração era feita da forma antiga, via web.config. Passei a usar o modelo de configuração do ASP.NET Core, e isso complicou o uso de alguns métodos estáticos que usavam configuração. Mas, com o modelo de injeção de dependências padrão do framework ficou bem fácil resolver.
• As rotas foram um ponto interessante. Eu utilizo duas rotas customizadas, fora a rota padrão. Elas ficaram bem mais simples do que eram antes.
• Achei um bug em que uma partial view postava para action errada e corrigi acrescentando o nome do controller e action corretas.

No final, o código teve 2074 exclusões, e 1108 inclusões, como você pode ver no Github, que mostra o diff do commit. Isso só reforça a simplicidade do ASP.NET Core quando comparado com o ASP.NET MVC e do novo sistema de projetos. As alterações mais significativas são no arquivo de projetos (csproj e vbproj), na remoção do web.config, e dos arquivos de resource (resx).

O deploy está sendo feito automaticamente pelo Azure. Sempre que a branch release é atualizada o Azure faz o deploy. Quando finalmente terminei o trabalho e atualizei o trabalho o release foi feito pelo Azure e a app continuou funcionando.

Antes disso, eu fui publicando manualmente a aplicação no Azure, usando o mecanismo de publish do próprio Visual Studio. Estou usando App Service, e ao subir a aplicação ela parou de funcionar. Tinha problemas com o uso do https, e a aplicação dizia não encontrar os certificados. Descobri que precisava marcar a opção de limpar os arquivos antes de publicar, ou seja, o Visual Studio excluiu os arquivos da versão antiga do projeto antes de publicar a nova. Isso fez ela voltar a funcionar. Não sei exatamente qual arquivo estava causando o problema, mas imagino que seja o web.config. Depois que consegui trazer tudo de volta ao ar, atualizei a branch release e o publish foi refeito, desta vez pelo Azure.

A configuração do Azure para acessar a conta de storage foi simples, conforme o esperado. Apenas setei uma string de conexão no App Service usando o exato mesmo valor que estava nas configurações anteriores. Essa conexão funcionou de primeira.

Conclusões

O update foi simples, e agora tenho uma app que roda mais rápido, pode rodar em Linux, Windows e Mac, ou em contêineres, e não precisa sequer de Visual Studio para editar. Ela rodou facilmente no Azure. Já fiz updates maiores que levaram semanas para terminar. Mas é bom saber que pequenas apps assim dá para fazer em menos de um dia.

Comparei manualmente os feeds, e o resultado foi excelente. O xml gerado ficou igualzinho o anterior, a única diferença foi a URL, que agora está sendo quebrada em mais de uma linha, não sei exatamente porque o compilador do VB está fazendo isso.

Caso você queira ver o commit para ver os detalhes do que foi feito GitHub.

Para acessar a app acesse recast.azurewebsites.net.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.