Um dia sem Visual Studio usando só a .NET CLI

Hoje o Visual Studio não vai abrir.

No Dia 01 dos meus 30 dias de .NET nós vimos o que acontece por trás de um dotnet run e conhecemos a .NET CLI. No Dia 02 abrimos a caixinha de um projeto .NET para entender melhor o Program.cs, .csproj, bin, obj e algumas das configurações que fazem nosso projeto funcionar.

Então hoje resolvi juntar as duas coisas e fazer um pequeno desafio que me lembrou dos tempos sem IA: criar, compilar, executar, testar e publicar uma aplicação .NET usando somente o terminal.

Sem botão de play, sem clicar com o botão direito na Solution, sem menu de Build e sem Visual Studio fazendo as coisas por mim.

Só eu, o terminal e a .NET CLI. Tal qual NEO do Matrix.

Antes de começar, o que podemos criar?

No Dia 01 vimos que a .NET CLI (Command-Line Interface) é uma ferramenta que permite interagir com o .NET através de comandos escritos e que ela vem junto com o .NET SDK.

Um dos primeiros comandos que encontramos foi dotnet new. Mas, antes de criar qualquer coisa, podemos descobrir quais templates estão disponíveis na nossa máquina usando o comando dotnet new list

O resultado mostra uma lista ENORME de templates que podemos utilizar para criar diferentes tipos de projetos e arquivos .NET. Entre eles encontramos aplicações Console, Class Libraries, projetos de testes, aplicações web e vários outros. A diferença entre cada um vêm num futuro não muito distante.

Então quando escrevemos dotnet new console o console não é só uma palavra aleatória que a CLI entende. Ele é o short name de um template que está instalado e disponível para o dotnet new.

Para o nosso desafio vamos criar uma aplicação Console chamada Dia03 usando o comando conhecido dotnet new console -n Dia03

A opção -n é a forma curta de --name e define o nome do que estamos criando. Depois do comando, podemos entrar na pasta. E pronto, nosso projeto foi criado sem abrir nenhuma IDE.

dotnet build — vamos ver se isso compila

Agora temos código, mas precisamos transformá-lo em algo que o .NET consiga executar. É aí que entra o nosso dotnet build do Dia 01.

Quando executamos esse comando, o .NET usa o MSBuild para construir o projeto e suas dependências. O código C# passa pelo processo de compilação que vimos no Dia 01 e os arquivos resultantes começam a aparecer naquela estrutura de bin e obj que vimos no Dia 02.

Por padrão, o build utiliza a configuração Debug, então podemos encontrar nossos arquivos em uma estrutura parecida com:

Mas também podemos escolher outra configuração com o uso do Release: dotnet build -c Release

O -c é a forma curta de --configuration e, nesse caso, estamos pedindo um build utilizando a configuração Release.

De forma simplificada, Debug é a configuração pensada para o desenvolvimento e depuração da aplicação, enquanto Release é a configuração utilizada quando queremos um build otimizado para distribuição. Olha como adiciona pastas ao obj e bin

Então o dotnet build não está executando nossa aplicação. Ele está construindo nosso projeto e verificando se aquele código consegue ser compilado com sucesso. Se tiver um belo erro de compilação no meio do caminho, ele vai nos contar.

dotnet run — esse aqui a gente já conhece

Depois de três dias falando sobre .NET, o dotnet run já está quase virando membro da família e almoçando no domingo com a gente

Esse comando executa nossa aplicação e, quando necessário, realiza o processo de build antes disso. Se quiser saber mais sobre esse processo de build você pode ler o Dia 01 também.

dotnet test — agora vamos deixar o QA feliz

Temos uma aplicação que cria, compila e executa, mas ainda falta uma coisa importante: 90% de cobertura de testes.

Se tentarmos explorar o dotnet test no nosso projeto Console, não temos nenhum teste para executar. Então vamos aproveitar a própria CLI para criar um projeto de testes.

Voltando para a pasta onde está nosso projeto Dia03, podemos executar dotnet new xunit -n Dia03.Tests pra criar esse projeto. Não vou entrar nos detalhes desse comando hoje.

Agora temos dois projetos:

