dotnet build

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

Name

dotnet build – Compila um projeto e todas as suas dependências.

Sinopse

dotnet build [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>] [-f|--framework <FRAMEWORK>]
    [--force] [--interactive] [--no-dependencies] [--no-incremental]
    [--no-restore] [--nologo] [--no-self-contained] [--os <OS>]
    [-o|--output <OUTPUT_DIRECTORY>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--self-contained [true|false]] [--source <SOURCE>]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet build -h|--help

Description

O comando dotnet build compila o projeto e suas dependências em um conjunto de binários. Os binários incluem o código do projeto em arquivos de linguagem intermediária (IL) com uma extensão .dll. A depender do tipo de projeto e das configurações, outros arquivos podem ser incluídos, tais como:

  • Um executável que pode ser usado para executar o aplicativo, se o tipo de projeto for um executável direcionado para o .NET Core 3.0 ou posterior.
  • Arquivos de símbolo usados para depuração com uma extensão .pdb.
  • Um arquivo .deps.jsno, que lista as dependências do aplicativo ou da biblioteca.
  • Um arquivo .runtimeconfig.jsno, que especifica o tempo de execução compartilhado e sua versão em um aplicativo.
  • Outras bibliotecas das quais o projeto depende (por meio de referências de projeto ou referências de pacote do NuGet).

Para projetos executáveis destinados a versões anteriores ao .NET Core 3.0, as dependências de biblioteca do NuGet normalmente NÃO são copiadas para a pasta de saída. Eles são resolvidos da pasta NuGet pacotes globais em tempo de executar. Com isso em mente, o produto de dotnet build não está pronto para ser transferido para outro computador para execução. Para criar uma versão do aplicativo que pode ser implantada, você precisa publicá-la (por exemplo, com o comando dotnet publish aplicativo). Para obter mais informações, consulte Implantação de aplicativos .NET.

Para projetos executáveis destinados ao .NET Core 3.0 e posteriores, as dependências da biblioteca são copiadas para a pasta de saída. Isso significa que, se não houver nenhuma outra lógica específica de publicação (como projetos Web), a saída do build deverá ser implantável.

Restauração implícita

A compilação exige o arquivo project.assets.json, que lista as dependências do seu aplicativo. O arquivo é criado quando dotnet restore é executado. Sem o arquivo de ativos em vigor, as ferramentas não conseguem resolver os assemblies de referência, o que resulta em erros.

Você não precisa executar dotnet restore o porque ele é executado implicitamente por todos os comandos que exigem a ocorrência de 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 --no-restore opção.

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

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

Esse comando oferece suporte às dotnet restore opções quando passadas na forma longa (por exemplo, --source ). Opções de formato curto, como -s, não são compatíveis.

Saída de biblioteca ou executável

O fato de o projeto ser executável ou não é determinado pela propriedade <OutputType> do arquivo de projeto. O seguinte exemplo mostra um projeto que produz um código executável:

<PropertyGroup>
  <OutputType>Exe</OutputType>
</PropertyGroup>

Para produzir uma biblioteca, omita a <OutputType> propriedade ou altere seu valor para Library . A DLL il de uma biblioteca não contém pontos de entrada e não pode ser executada.

MSBuild

O dotnet build usa o MSBuild para compilar o projeto e, portanto, dá suporte a builds paralelos e incrementais. Para obter mais informações, consulte Compilações incrementais.

Além das próprias opções, o comando dotnet build também aceita opções do MSBuild, como -p para configurar propriedades ou -l para definir um agente. Para obter mais informações sobre essas opções, confira a Referência de linha de comando do MSBuild. Ou você também pode usar o comando dotnet msbuild.

Observação

Quando dotnet build é executado automaticamente por , dotnet run argumentos como não são -property:property=value respeitados.

A execução é equivalente à execução ; no entanto, o dotnet build detalhes padrão da saída é dotnet msbuild -restore diferente.

Downloads de manifesto de carga de trabalho

Quando você executar esse comando, ele iniciará um download em segundo plano assíncrono de manifestos de anúncios para cargas de trabalho. Se o download ainda estiver em execução quando esse comando for final, o download será interrompido. Para obter mais informações, consulte Manifestos de anúncio.

Argumentos

PROJECT | SOLUTION

O arquivo de projeto ou solução a ser compilado. Se um arquivo de solução ou projeto não for especificado, o MSBuild pesquisará o diretório de trabalho atual em busca de um arquivo que tenha uma extensão terminada em proj ou sln e usará esse arquivo.

Opções

  • -a|--arch <ARCHITECTURE>

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

  • -c|--configuration <CONFIGURATION>

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

  • -f|--framework <FRAMEWORK>

    Compila para uma estrutura específica. A estrutura precisa ser definida no arquivo de projeto.

  • --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.

  • -?|-h|--help

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

  • --interactive

    Permite que o comando pare e aguarde entrada ou ação do usuário. Por exemplo, para concluir a autenticação. Disponível desde o SDK do .NET Core 3.0.

  • --no-dependencies

    Ignora as referências P2P (projeto a projeto) e compila apenas o projeto raiz especificado.

  • --no-incremental

    Marca o build como não segura para build incremental. Esse sinalizador desativa a compilação incremental e força uma nova recompilação do grafo de dependência do projeto.

  • --no-restore

    Não executa uma restauração implícita durante o build.

  • --nologo

    Não exibe a faixa de inicialização nem a mensagem de direitos autorais. Disponível desde o SDK do .NET Core 3.0.

  • --no-self-contained

    Publica o aplicativo como um aplicativo dependente de estrutura. Um runtime do .NET compatível deve ser instalado no computador de destino para executar o aplicativo. Disponível desde o SDK do .NET 6.

  • -o|--output <OUTPUT_DIRECTORY>

    Diretório no qual os binários compilados são colocados. Se não for especificado, o caminho padrão será ./bin/<configuration>/<framework>/. Para projetos com várias estruturas de destino (por meio da propriedade ), você também precisa TargetFrameworks definir quando especificar essa --framework opção.

  • --os <OS>

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

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Especifica o runtime de destino. Para obter uma lista de RIDs (Identificadores de Runtime), veja o Catálogo de RIDs. Se você usar essa opção com o SDK do .NET 6, use --self-contained ou --no-self-contained também.

  • --self-contained [true|false]

    Publica o runtime do .NET com o aplicativo para que o runtime não precise ser instalado no computador de destino. O padrão será true se um identificador de runtime for especificado. Disponível desde o SDK do .NET 6.

  • --source <SOURCE>

    O URI da origem NuGet pacote a ser usado durante a operação de restauração.

  • -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.

  • --version-suffix <VERSION_SUFFIX>

    Define o valor da propriedade $(VersionSuffix) a ser usada ao compilar o projeto. Isso funcionará apenas se a propriedade $(Version) não estiver definida. Em seguida, $(Version) é definido como o $(VersionPrefix) combinado com o $(VersionSuffix), separado por um traço.

Exemplos

  • Compile um projeto e suas dependências:

    dotnet build
    
  • Compile um projeto e suas dependências usando a configuração da Versão:

    dotnet build --configuration Release
    
  • Compile um projeto e suas dependências para um runtime específico (no exemplo, Ubuntu 18.04):

    dotnet build --runtime ubuntu.18.04-x64
    
  • Crie o projeto e use a fonte NuGet pacote especificada durante a operação de restauração:

    dotnet build --source c:\packages\mypackages
    
  • Compile o projeto e defina a versão 1.2.3.4 como um parâmetro de compilação usando a -p opção MSBuild:

    dotnet build -p:Version=1.2.3.4