Kompilowanie, testowanie i wdrażanie projektów platformy .NET Core

Usługi Azure DevOps | Azure DevOps Server | Azure DevOps Server 2022

W tym artykule opisano sposób pracy z projektami platformy .NET Core przy użyciu usługi Azure Pipelines. W tym artykule przedstawiono następujące zadania:

Wymagania wstępne

Tworzenie projektu platformy .NET i przekazywanie go do usługi GitHub

Jeśli chcesz użyć projektu platformy .NET, który znajduje się już w repozytorium GitHub, możesz pominąć tę sekcję.

Jeśli nie masz projektu platformy .NET do pracy, utwórz nowy na komputerze lokalnym w następujący sposób:

1. Zainstaluj zestaw .NET 8.0 SDK lub upewnij się, że jest zainstalowany.
2. Otwórz okno terminalu na komputerze lokalnym.
3. Utwórz katalog projektu i przejdź do niego.
4. Utwórz nową aplikację internetową platformy .NET 8, uruchamiając polecenie dotnet new webapp -f net8.0.
5. Skompiluj i uruchom aplikację lokalnie przy użyciu polecenia dotnet run.
6. Po uruchomieniu aplikacji naciśnij Ctrl+C, aby ją zamknąć.
7. Przekaż lub połącz projekt lokalny z repozytorium GitHub.

Stwórz potok

Jeśli masz potok, którego chcesz użyć, możesz pominąć tę sekcję. W przeciwnym razie można użyć albo edytora potoku YAML, albo edytora klasycznego do utworzenia potoku.

Masz teraz działający potok przetwarzania gotowy do dostosowania.

Konfigurowanie środowiska kompilacji

steps:
- task: UseDotNet@2
  inputs:
    version: '8.x'

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse

pool:
  vmImage: 'ubuntu-latest' 

steps:
- task: UseDotNet@2
  inputs:
    version: '8.x'

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

Przywracanie zależności

Pakiety NuGet umożliwiają projektowi korzystanie z kodu, który nie jest kompilowany. Uruchom polecenie , dotnet restore aby pobrać pakiety NuGet i narzędzia specyficzne dla projektu. To polecenie można uruchomić za pomocą zadania .NET Core (DotNetCoreCLI@2) lub jako skryptu w potoku. Polecenie dotnet restore używa NuGet.exe spakowanego za pomocą zestawu .NET Core SDK i może przywracać tylko pakiety określone w plikach *.csproj projektu .NET Core.

Użyj zadania .NET Core (DotNetCoreCLI@2), aby pobrać i przywrócić pakiety NuGet z usługi Azure Artifacts, NuGet.org lub innego uwierzytelnionego zewnętrznego lub wewnętrznego repozytorium NuGet. Jeśli źródło danych NuGet znajduje się w tym samym projekcie co potok, nie musisz się uwierzytelniać. Aby uzyskać więcej informacji, zobacz .NET Core task (DotNetCoreCLI@2).

Poniższy potok używa DotNetCoreCLI@2 zadania do przywrócenia źródła danych usługi Azure Artifact.

trigger:
- main

pool:
  vmImage: 'windows-latest'

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 8.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

variables:
  buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    feedsToUse: 'select'
    vstsFeed: 'my-vsts-feed' # A series of numbers and letters

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    arguments: '--configuration $(buildConfiguration)'
  displayName: 'dotnet build $(buildConfiguration)'

Platforma .NET automatycznie przywraca pakiety podczas uruchamiania poleceń, takich jak dotnet build. Nadal musisz użyć zadania .NET Core (DotNetCoreCLI@2), aby przywrócić pakiety, jeśli używasz uwierzytelnionego źródła danych.

Zarządzaj poświadczeniami dla uwierzytelnionego źródła, tworząc połączenie usługi NuGet w Ustawieniach projektu>Potoki>Połączenia usług. Aby uzyskać więcej informacji na temat połączeń usługi NuGet, zobacz Publikowanie pakietów NuGet za pomocą usługi Azure Pipelines.

Przywracanie pakietów z NuGet.org

Aby przywrócić pakiety z NuGet.org, zaktualizuj potok w następujący sposób.

steps:
- task: DotNetCoreCLI@2
  displayName: Restore
  inputs:
    command: restore
    projects: '**/*.csproj'
    feedsToUse: select

Przywracanie pakietów z zewnętrznego źródła danych

Aby określić zewnętrzne repozytorium NuGet, umieść adres URL w pliku NuGet.config w repozytorium. Upewnij się, że w pliku NuGet.config określono dowolne źródło danych niestandardowych i że poświadczenia są określone w połączeniu usługi NuGet.

