execução dotnet

Este artigo se aplica a: ✔️ SDK do .NET 6 e versões posteriores

Nome

dotnet run – Executa o código-fonte sem qualquer comando de compilação ou inicialização explícito.

Sinopse

dotnet run [<applicationArguments>]
  [-a|--arch <ARCHITECTURE>] [--artifacts-path <ARTIFACTS_DIR>]
  [-c|--configuration <CONFIGURATION>] [-e|--environment <KEY=VALUE>]
  [--file <FILE_PATH>] [-f|--framework <FRAMEWORK>] [--force] [--interactive]
  [--launch-profile <NAME>] [--no-build] [--no-dependencies]
  [--no-launch-profile] [--no-restore] [--os <OS>] [--project <PATH>]
  [-r|--runtime <RUNTIME_IDENTIFIER>] [--tl:[auto|on|off]]
  [-v|--verbosity <LEVEL>] [[--] [application arguments]]

dotnet run -h|--help

Descrição

O comando dotnet run fornece uma opção conveniente para executar o aplicativo do código-fonte com um comando. Ele é útil para o desenvolvimento iterativo rápido a partir da linha de comando. O comando depende do comando dotnet build para compilar o código. Quaisquer requisitos para a construção também se aplicam dotnet run .

Os arquivos de saída são gravados no local padrão, que é bin/<configuration>/<target>. Por exemplo, se você tiver um aplicativo netcoreapp2.1 e executar dotnet run, a saída será colocada em bin/Debug/netcoreapp2.1. Os arquivos são substituídos conforme necessário. Os arquivos temporários são colocados no diretório obj.

Se o projeto especificar várias estruturas, a execução de dotnet run resultará em um erro, a menos que a opção -f|--framework <FRAMEWORK> seja usada para especificar a estrutura.

O comando dotnet run é usado no contexto de projetos, não assemblies compilados. Se, em vez disso, você estiver tentando executar uma DLL de aplicativo dependente da estrutura, use dotnet sem um comando. Por exemplo, para executar myapp.dll, use:

dotnet myapp.dll

Para obter mais informações sobre o dotnet driver, consulte a visão geral da CLI do .NET.

Para executar o aplicativo, o comando dotnet run resolve as dependências do aplicativo que estão fora do runtime compartilhado por meio do cache NuGet. Como ele usa as dependências em cache, não recomendamos usar dotnet run para executar aplicativos em produção. Em vez disso, crie uma implantação usando o comando dotnet publish e implante a saída publicada.

Restauração implícita

Não é necessário executar dotnet restore, pois ele é executado implicitamente por todos os comandos que exigem uma restauração, como dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish e dotnet pack. Para desabilitar a restauração implícita, use a opção --no-restore.

O comando dotnet restore ainda é útil em determinados cenários em que realizar uma restauração explícita faz sentido, como compilações de integração contínua no Azure DevOps Services ou em sistemas de compilação que precisam controlar explicitamente quando a restauração ocorrerá.

Para obter informações sobre como gerenciar feeds do NuGet, consulte a documentação de dotnet restore.

Este comando é compatível com as opções dotnet restore quando passado no formato longo (por exemplo, --source). Opções de formato curto, como -s, não são compatíveis.

Downloads de manifesto de carga de trabalho

Quando você executa esse comando, ele inicia um download assíncrono em segundo plano de manifestos de publicidade para cargas de trabalho. Se o download ainda estiver em execução quando esse comando for concluído, o download será interrompido. Para saber mais, confira Manifestos de publicidade.

Arguments

<applicationArguments>

Argumentos passados para o aplicativo que está sendo executado.

Todos os argumentos que não são reconhecidos são dotnet run passados para o aplicativo. Para separar argumentos de dotnet run argumentos para o aplicativo, use a opção -- .

Opções

• --

  Delimita os argumentos para dotnet run dos argumentos para o aplicativo que está sendo executado. Todos os argumentos após esse delimitador são passados para o aplicativo que está sendo executado.

• -a|--arch <ARCHITECTURE>

  Especifica a arquitetura de destino. Essa é uma sintaxe abreviada para definir o RID (Identificador de Runtime), em que o valor fornecido é combinado com o RID padrão. Por exemplo, em um computador win-x64, a especificação de --arch x86 define o RID como win-x86. Se você usar essa opção, não use a opção -r|--runtime. Disponível desde a versão prévia 7 do .NET 6.

• --artifacts-path <ARTIFACTS_DIR>

  Todos os arquivos de saída de compilação do comando executado irão para subpastas no caminho especificado, separados por projeto. Para obter mais informações, consulte Layout de saída de artefatos. Disponível desde o SDK do .NET 8.

