dotnet build

  • Artykuł
  • Czas czytania: 5 min

Ten artykuł dotyczy: ✔️ zestaw .NET Core 3.1 SDK i nowsze wersje

Nazwa

dotnet build — Tworzy projekt i wszystkie jego zależności.

Streszczenie

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

Opis

Polecenie dotnet build kompiluje projekt i jego zależności w zestawie plików binarnych. Pliki binarne obejmują kod projektu w plikach języka pośredniego (IL) z rozszerzeniem .dll . W zależności od typu i ustawień projektu mogą znajdować się inne pliki, takie jak:

  • Plik wykonywalny, który może służyć do uruchamiania aplikacji, jeśli typ projektu jest plikiem wykonywalnym przeznaczonym dla platformy .NET Core 3.0 lub nowszej.
  • Pliki symboli używane do debugowania z rozszerzeniem .pdb .
  • Plik deps.json zawierający listę zależności aplikacji lub biblioteki.
  • Plik .runtimeconfig.json , który określa środowisko uruchomieniowe udostępnione i jego wersję dla aplikacji.
  • Inne biblioteki, od których zależy projekt (za pośrednictwem odwołań do projektu lub odwołań do pakietu NuGet).

W przypadku projektów wykonywalnych przeznaczonych dla wersji starszych niż .NET Core 3.0 zależności biblioteki z NuGet zwykle nie są kopiowane do folderu wyjściowego. Są one rozpoznawane z folderu pakietów globalnych NuGet w czasie wykonywania. Mając to na uwadze, produkt nie dotnet build jest gotowy do przeniesienia na inną maszynę do uruchomienia. Aby utworzyć wersję aplikacji, którą można wdrożyć, należy ją opublikować (na przykład za pomocą polecenia dotnet publish ). Aby uzyskać więcej informacji, zobacz Wdrażanie aplikacji platformy .NET.

W przypadku projektów wykonywalnych przeznaczonych dla platformy .NET Core 3.0 i nowszych zależności bibliotek są kopiowane do folderu wyjściowego. Oznacza to, że jeśli nie ma żadnej innej logiki specyficznej dla publikowania (takiej jak projekty internetowe), dane wyjściowe kompilacji powinny być wdrażalne.

Niejawne przywracanie

Kompilowanie wymaga pliku project.assets.json , który zawiera listę zależności aplikacji. Plik jest tworzony po dotnet restore wykonaniu. Bez pliku zasobów narzędzia nie mogą rozwiązywać problemów z zestawami referencyjnymi, co powoduje błędy.

Nie trzeba uruchamiać, dotnet restore ponieważ jest ona uruchamiana niejawnie przez wszystkie polecenia, które wymagają przywrócenia, takie jak dotnet new, dotnet build, dotnet run, , dotnet test, , dotnet publishi dotnet pack. Aby wyłączyć niejawne przywracanie, użyj --no-restore opcji .

Polecenie dotnet restore jest nadal przydatne w niektórych scenariuszach, w których jawne przywracanie ma sens, takie jak kompilacje ciągłej integracji w Azure DevOps Services lub w systemach kompilacji, które muszą jawnie kontrolować po zakończeniu przywracania.

Aby uzyskać informacje na temat zarządzania kanałami informacyjnymi NuGet, zobacz dokumentacjędotnet restore.

To polecenie obsługuje dotnet restore opcje przekazywane w długim formularzu (na przykład --source). Krótkie opcje formularza, takie jak -s, nie są obsługiwane.

Dane wyjściowe pliku wykonywalnego lub biblioteki

Określa, czy projekt jest wykonywalny, czy nie jest określany przez <OutputType> właściwość w pliku projektu. W poniższym przykładzie przedstawiono projekt, który tworzy kod wykonywalny:

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

Aby utworzyć bibliotekę, pomiń <OutputType> właściwość lub zmień jej wartość na Library. Biblioteka DLL IL dla biblioteki nie zawiera punktów wejścia i nie można jej wykonać.

MSBuild

dotnet buildużywa MSBuild do kompilowania projektu, dlatego obsługuje zarówno kompilacje równoległe, jak i przyrostowe. Aby uzyskać więcej informacji, zobacz Kompilacje przyrostowe.

Oprócz jego opcji dotnet build polecenie akceptuje MSBuild opcje, takie jak -p ustawianie właściwości lub -l definiowanie rejestratora. Aby uzyskać więcej informacji na temat tych opcji, zobacz dokumentację MSBuild Command-Line. Możesz też użyć polecenia dotnet msbuild .

Uwaga

Po dotnet build automatycznym uruchomieniu przez dotnet runargumenty takie jak -property:property=value nie są przestrzegane.

Uruchomienie jest równoważne z dotnet build uruchomionym poleceniem dotnet msbuild -restore; jednak domyślna szczegółowość danych wyjściowych jest inna.

Pliki do pobrania manifestu obciążenia

Po uruchomieniu tego polecenia inicjuje asynchroniczne pobieranie manifestów reklamowych dla obciążeń. Jeśli pobieranie jest nadal uruchomione po zakończeniu tego polecenia, pobieranie zostanie zatrzymane. Aby uzyskać więcej informacji, zobacz Manifesty reklamowe.

