Skip to content
chaveprimaria edited this page Apr 8, 2024 · 7 revisions

Welcome to the loja-do-valdir wiki!

O que é uma CLI?

A CLI (Command Line Interface) ou Interface de Linha de Comando, é uma ferramenta que permite interagir com o software através de comandos digitados no terminal ou prompt de comando — em oposição a uma interface gráfica de usuário (GUI) —, sendo compatível com Windows, Linux e MacOS.

image

Para que serve?

Faz parte do ambiente de desenvolvimento .NET e oferece uma interface versátil para executar uma variedade de tarefas, tais como:

  • Compilação: transforma código-fonte em executáveis (arquivo que contém um programa pronto para ser "rodado") ou bibliotecas compatíveis em um ambiente .NET;
  • Execução: roda aplicativos e testes diretamente no terminal;
  • Depuração: identifica e corrige problemas no código;
  • Gerenciamento de pacotes: instala, atualiza e remove pacotes NuGet (gerenciador de pacotes), que são bibliotecas de código reutilizáveis;
  • Publicação: prepara e implanta aplicativos para distribuição;
  • Geração de Código: cria novos projetos e arquivos de código-fonte de forma condicionada;
  • Testes: executa testes automatizados para verificar a qualidade do código;
  • Gerenciamento de Versão: trabalha com diferentes versões do .NET SDK (conjunto de ferramentas) e runtimes (ambiente de execução).

Em resumo, é um meio essencial para simplificar e automatizar o processo de desenvolvimento de software na plataforma .NET, oferecendo uma maneira eficiente de gerenciar e executar finalidades comuns através da linha de comando.

Como é utilizada e casos de uso

