PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchAo digitar dotnet run, a CLI do .NET seleciona um projeto, restaura pacotes NuGet quando necessário, aciona o build e inicia o aplicativo. Um perfil compatível de launchSettings.json também pode influenciar a inicialização. É um atalho voltado ao desenvolvimento: não equivale simplesmente a executar uma DLL já compilada nem é a forma recomendada de implantar um aplicativo em produção.
1. A CLI encontra o projeto a executar
Sem um caminho informado, dotnet run usa o diretório atual como contexto para localizar o projeto. Para escolher um projeto em outro local ou especificar o arquivo do projeto, use --project. O comando opera sobre projetos; para executar uma DLL framework-dependent já existente, a forma documentada é dotnet nome.dll. Consulte a referência do comando dotnet run e a visão geral da CLI do .NET.
As an Amazon Associate I earn from qualifying purchases.
Se o projeto tiver como alvo vários frameworks, a CLI precisa saber qual usar. Informe-o com --framework; sem uma escolha inequívoca, o comando falha por ambiguidade.
2. Dependências NuGet são restauradas quando necessário
Não é preciso executar dotnet restore manualmente antes de cada execução. Quando necessário, dotnet run aciona a restauração: o NuGet resolve as dependências referenciadas pelo projeto, baixa os pacotes ausentes, verifica compatibilidade e os disponibiliza no cache local. O resultado pode variar conforme o estado do cache e as dependências do projeto. A Microsoft descreve esse processo na documentação de dotnet restore.
#1 Best Overall
--no-restorepula a restauração implícita, mas não o build.--forceforça a resolução das dependências.
3. O projeto é compilado por meio do build
dotnet run depende de dotnet build. O build usa MSBuild para compilar o projeto e suas dependências; a documentação da CLI descreve dotnet build como equivalente a dotnet msbuild -restore, embora os níveis de verbosidade padrão sejam diferentes. Isso não significa que dotnet run seja apenas um alias textual universal para build seguido de uma chamada: run tem opções próprias e também controla a execução do processo. Veja a documentação de dotnet build e dotnet msbuild.
Onde ficam os artefatos
Por padrão, os resultados do build vão para bin/<configuration>/<target>, normalmente bin/Debug/<target>; arquivos temporários ficam em obj. O valor de configuração pode ser alterado, por exemplo, com --configuration Release. Saídas existentes podem ser sobrescritas conforme necessário. Esses caminhos são os padrões documentados, não uma garantia para projetos com propriedades MSBuild ou configuração próprias.
O que muda com as opções de build
--no-buildpula o build e também implica--no-restore. Use-o somente quando os artefatos necessários já estiverem disponíveis.--no-restorepula apenas a restauração; o build ainda pode ocorrer.
4. A CLI inicia o processo com perfil e configuração
Um perfil suportado em launchSettings.json pode definir o tipo de comando, argumentos e variáveis de ambiente usados na inicialização. Para dotnet run, os tipos de perfil com suporte são Project e Executable. Use --no-launch-profile para ignorar esse arquivo. Portanto, o comportamento de inicialização não é determinado apenas pelo código: também pode depender do perfil selecionado e das configurações do projeto.
Recommended Free Tools
A opção --environment KEY=VALUE configura o ambiente do processo iniciado e, segundo a documentação da Microsoft, prevalece sobre valores de ambiente definidos pelo perfil. Ela foi adicionada no SDK 9.0.200; confirme a disponibilidade no SDK instalado antes de usá-la. A referência de dotnet run registra essa e outras opções com suas versões mínimas.
5. Argumentos da CLI e do aplicativo são separados por --
As opções antes de -- pertencem à CLI; os argumentos depois dele são encaminhados ao aplicativo. Essa separação evita que uma opção destinada ao programa seja interpretada como opção do comando, inclusive quando a CLI ganhar novas opções em versões futuras.
dotnet run --project ConsoleApp.csproj -- --app-flag --app-name A.txtNesse exemplo documentado, --project ConsoleApp.csproj seleciona o projeto e os valores após o segundo -- são argumentos do aplicativo.
Rank #4
Quando faz sentido usar dotnet run?
A Microsoft caracteriza o comando como uma forma conveniente de executar um aplicativo a partir do código-fonte com um comando. Ele é apropriado para o ciclo iterativo de desenvolvimento, em que é útil restaurar, compilar e iniciar o projeto sem invocar cada etapa separadamente.
Para produção, a orientação da documentação é publicar o aplicativo com dotnet publish e implantar a saída publicada. dotnet run usa dependências em cache e não é recomendado como mecanismo de execução em produção. Para uma DLL framework-dependent já compilada, use dotnet nome.dll, em vez de tratar dotnet run como um executor genérico de assemblies.
O que pode alterar a sequência
O caminho concreto depende do projeto, do framework-alvo, do SDK instalado, do cache, das propriedades MSBuild, do perfil de inicialização e das opções fornecidas. A página principal de dotnet run cobre o .NET SDK 6 e posteriores, mas nem toda opção existe em todas essas versões: --artifacts-path foi adicionada no SDK 8, --environment no SDK 9.0.200 e --file no SDK 10.0.100. Consulte a versão mínima associada à opção na documentação oficial antes de incluí-la em um script ou fluxo de trabalho.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