• -c|--configuration <CONFIGURATION>

  Define a configuração da compilação. O padrão para a maioria dos projetos é Debug, mas você pode substituir as configurações de compilação em seu projeto.

• --disable-build-servers

  Força o comando a ignorar todos os servidores de build persistentes. Essa opção fornece uma maneira consistente de desabilitar todo o uso do cache de build, o que força um build do zero. Um build que não depende de caches é útil quando os caches podem estar corrompidos ou incorretos por algum motivo. Disponível desde o SDK do .NET 7.

• -e|--environment <KEY=VALUE>

  Define a variável de ambiente especificada no processo que será executada pelo comando. A variável de ambiente especificada não é aplicada ao dotnet run processo.

  As variáveis de ambiente passadas por essa opção têm precedência sobre variáveis de ambiente ambiente, diretivas System.CommandLine env e environmentVariables do perfil de inicialização escolhido. Para obter mais informações, confira Variáveis de ambiente.

  (Essa opção foi adicionada ao SDK do .NET 9.0.200.)

• -f|--framework <FRAMEWORK>

  Compila e executa o aplicativo usando a estrutura especificada. A estrutura deve ser especificada no arquivo de projeto.

• --file <FILE_PATH>

  O caminho para o aplicativo baseado em arquivo a ser executado. Se um caminho não for especificado, o diretório atual será usado para localizar e executar o arquivo. Para obter mais informações sobre aplicativos baseados em arquivo, consulte Criar aplicativos C# baseados em arquivo.

  No Unix, você pode executar aplicativos baseados em arquivo diretamente, usando o nome do arquivo de origem na linha de comando em vez de dotnet run. Primeiro, verifique se o arquivo tem permissões de execução. Em seguida, adicione uma linha #! shebang como a primeira linha do arquivo, por exemplo:

  #!/usr/bin/env dotnet run
  

  Em seguida, você pode executar o arquivo diretamente na linha de comando:

  ./ConsoleApp.cs
  

  Introduzido no SDK do .NET 10.0.100.

• --force

  Forçará todas as dependências a serem resolvidas mesmo se última restauração tiver sido bem-sucedida. A especificação desse sinalizador é o mesmo que a exclusão do arquivo project.assets.json.

• --interactive

  Permite que o comando pare e aguarde entrada ou ação do usuário. Por exemplo, para concluir a autenticação.

• --launch-profile <NAME>

  O nome do perfil de inicialização (se houver) a ser usado ao iniciar o aplicativo. Os perfis de inicialização são definidos no arquivo launchSettings.json e, normalmente, são chamados Development, Staging e Production. Para obter mais informações, consulte Working with multiple environments (Trabalhando com vários ambientes).

• --no-build

  Não compila o projeto antes da execução. Também define o sinalizador --no-restore implicitamente.

• --no-cache

  Ignore as verificações atualizadas e sempre crie o programa antes de ser executado.

• --no-dependencies

  Ao restaurar um projeto com referências de P2P (projeto a projeto), restaura o projeto raiz, não as referências.

• --no-launch-profile

  Não tenta usar launchSettings.json para configurar o aplicativo.

• --no-restore

  Não executa uma restauração implícita ao executar o comando.

• --no-self-contained

  Publique seu aplicativo como um aplicativo dependente da estrutura. Um runtime do .NET compatível deve ser instalado no computador de destino para executar seu aplicativo.

• --os <OS>

  Especifica o sistema operacional (SO) de destino. Essa é uma sintaxe abreviada para definir o RID (Identificador de Runtime), em que o valor fornecido é combinado com o RID padrão. Por exemplo, em um computador win-x64, a especificação de --os linux define o RID como linux-x64. Se você usar essa opção, não use a opção -r|--runtime. Disponível desde o .NET 6.

• --project <PATH>

  Especifica o caminho do arquivo de projeto a ser executado (nome da pasta ou caminho completo). Se não é especificado, ele usa como padrão o diretório atual.

  A abreviação -p de --project está preterida a partir do SDK do .NET 6. Por um tempo limitado, -p ainda pode ser usado para --project , apesar do aviso de substituição. Se o argumento fornecido para a opção não contiver =, o comando aceitará -p como abreviação de --project. Caso contrário, o comando pressupõe que -p seja abreviação para --property. Esse uso flexível de -p for --project será eliminado gradualmente no .NET 7.