Aby przywrócić pakiety z zewnętrznego źródła danych, dodaj restore zadanie zgodnie z instrukcjami w poprzedniej sekcji, ale zmień ustawienia konfiguracji w następujący sposób:

steps:
- task: DotNetCoreCLI@2
  displayName: Restore
  inputs:
    command: restore
    projects: '**/*.csproj'
    feedsToUse: config
    nugetConfigPath: NuGet.config    # Relative to root of the repository
    externalFeedCredentials: <NuGet service connection>

Przywracanie pakietów dla projektów programu .NET Framework

Jeśli rozwiązanie zawiera projekt .NET Framework lub używasz package.json do określania zależności, użyj zadania NuGetCommand@2 , aby przywrócić te zależności.

- task: NuGetCommand@2
  inputs:
    command: 'restore'
    restoreSolution: '**/*.sln'
    feedsToUse: 'select'

Zbuduj swój projekt

Skompiluj swój projekt .NET Core, uruchamiając polecenie dotnet build. Polecenie można dodać do potoku za pomocą zadania .NET Core (DotNetCoreCLI@2) lub jako skrypt wiersza polecenia.

Użyj zadania .NET Core

steps:
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

Kompilowanie platformy .NET Core za pomocą skryptu wiersza polecenia

Możesz również skompilować przy użyciu skryptu wiersza polecenia.

steps:
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'

Dodawanie innych poleceń zestawu .NET SDK do potoku

Do potoku można dodać inne polecenia zestawu SDK platformy .NET za pomocą zadania .NET Core (DotNetCoreCLI@2) lub skryptów.

Dodaj polecenie .NET CLI za pomocą zadania .NET Core

Zadanie .NET Core (DotNetCoreCLI@2) umożliwia łatwe dodawanie poleceń interfejsu wiersza polecenia platformy .NET do potoku. Zadania platformy .NET Core (DotNetCoreCLI@2) można dodawać, edytując plik YAML lub za pomocą edytora klasycznego.

steps:
# ...
- script: dotnet test <test-project> 

Instalowanie narzędzia

Aby zainstalować narzędzie globalne platformy .NET Core, takie jak dotnetsay w kompilacji uruchomionej w systemie Windows, dodaj zadanie platformy .NET Core i ustaw następujące właściwości w konfiguracji:

• Polecenie: niestandardowe
• Ścieżka do projektów: pozostaw puste
• Polecenie niestandardowe: tool
• Argumenty: install -g dotnetsay

Aby uruchomić narzędzie, dodaj zadanie Wiersz polecenia i wprowadź dotnetsay w polu Skrypt.

Uruchamianie testów

Gdy repozytorium zawiera projekty testowe, użyj zadania .NET Core (DotNetCoreCLI@2), aby uruchamiać testy jednostkowe przy użyciu struktur testowych, takich jak MSTest, xUnit i NUnit. Projekt testowy musi odwoływać się do zestawu Microsoft.NET.Test.SDK w wersji 15.8.0 lub nowszej.

Usługa automatycznie publikuje wyniki testów. Można je zobaczyć w podsumowaniu kompilacji. Skorzystaj z wyników testu, aby rozwiązać problemy z testami, które zakończyły się niepowodzeniem, i przeanalizować czas testu.

Aby dodać zadanie testowe do potoku, dodaj następujący fragment kodu do pliku azure-pipelines.yml :

steps:
# ...
# do this after other tasks such as build
- task: DotNetCoreCLI@2
  inputs:
    command: test
    projects: '**/*Tests/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

Jeśli używasz asystenta zadań do dodawania zadania .NET Core (DotNetCoreCLI@2), ustaw następujące właściwości:

• Polecenie: test
• Ścieżka do projektów: ustaw ścieżkę do projektów testowych w rozwiązaniu
• Argumenty: --configuration $(BuildConfiguration)

Alternatywnie, uruchom polecenie dotnet test z określonym rejestratorem, a następnie użyj zadania PublishTestResults@2.

steps:
# ...
# do this after your tests run
- script: dotnet test <test-project> --logger trx
- task: PublishTestResults@2
  condition: succeededOrFailed()
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'

Zbieranie pokrycia kodu

Podczas kompilacji na platformie Windows można zbierać metryki pokrycia kodu przy użyciu wbudowanego modułu zbierającego dane pokrycia. Projekt testowy musi odwoływać się do zestawu Microsoft.NET.Test.SDK w wersji 15.8.0 lub nowszej.