O template xunit cria um projeto de testes utilizando xUnit um framework de testes para o .NET. Ele nos da as ferramentas e convenções que usamos para escrever testes automatizados em C#, principalmente testes unitários.

Como queremos que nossos testes consigam acessar o projeto que estamos testando, adicionamos uma referência entre eles:

dotnet reference add ../Dia03/Dia03.csproj --project Dia03.Tests

A referência fica registrada no .csproj do projeto de testes através de um ProjectReference, bem parecido com o que vimos ontem quando adicionamos um pacote NuGet.

Agora podemos executar nossos testes e ver o resultado

O comando faz o build dos projetos necessários e executa os testes encontrados no projeto de testes. No final recebemos o resultado diretamente no terminal, mostrando quantos testes passaram, falharam ou foram ignorados.

Não vou entrar em xUnit e estrutura de testes agora porque isso merece um dia próprio. O importante aqui é que conseguimos criar o projeto de testes e executá-lo sem precisar abrir o Test Explorer do Visual Studio.

dotnet publish — terminou, agora precisamos entregar

Até agora criamos nosso projeto, compilamos, executamos e rodamos os testes. Falta preparar nossa aplicação para sair da nossa máquina com o dotnet publish

Uma dúvida que eu já tive é: se dotnet build já compilou minha aplicação, para que existe o dotnet publish? Os dois realmente passam pelo processo de build, mas têm objetivos diferentes.

O dotnet build está focado em construir o projeto, gerando os binários necessários para desenvolvimento e validação do código. Já o dotnet publish prepara a aplicação e suas dependências para que ela possa ser implantada em outro ambiente.

Podemos publicar nossa aplicação em Release com o comando dotnet publish -c Release e ver uma pasta parecida com essa

Dentro de publish ficam os arquivos que fazem parte da saída publicada da nossa aplicação. Então uma forma simples de pensar é que o build responde algo próximo de " eu consigo construir esse projeto?", enquanto o publish responde "quais arquivos eu preciso preparar para distribuir essa aplicação?"

Parece bastante coisa e é mas a própria CLI pode ajudar a gente nas horas do desespero

Não decore tudo, pergunte para a própria CLI

Até agora usamos várias opções nos comandos que viram letrinhas soltas -n, -c. E a lista fica muito maior conforme começamos a explorar a CLI, no final a gente tá digitando sem nem saber o porquê. Não é mais nosso intuito certo? A boa notícia é que não precisamos decorar todos esses comandos e opções.

Podemos pedir ajuda diretamente no terminal com o dotnet --help ou, melhor ainda, pedir ajuda para um comando específico:

dotnet new --help
dotnet build --help
dotnet run --help
dotnet test --help
dotnet publish --help

Isso mostra a descrição do comando, seus argumentos e as opções disponíveis. Para mim, saber que uma opção existe e saber onde encontrá-la é muito mais útil do que tentar decorar cinquenta parâmetros que eu talvez use duas vezes no ano.

Do zero ao publish sem Visual Studio

Começamos o dia sem abrir o Visual Studio e passamos por praticamente todo o ciclo básico da nossa aplicação usando apenas a .NET CLI. Isso não significa que amanhã vou desinstalar o Visual Studio e começar a desenvolver tudo pelo CMD (Deus me dibre). A IDE existe justamente para facilitar nossa vida e automatizar várias dessas tarefas. Obrigada Microsoft.

Mas existe uma diferença enorme entre deixar uma ferramenta fazer alguma coisa por nós e não saber o que ela está fazendo por nós. Dá pra ficar horas filosofando sobre isso e o uso da IA mas, vamos deixar esse papo pra um café.

Quando clicamos em Build, executamos os testes pelo Test Explorer ou publicamos uma aplicação pela interface do Visual Studio, existem ferramentas e comandos do .NET trabalhando por trás dessas facilidades. Conhecer a CLI ajuda a entender melhor esse processo e também faz bastante diferença quando saímos da nossa máquina e encontramos ambientes onde não existe um botão bonitinho para clicar, como pipelines de CI/CD, containers e servidores.

O Visual Studio descansou hoje mas pode abrir de novo amanhã.

Referências

• .NET CLI overview — Microsoft Learn e as subpáginas com os comandos