• --property:<NAME>=<VALUE>

  Define uma ou mais propriedades MSBuild. Especifique várias propriedades delimitadas por ponto-e-vírgula ou repetindo a opção:

  --property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
  --property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>
  

  O formulário curto -p pode ser usado para --property. Se o argumento fornecido para a opção contiver =, -p será aceito como abreviação de --property. Caso contrário, o comando pressupõe que -p seja abreviação para --project.

  Para passar --property para o aplicativo em vez de definir uma propriedade MSBuild, forneça a opção após o separador de sintaxe --, por exemplo:

  dotnet run -- --property name=value
  

• -r|--runtime <RUNTIME_IDENTIFIER>

  Especifica o runtime de destino para o qual restaurar os pacotes. Para obter uma lista de RIDs (Identificadores de Runtime), veja o Catálogo de RIDs.

• --sc|--self-contained

  Publique o runtime do .NET com seu aplicativo para que o runtime não precise ser instalado no computador de destino.

• --tl:[auto|on|off]

  Especifica se o Agente de Terminal deve ser usado para a saída de build. O padrão é auto, que primeiro verifica o ambiente antes de habilitar o registro em log do terminal. A verificação de ambiente confirma se o terminal é capaz de usar recursos de saída modernos e não está usando uma saída padrão redirecionada antes de habilitar o novo agente. on ignora a verificação de ambiente e habilita o registro em log do terminal. off ignora a verificação de ambiente e usa o agente de console padrão.

  O Agente de Terminal mostra a fase de restauração seguida pela fase de build. Durante cada fase, os projetos de construção atuais aparecem na parte inferior do terminal. Cada projeto que está sendo criado gera tanto o destino do MSBuild em construção no momento quanto o tempo gasto nesse destino. Você pode pesquisar essas informações para saber mais sobre o build. Quando a build de um projeto é concluída, é gravada uma única seção "build concluída" que captura:

  • O nome do projeto criado.
  • A estrutura de destino (se houver vários destinos).
  • O status dessa build.
  • A saída primária dessa build (que contém um hiperlink).
  • Qualquer diagnóstico gerado para esse projeto.

  Esta opção está disponível desde o .NET 8.

• -v|--verbosity <LEVEL>

  Define o nível de detalhes do comando. Os valores permitidos são q[uiet], m[inimal], n[ormal], d[etailed] e diag[nostic]. O padrão é minimal. Para obter mais informações, consulte LoggerVerbosity.

• -?|-h|--help

  Imprime uma descrição de como usar o comando.

Variáveis de ambiente

Há quatro mecanismos pelos quais as variáveis de ambiente podem ser aplicadas ao aplicativo iniciado:

1. Variáveis de ambiente do sistema operacional quando o comando é executado.
2. Diretivas System.CommandLine env , como [env:key=value]. Elas se aplicam a todo dotnet run o processo, não apenas ao projeto que está sendo executado dotnet run.
3. environmentVariables do perfil de inicialização escolhido (-lp) no arquivolaunchSettings.json do projeto, se houver. Elas se aplicam ao projeto que está sendo executado por dotnet run.
4. -e|--environment Valores de opção da CLI (adicionados ao SDK do .NET versão 9.0.200). Elas se aplicam ao projeto que está sendo executado por dotnet run.

O ambiente é construído na mesma ordem que essa lista, portanto, a opção -e|--environment tem a precedência mais alta.

Exemplos

• Execute o projeto no diretório atual:

  dotnet run
  

• Execute o aplicativo baseado em arquivo especificado no diretório atual:

  dotnet run --file ConsoleApp.cs
  

  O suporte a aplicativos baseados em arquivo foi adicionado ao SDK do .NET 10.0.100.

• Execute o projeto especificado:

  dotnet run --project ./projects/proj1/proj1.csproj
  

• Execute o projeto no diretório atual, especificando a configuração de versão:

  dotnet run --property:Configuration=Release
  

• Execute o projeto no diretório atual (o argumento --help neste exemplo é passado para o aplicativo, visto que a opção vazia -- foi usada):

  dotnet run --configuration Release -- --help
  

• Restaure as dependências e as ferramentas para o projeto no diretório atual, apenas mostrando uma saída mínima e, em seguida, execute o projeto:

  dotnet run --verbosity m
  

• Execute o projeto no diretório atual usando a estrutura especificada e passe argumentos para o aplicativo:

  dotnet run -f net6.0 -- arg1 arg2
  

  No exemplo a seguir, três argumentos são passados para o aplicativo. Um argumento é passado usando -e dois argumentos são passados após --:

  dotnet run -f net6.0 -arg1 -- arg2 arg3