Gdy korzystasz z zadania .NET Core (DotNetCoreCLI@2) do uruchamiania testów, pipeline automatycznie publikuje dane dotyczące pokrycia kodu na serwerze. Możesz pobrać plik *.coverage z podsumowania kompilacji, aby wyświetlić go w programie Visual Studio.

Aby zbierać informacje o pokryciu kodu, dodaj argument --collect "Code Coverage" podczas dodawania zadania testowego do potoku.

steps:
# ...
# do this after other tasks such as build
- task: DotNetCoreCLI@2
  inputs:
    command: test
    projects: '**/*Tests/*.csproj'
    arguments: '--configuration $(buildConfiguration) --collect "Code Coverage"'

Jeśli używasz asystenta zadań do dodawania zadania .NET Core (DotNetCoreCLI@2), ustaw następujące właściwości:

• Polecenie: test
• Ścieżka do projektów: Ustaw ścieżkę do projektów testowych w rozwiązaniu
• Argumenty: --configuration $(BuildConfiguration) --collect "Code Coverage"

Upewnij się, że opcja Publikuj wyniki testu pozostaje zaznaczona.

Alternatywnie, aby zebrać wyniki pokrycia kodu za pomocą polecenia dotnet test z określonym rejestratorem danych, a następnie uruchomić zadanie PublishTestResults@2, użyj następującego kodu:

steps:
# ...
# do this after your tests run
- script: dotnet test <test-project> --logger trx --collect "Code Coverage"
- task: PublishTestResults@2
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'

Zbierz metryki pokrycia kodu za pomocą Coverlet

W przypadku kompilacji w systemie Linux lub macOS użyj rozwiązania Coverlet lub podobnego narzędzia, aby zebrać metryki pokrycia kodu.

Wyniki pokrycia kodu można opublikować na serwerze za pomocą zadania Publikuj wyniki pokrycia kodu (PublishCodeCoverageResults@2). Należy skonfigurować narzędzie pokrycia, aby wygenerować wyniki w formacie pokrycia Cobertura lub JaCoCo.

Aby uruchomić testy i opublikować raport pokrycia kodu przy użyciu narzędzia Coverlet:

1. Dodaj odwołanie do coverlet.collector pakietu NuGet.
2. Dodaj następujący fragment kodu do pliku azure-pipelines.yml . Nie dodawaj dodatkowych DataCollectionRunSettings argumentów, ponieważ XPlat Code Coverage moduł zbierający tworzy już raport Cobertura.

- task: UseDotNet@2
  inputs:
    version: '8.x'
  
- task: DotNetCoreCLI@2
  displayName: 'dotnet build'
  inputs:
    command: 'build'
    arguments: '--configuration $(buildConfiguration)'
  
- task: DotNetCoreCLI@2
  displayName: 'dotnet test'
  inputs:
    command: 'test'
    arguments: '--configuration $(buildConfiguration) --collect:"XPlat Code Coverage"'
    publishTestResults: true
    projects: '<test project directory>'
  
- task: PublishCodeCoverageResults@2
  displayName: 'Publish code coverage report'
  inputs:
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

Pakietowanie i dostarczanie kodu

Aby spakować i dostarczyć dane wyjściowe kompilacji, możesz:

• Publikowanie artefaktów kompilacji w usłudze Azure Pipelines.
• Utwórz pakiet NuGet i opublikuj go w kanale informacyjnym NuGet.
• Opublikuj pakiet NuGet w usłudze Azure Artifacts.
• Utwórz archiwum ZIP do wdrożenia w aplikacji internetowej.
• Publikowanie symboli na serwerze symboli usługi Azure Artifacts lub w udziale plików.

Możesz również utworzyć obraz dla aplikacji i wypchnąć go do rejestru kontenerów.

Publikowanie artefaktów w usłudze Azure Pipelines

steps:

- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'myWebsite'

steps:

- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: true
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'

Aby uzyskać więcej informacji, zobacz Publikowanie i pobieranie artefaktów kompilacji.

Opublikuj w kanale NuGet

Aby utworzyć pakiet NuGet i opublikować go w kanale informacyjnym NuGet, dodaj następujący fragment kodu do pliku azure-pipelines.yml :

steps:
# ...
# do this near the end of your pipeline
- script: dotnet pack /p:PackageVersion=$(version)  # define the version variable elsewhere in your pipeline
- task: NuGetAuthenticate@1
  inputs:
    nuGetServiceConnections: '<NuGet service connection>'
- task: NuGetCommand@2
  inputs:
    command: push
    nuGetFeedType: external
    publishFeedCredentials: '<NuGet service connection>'
    versioningScheme: byEnvVar
    versionEnvVar: version