Argumenty

PROJECT | SOLUTION

Plik projektu lub rozwiązania do skompilowania. Jeśli nie określono pliku projektu lub rozwiązania, MSBuild przeszukuje bieżący katalog roboczy dla pliku z rozszerzeniem pliku, które kończy się na pliku proj lub sln i używa tego pliku.

Opcje

  • -a|--arch <ARCHITECTURE>

    Określa architekturę docelową. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określ ustawienie --arch x86 identyfikatora RID na win-x86wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime opcji. Dostępne od platformy .NET 6 (wersja zapoznawcza 7).

  • -c|--configuration <CONFIGURATION>

    Definiuje konfigurację kompilacji. Wartość domyślna dla większości projektów to Debug, ale można zastąpić ustawienia konfiguracji kompilacji w projekcie.

  • -f|--framework <FRAMEWORK>

    Kompiluje dla określonej platformy. Struktura musi być zdefiniowana w pliku projektu.

  • --force

    Wymusza rozwiązanie wszystkich zależności, nawet jeśli ostatnie przywracanie zakończyło się pomyślnie. Określenie tej flagi jest takie samo jak usunięcie pliku project.assets.json .

  • -?|-h|--help

    Wyświetla opis sposobu używania polecenia.

  • --interactive

    Umożliwia zatrzymanie polecenia i oczekiwanie na wprowadzenie lub działanie użytkownika. Na przykład w celu ukończenia uwierzytelniania. Dostępny od zestawu .NET Core 3.0 SDK.

  • --no-dependencies

    Ignoruje odwołania do projektu (P2P) i kompiluje tylko określony projekt główny.

  • --no-incremental

    Oznacza kompilację jako niebezpieczną dla kompilacji przyrostowej. Ta flaga wyłącza kompilację przyrostową i wymusza czystą kompilację grafu zależności projektu.

  • --no-restore

    Nie wykonuje niejawnego przywracania podczas kompilacji.

  • --nologo

    Nie wyświetla baneru startowego ani komunikatu o prawach autorskich.

  • --no-self-contained

    Publikuje aplikację jako aplikację zależną od platformy. Aby uruchomić aplikację, na maszynie docelowej musi być zainstalowane zgodne środowisko uruchomieniowe platformy .NET. Dostępne od zestawu .NET 6 SDK.

  • -o|--output <OUTPUT_DIRECTORY>

    Katalog, w którym mają być umieszczane skompilowane pliki binarne. Jeśli nie zostanie określona, domyślna ścieżka to ./bin/<configuration>/<framework>/. W przypadku projektów z wieloma platformami docelowymi (za pośrednictwem TargetFrameworks właściwości) należy również zdefiniować --framework podczas określania tej opcji.

  • --os <OS>

    Określa docelowy system operacyjny. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określ ustawienie --os linux identyfikatora RID na linux-x64wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime opcji. Dostępne od platformy .NET 6.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Określa docelowe środowisko uruchomieniowe. Aby uzyskać listę identyfikatorów środowiska uruchomieniowego (RID), zobacz wykaz identyfikatorów RID. Jeśli używasz tej opcji z zestawem .NET 6 SDK, użyj --self-contained lub --no-self-contained użyj go również.

  • --self-contained [true|false]

    Publikuje środowisko uruchomieniowe platformy .NET z aplikacją, aby środowisko uruchomieniowe nie musi być zainstalowane na maszynie docelowej. Wartość domyślna to true jeśli określono identyfikator środowiska uruchomieniowego. Dostępne od zestawu .NET 6 SDK.

  • --source <SOURCE>

    Identyfikator URI źródła pakietu NuGet do użycia podczas operacji przywracania.

  • -v|--verbosity <LEVEL>

    Ustawia poziom szczegółowości polecenia. Dozwolone wartości to q[uiet], , m[inimal], d[etailed]n[ormal], i diag[nostic]. Wartość domyślna to minimal. Aby uzyskać więcej informacji, zobacz LoggerVerbosity.

  • --version-suffix <VERSION_SUFFIX>

    Ustawia wartość $(VersionSuffix) właściwości do użycia podczas kompilowania projektu. To działa tylko wtedy, gdy $(Version) właściwość nie jest ustawiona. $(Version) Następnie jest ustawiana na $(VersionPrefix) wartość połączoną z $(VersionSuffix)kreską rozdzieloną kreską.

Przykłady

  • Skompiluj projekt i jego zależności:

    dotnet build

  • Skompiluj projekt i jego zależności przy użyciu konfiguracji wydania:

    dotnet build --configuration Release

  • Skompiluj projekt i jego zależności dla określonego środowiska uruchomieniowego (w tym przykładzie Ubuntu 18.04):

    dotnet build --runtime ubuntu.18.04-x64

  • Skompiluj projekt i użyj określonego źródła pakietu NuGet podczas operacji przywracania:

    dotnet build --source c:\packages\mypackages

  • Skompiluj projekt i ustaw wersję 1.2.3.4 jako parametr kompilacji przy użyciu -popcji MSBuild:

    dotnet build -p:Version=1.2.3.4