Cinco anos e meio atrás eu criei um projeto rápido chamado “Recast”, com a intenção de poder ouvir episódios de podcasts antigos que tinham saído dos respectivos feeds ou quaisquer áudios 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 meus requisitos. 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 artigo mostra como e o que fiz.

Aviso: gostaria de deixar claro que esse é um projeto simples. Ou seja, não assuma que projetos maiores serão 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 para os novos
• 3 – Corrigir os erros e incompatibilidades
• 4 – Instalar as dependências via NuGet

Do passo 2 até o 4 eu 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 facilita mover os arquivos, e 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 criar um framework web novo, que inova em diversos sentidos, e ao mesmo tempo facilita a migração.

Alguns pontos interessantes:

• O projeto de VB com .NET Standard funcionou sem alteração 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 componentes 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 front-end nos arquivos Razor. Ficou bastante simples e não deu nenhum trabalho. Na verdade, acabou por simplificar o trabalho e deixá-lo mais objetivo. Não faz sentido usar tudo aquilo para um projeto desta simplicidade. Dito isso, o front-end 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 o 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 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 exatamente o 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 sequer precisa 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 podemos 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 queira ver o commit para ver os detalhes do que foi feito GitHub.

Para acessar a app, acesse recast.azurewebsites.net.

***

Este artigo foi produzido em parceria com a Lambda3. Leia outros conteúdos no blog da empresa: blog.lambda3.com.br