-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Welcome to the loja-do-valdir wiki!
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.
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 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).
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:
- 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.
- Executar aplicativos.
A seguir, estão listados os comandos mais comuns, e utilizados no projeto loja-do-valdir
, além de seus argumentos correspondentes.
É 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 |
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 pordotnet 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
).
É 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 run
ou 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.
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.
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:
- 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.
- Arquivos de símbolos
.pdb
(Program Database) para depuração; - Um arquivo
.deps.json
ou.runtimeconfig.json
especificando o tempo de execução compartilhado e sua versão em um aplicativo; - 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.
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.
É 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.
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:
- 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; - Um arquivo
.deps.json
que lista todas as dependências do projeto. - 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; - 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.
Limpa a saída do projeto.
dotnet clean
Não possui subcomandos, mas aceita argumentos para controlar seu comportamento.
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.