Como mencionado anteriormente, a CLI é utilizada amplamente por desenvolvedores afim de realizar atividades relacionadas à construção de apps e bibliotecas. Algumas das principais formas de utilização incluem:

  • Criação de Projetos: seja para aplicativos, bibliotecas de classe ou projetos de testes, a CLI simplifica o processo com comandos simples, permitindo até mesmo especificar o projeto desejado, a linguagem (C#, F#, VB), o nome e outros parâmetros relevantes;
  • Compilação e Execução: útil para testar o código durante o processo de desenvolvimento ou executar scripts automatizados;
  • Gerenciamento de Pacotes: o NuGet, integrado à CLI do .NET, facilita o gerenciamento de pacotes em projetos. Os desenvolvedores podem instalar, atualizar e remover pacotes diretamente do terminal;
  • Testes Automatizados: a CLI descomplexifica a execução de testes automatizados usando frameworks como xUnit, NUnit ou MSTest, autorizando a execução de testes unitários, de integração ou aceitação pela linha de comando;
  • Publicação de Aplicativos: após concluir o desenvolvimento, os programadores podem utilizar a CLI para publicar o app, preparando-o para implantação em produção, incluindo compilação, empacotamento de recursos e criação de artefatos de distribuição;
  • Implantação de Ambientes em Produção: por fim, a interface pode ser usada também para implantar aplicativos em ambientes de produção, seja em servidores locais, na nuvem ou em contêineres, acelerando o processo de implantação ou ferramentas de integração/entrega contínua (CI/CD — Integração Contínua - Continuous Integration | Entrega Contínua/Implantação Contínua - Continuous Delivery/Continuous Deployment).

Comandos e seus argumentos

A interface do .NET segue uma abordagem modular e hierárquica — padrão —, onde comandos principais são usados para realizar tarefas de alto nível, podendo ser seguidos por possíveis subcomandos e argumentos — informações adicionais ao comando — para executar tarefas mais específicas.

Embora subcomandos e argumentos não sejam sempre requeridos em todos os comandos, muitos deles possuem opções padrão que podem ser aplicadas. Por exemplo, os argumentos -force, -c, -h são comuns em muitos comandos. É importante verificar a documentação específica de cada comando para entender quais opções estão disponíveis e como elas podem ser utilizadas.

dotnet

Sua base segue tendo duas funções:

  1. Fornecer comandos para trabalhar com projetos .NET;

Por exemplo, dotnet build compila um projeto. Cada comando define suas próprias opções e argumentos. Todos os comandos dão suporte à opção --help para imprimir uma breve documentação sobre como usar o comando.

  1. Executar aplicativos.

A seguir, estão listados os comandos mais comuns, e utilizados no projeto loja-do-valdir, além de seus argumentos correspondentes.

dotnet new

É utilizado como ponto inicial para criar novos projetos, arquivos de código-fonte e configurações ou solução com base em um modelo específico. A estrutura básica do comando é:

dotnet new <SUBCOMANDO> <ARGUMENTO>

Aqui estão alguns exemplos de subcomandos e suas execuções:

COMANDO SUBCOMANDO EXECUÇÃO
dotnet new console Cria uma aplicação console.
dotnet new web Cria novo projeto de aplicativo da web.
dotnet new classlib Cria nova biblioteca de classes.
dotnet new sln Cria novo arquivo de solução.
dotnet new mvc -au None Cria projeto MVC no diretório atual sem autenticação.
dotnet new mstest Cria novo projeto de teste MSTest.
dotnet new xunit Cria novo projeto de teste xUnit.
dotnet new --install Instala novos templates.
dotnet new --help Lista templates personalizados disponíveis.

Alguns exemplos de argumentos incluem:

  • -n: nomeia o arquivo;
  • -o: nomeia o diretório/pasta — caso não especificar o nome do projeto, o arquivo assumirá o nome do diretório criado.
  • force: é opcional, sendo utilizado em casos que se necessite que "force" o computador a executar a tarefa, mesmo que haja um impedimento prévio.

A partir do SDK do .NET 7, a sintaxe do dotnet new foi alterada. Para obter ajuda sobre os subcomandos, você pode utilizar a opção -h ou --help, por exemplo:

antes do SDK .NET 6.0.100 a partir do SDK .NET 6.0.100
dotnet new spa --list dotnet new list
dotnet new --search dotnet new search
dotnet new --install dotnet new install
dotnet new --uninstall dotnet new uninstall
dotnet new --update-apply dotnet new update
dotnet new --update-check dotnet new update --check-only

dotnet run

Executa o código-fonte sem qualquer comando de compilação ou inicialização explícita, além de exibir mensagens de saída no console, que podem incluir mensagens de log, erros ou qualquer outra saída gerada pelo projeto enquanto é executado.

dotnet run não respeita argumentos como /property:property=value, que são respeitados por dotnet build.

dotnet run

O comando dotnet run não possui subcomandos, porém há argumentos opcionais padrões, como especificação da arquitetura de destino (a | --arch), framework (-f | --framework) ou configurações (-c | --configuration).

dotnet watch

É um observador de arquivos que serve para monitorar alterações nos arquivos do projeto e reagir automaticamente a essas alterações, reiniciando ou executando comando adicionais conforme necessário — como dotnet runou outro comando especifico dotnet —. É especialmente útil em cenários de desenvolvimento, onde se deseja ver imediatamente as alterações refletidas no app enquanto trabalha nele.

dotnet watch <SUBCOMANDO>

COMANDO SUBCOMANDO EXECUÇÃO
dotnet watch run Executa o projeto em um loop, reiniciando automaticamente sempre que ocorrerem alterações nos arquivos do projeto.
dotnet watch test Executa os testes automatizados em um loop, reiniciando automaticamente sempre que ocorrerem alterações nos arquivos do projeto.
dotnet watch exec Executa um comando específico em um loop, reiniciando automaticamente sempre que ocorrerem alterações nos arquivos do projeto.

Útil durante o desenvolvimento, pois permite que você veja imediatamente o impacto das alterações no código sem precisar reiniciar manualmente o projeto.

Aceita argumentos.

dotnet restore

O comando dotnet restore é utilizado para restaurar as dependências de um projeto do .NET. Normalmente faz referências a bibliotecas externas em pacotes NuGet que fornecem funcionalidade adicional, garantindo que estejam disponíveis localmente para compilação e execução, além de serem referenciadas no arquivo de projeto .csproj ou .vbproj.

dotnet restore <ARGUMENTO> <ARQUIVO/PASTA>

Ao executar o comando, a interface utiliza o NuGet para procurar e se necessário, baixa as dependências no arquivo de projeto, garantindo que todas as bibliotecas essenciais estejam disponíveis localmente para compilação e execução do projeto. Ele também garante que sejam compatíveis entre si e que não haja conflitos entre elas.

COMANDO ARGUMENTO EXECUÇÃO
dotnet restore root Especifica o diretório raiz a partir do qual as dependências devem ser restauradas. Por padrão, o diretório atual é usado como raiz.
dotnet restore --configfile Especifica um arquivo de configuração do NuGet para ser usado durante a restauração, o que pode ser útil para configurar repositórios de pacotes personalizados ou autenticação.
dotnet restore --disable-build-servers Desabilita a utilização de servidores de compilação remotos durante a restauração.
dotnet restore --disable-parallel Desabilita a restauração paralela de pacotes.
dotnet restore --no-cache Desabilita o uso do cache de pacotes durante a restauração, forçando o NuGet a baixar todas as dependências novamente. Isso pode ser útil se estiver enfrentando problemas relacionados ao cache ou se quiser garantir que esteja obtendo as versões mais recentes dos pacotes.
dotnet restore --no-dependencies Restaura apenas o projeto especificado, ignorando suas dependências.
dotnet restore --packages Especifica o diretório onde os pacotes restaurados serão armazenados.
dotnet restore -s ou --source Especifica os locais onde o NuGet deve procurar por pacotes. Este argumento pode ser usado para adicionar os repositórios NuGet adicionais para pesquisa de pacotes.
dotnet restore -v ou --verbosity Especifica o nível de verbosidade da saída durante a restauração.

Não possui subcomandos.

dotnet build

O comando dotnet build compila o código-fonte do projeto e suas dependências em um conjunto de binários, estes que incluem o código do projeto em arquivos de linguagem intermediária com extensão .dll e/ou .exe. Em outras palavras, ele analisa, verifica a sintaxe, resolve referências a bibliotecas, otimiza o código e gera o IL (Intermediate Language) correspondente — também conhecido como MSIL (Microsoft Intermediate Language) e CIL (Common Intermediate Language).

Dependendo do tipo de projeto e das configurações, outros arquivos podem ser gerados:

  1. Um executável, caso o projeto seja um app executável direcionado ao .NET Core 3.0 ou posterior;

Em projetos executáveis anteriores ao .NET Core 3.0, as dependências do NuGet não são incluídas na pasta de saída durante a compilação, sendo resolvidas em tempo de execução. Por outro lado, em projetos direcionados ao .NET Core 3.0 e posteriores, as dependências são copiadas para a pasta de saída durante a compilação, tornando-os prontos para distribuição e execução em um ambiente de produção sem etapas adicionais de configuração.

  1. Arquivos de símbolos .pdb (Program Database) para depuração;
  2. Um arquivo .deps.json ou .runtimeconfig.json especificando o tempo de execução compartilhado e sua versão em um aplicativo;
  3. Outras bibliotecas das quais o projeto depender, por meio de referências de projeto ou do NuGet.

dotnet build <ARGUMENTO>

COMANDO ARGUMENTO EXECUÇÃO
dotnet build --configuration Especifica a configuração de compilação a ser utilizada, como "Debug" ou "Release".
dotnet build --framework Indica o framework de destino para o qual o projeto deve ser compilado.
dotnet build --output Classifica o diretório de saída para os arquivos compilados.
dotnet build --no-incremental Desativa a compilação incremental, forçando uma recompilação completa do projeto.
dotnet build --no-dependencies Compila apenas o projeto especificado, ignorando suas dependências.
dotnet build --verbosity Classifica o nível de detalhamento da saída durante a compilação.

Não possui subcomando.

dotnet build-server

Enquanto dotnet build é o comando principal para compilar um projeto ou solução, dotnet build-server é uma opção que pode ser usada para melhorar o desempenho, mantendo um servidor de compilação em segundo plano, evitando repetição de certas operações entre compilações consecutivas, como um copiloto.

dotnet build-server

Não possui argumentos ou subcomandos.

dotnet test

É um driver em essência, como um tipo de motor atuando por trás do comando, fornecendo a infraestrutura necessária para tecnicizar a execução de testes de unidade, garantindo que eles sejam executados de maneira consistente e confiável em diferentes ambientes de desenvolvimento. Ele é responsável por coordenar a execução dos testes de unidade dentro do ambiente de execução do .NET, descobrindo, carregando e executando os testes definidos nos projetos de teste, além de registrar os resultados dos testes para análise posterior. Ora:

  • Descoberta: é responsável por descobrir todos os testes disponíveis em um projeto de teste. Ele examina o código-fonte e os metadados do projeto para identificar todos os métodos de teste, classes de teste e assemblies de teste disponíveis para execução;
  • Preparação do Ambiente: uma vez que os testes tenham sido descobertos, ele é responsável por carregar e preparar o ambiente de execução para os testes. Isso pode envolver a compilação dinâmica do código de teste, a carga de assemblies* necessários e a configuração de qualquer ambiente de execução necessário para os testes;

A carga de assemblies no .NET é o processo de carregar arquivos de assembly durante a execução do programa. Um assembly é a unidade básica de implantação e execução no .NET, contendo código compilado, metadados e recursos. Esse processo é essencial para permitir que os aplicativos .NET usem código compilado dinamicamente, oferecendo flexibilidade para adicionar ou remover funcionalidades sem precisar recompilar ou reiniciar o aplicativo.

  • Execução: após o carregamento dos testes, o driver executa os testes de acordo com as configurações fornecidas. Ele registra os resultados dos testes, incluindo informações sobre testes bem-sucedidos, falhos ou ignorados, e fornece feedback detalhado sobre o desempenho do teste e quaisquer problemas encontrados durante a execução;
  • Suporte: o .NET oferece suporte a vários frameworks de teste, como MSTest, xUnit.NET e NUnit. Também é frequentemente integrado a ferramentas de desenvolvimento populares, como Visual Studio e Visual Studio Code, para fornecer uma experiência de teste integrada e simplificada.

dotnet test <ARGUMENTOS>

COMANDO ARGUMENTO EXECUÇÃO
dotnet test --filter Permite filtrar os testes a serem executados com base em uma expressão de filtro. Por exemplo, você pode especificar o nome de um ou mais testes para executar apenas esses testes.
dotnet test --logger Especifica o logger a ser usado para registrar a saída dos testes. Por padrão, a saída é registrada no console, mas você pode especificar outros loggers, como o trx para gerar um arquivo de resultados de teste no formato TRX.
dotnet test --collect Executar os testes no projeto no diretório atual e gerar um arquivo de cobertura de código (somente Windows)

Não possui subcomandos.

dotnet publish

O comando publica o aplicativo e suas dependências em uma pasta específica, tornando-o pronto para implantação em um sistema de hospedagem. A publicação aqui se refere ao processo de compilar o app, juntamente com suas dependências, e organizar os arquivos resultantes de forma que o aplicativo possa ser executado em um ambiente de produção. A saída inclui:

  1. Criação e compilação de arquivos em linguagem intermediária armazenado em um assembly com extensão .dll, arquivos de configuração e o empacotamento de todas as dependências necessárias para a execução do app;
  2. Um arquivo .deps.jsonque lista todas as dependências do projeto.
  3. Um arquivo .runtimeconfig.json que define o tempo de execução esperado pelo aplicativo, junto com outras configurações relacionadas ao tempo de execução, como o tipo de coleta de lixo;
  4. As dependências do aplicativo, que são copiadas no cache NuGet para a pasta de saída.

Durante a publicação, o comando reúne todas as peças necessárias para que o aplicativo funcione e as coloca em uma pasta. Isso inclui o próprio aplicativo e qualquer outro software que ele precise para funcionar corretamente. Essas peças extras são copiadas para a pasta de publicação, garantindo que o aplicativo tenha tudo o que precisa para funcionar, independentemente de onde for implantado.

dotnet publish

COMANDO ARGUMENTO EXECUÇÃO
dotnet publish -c ou --configuration Especifica o tipo de configuração a ser usada durante a publicação do aplicativo, como Debug ou Release.
dotnet publish --disable-build-servers Força o comando a ignorar qualquer servidor de compilação persistente. Essa opção fornece uma maneira consistente de desativar todo o uso do cache de compilação, o que força uma compilação do zero. Uma compilação que não depende de caches é útil quando os caches podem estar corrompidos ou incorretos por algum motivo.

Essa saída gerada pelo comando dotnet publish está pronta para ser implantada em um sistema de hospedagem, como um servidor ou desktop. Este é o método oficialmente suportado para preparar o aplicativo para implantação. Dependendo das especificações de implantação definidas pelo projeto, o sistema de hospedagem pode não ter o tempo de execução compartilhado do .NET instalado.


Não possui subcomandos.

dotnet clean

Limpa a saída do projeto.

dotnet clean

Não possui subcomandos, mas aceita argumentos para controlar seu comportamento.

dotnet pack

Compila o projeto e gera pacotes NuGet, resultando em um arquivo .nupkg. É um método de unidades de distribuição que contêm biblioteca, componentes ou apps para compartilhamento e reutilização em outros projetos. Ou seja, criação de artefatos empacotados padronizados que permite que se compartilhe soluções e bibliotecas de forma eficiente dentro do ecossistema .NET.

COMANDO ARGUMENTO EXECUÇÃO
dotnet pack --include-symbols Cria o pacote de símbolos de depuração.
dotnet pack --include-source Cria pacote de símbolos de depuração com uma pasta src dentro com os arquivos de origem.
dotnet pack --interactive Permite que o comando pare e aguarde entrada ou ação do usuário.

Por padrão, dotnet pack compila primeiro o projeto. Se quiser evitar esse comportamento, passe a opção --no-build. Com frequência, essa opção é útil em cenários de build de integração contínua nos quais se sabe que o código foi compilado anteriormente.


Não possui subcomandos.

Saiba mais...

Documentação oficial da Microsoft

Clone this wiki locally