Aby uzyskać więcej informacji na temat przechowywania wersji i publikowania pakietów NuGet, zobacz Publikowanie pakietów NuGet za pomocą usługi Azure Pipelines.

Publikowanie pakietu NuGet w usłudze Azure Artifacts

Pakiety NuGet można opublikować w kanale informacyjnym usługi Azure Artifacts przy użyciu zadania NuGetCommand@2 . Aby uzyskać więcej informacji, zobacz Publikowanie pakietów NuGet za pomocą usługi Azure Pipelines.

Publikowanie archiwum pliku ZIP w aplikacji internetowej

Aby utworzyć archiwum plików ZIP, które jest gotowe do opublikowania w aplikacji internetowej, dodaj następujący fragment kodu do azure-pipelines.yml. Uruchom to zadanie po utworzeniu aplikacji w pobliżu końca potoku w większości przypadków. Na przykład uruchom to zadanie przed wdrożeniem do aplikacji internetowej Azure w systemie Windows.

steps:
# ...
- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

Aby opublikować to archiwum w aplikacji internetowej, zobacz Wdrażanie usługi Azure Web Apps.

Opublikuj symbole

Za pomocą PublishSymbols@2 zadania można publikować symbole na serwerze symboli usługi Azure Artifacts lub w udziale plików. Aby uzyskać więcej informacji, zobacz Publikowanie symboli.

Aby na przykład opublikować symbole w udziale plików, dodaj następujący fragment kodu do pliku azure-pipelines.yml :

- task: PublishSymbols@2
  inputs:
    SymbolsFolder: '$(Build.SourcesDirectory)'
    SearchPattern: '**/bin/**/*.pdb'
    IndexSources: true
    PublishSymbols: true
    SymbolServerType: 'FileShare' 
    SymbolsPath: '\\<server>\<shareName>'

Aby użyć edytora klasycznego, dodaj do potoku zadanie Indeksuj źródła i opublikuj symbole .

Rozwiązywanie problemów

Jeśli projekt kompiluje się pomyślnie na komputerze lokalnym, ale nie w usłudze Azure Pipelines, zapoznaj się z następującymi potencjalnymi przyczynami i działaniami naprawczymi.

• Nowa wersja zestawu .NET Core SDK lub Visual Studio może spowodować przerwanie kompilacji. Może na przykład zawierać nowszą wersję lub funkcję narzędzia NuGet. Upewnij się, że wersje zestawu SDK platformy .NET Core oraz środowisko uruchomieniowe na komputerze programisty są takie same jak na agencie potoku.

  Możesz dołączyć do swojego potoku dotnet --version skrypt wiersza polecenia, aby wyświetlić wersję zestawu SDK platformy .NET Core. Użyj Instalatora narzędzi platformy .NET Core , aby wdrożyć tę samą wersję na agencie, lub zaktualizuj projekty i maszynę programową do wersji potoku zestawu .NET Core SDK.

• Problemy z połączeniem mogą powodować sporadyczne niepowodzenie kompilacji podczas przywracania pakietów z NuGet.org. NuGet.org mogą występować problemy lub mogą występować problemy z siecią między centrum danych platformy Azure i NuGet.org. Możesz sprawdzić, czy użycie usługi Azure Artifacts ze źródłami nadrzędnymi w celu buforowania pakietów zwiększa niezawodność kompilacji.

  Potok przetwarzania automatycznie używa swoich poświadczeń do połączenia z Azure Artifacts. Te poświadczenia zazwyczaj pochodzą z konta usługi Project Collection Build Service . Aby dowiedzieć się więcej na temat używania usługi Azure Artifacts do buforowania pakietów NuGet, zobacz Nawiązywanie połączenia z źródłami danych usługi Azure Artifact.

• Być może używasz w Visual Studio logiki, która nie jest uwzględniona w Twoim potoku. Usługa Azure Pipelines uruchamia każde polecenie w zadaniu sekwencyjnie w nowym procesie. Sprawdź dzienniki z kompilacji potoków, aby wyświetlić dokładne polecenia uruchomione w kompilacji. Aby zlokalizować problem, powtórz te same polecenia w tej samej kolejności na maszynie dewelopera.

• Jeśli masz mieszane rozwiązanie obejmujące niektóre projekty .NET Core i niektóre projekty programu .NET Framework, użyj zadania NuGet , aby przywrócić pakiety określone w plikach packages.config . Dodaj zadanie MSBuild lub Visual Studio Build, aby skompilować projekty programu .NET Framework.

Treści powiązane

• Azure Artifacts
• Zadania kompilacji i wydawania
• Narzędzia wiersza polecenia .NET Core
• Testowanie jednostkowe w projektach platformy .NET Core