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.