{"meta":{"title":"Создание и тестирование для .NET","intro":"Узнайте, как создать рабочий процесс непрерывной интеграции (CI) для создания и тестирования проекта .NET.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/tutorials","title":"Учебники"},{"href":"/ru/actions/tutorials/build-and-test-code","title":"Сборка и тестирование кода"},{"href":"/ru/actions/tutorials/build-and-test-code/net","title":".NET"}],"documentType":"article"},"body":"# Создание и тестирование для .NET\n\nУзнайте, как создать рабочий процесс непрерывной интеграции (CI) для создания и тестирования проекта .NET.\n\n## Введение\n\nВ этом руководстве описано, как создать, протестировать и опубликовать пакет .NET.\n\nGitHub-размещенные средства запуска имеют кэш средств с предварительно установленным программным обеспечением, которое включает пакет SDK .NET Core. Полный список программного обеспечения up-to-date и предварительно установленных версий пакета SDK для .NET Core см. в программном [обеспечении, установленном на GitHubразмещенных запусках](/ru/actions/concepts/runners/github-hosted-runners).\n\n## Необходимые компоненты\n\nВы уже должны быть знакомы с синтаксисом YAML и его использованием GitHub Actions. Дополнительные сведения см. в разделе [Синтаксис рабочего процесса для GitHub Actions](/ru/actions/reference/workflows-and-actions/workflow-syntax).\n\nРекомендуется иметь базовое представление о пакете SDK для .NET Core. Дополнительные сведения см. в разделе [Приступая к работе с .NET](https://dotnet.microsoft.com/learn).\n\n## Использование шаблона рабочего процесса .NET\n\nЧтобы быстро приступить к работе, добавьте шаблон рабочего процесса в `.github/workflows` каталог репозитория.\n\nGitHubпредоставляет шаблон рабочего процесса для .NET, который должен работать для большинства .NET проектов. В последующих разделах этого руководства приведены примеры настройки этого шаблона рабочего процесса.\n\n1. На GitHubперейдите на главную страницу репозитория.\n\n2. Под именем репозитория щелкните **<svg version=\"1.1\" width=\"16\" height=\"16\" viewBox=\"0 0 16 16\" class=\"octicon octicon-play\" aria-label=\"play\" role=\"img\"><path d=\"M8 0a8 8 0 1 1 0 16A8 8 0 0 1 8 0ZM1.5 8a6.5 6.5 0 1 0 13 0 6.5 6.5 0 0 0-13 0Zm4.879-2.773 4.264 2.559a.25.25 0 0 1 0 .428l-4.264 2.559A.25.25 0 0 1 6 10.559V5.442a.25.25 0 0 1 .379-.215Z\"></path></svg> Actions**.\n\n   ![Снимок экрана: вкладки для репозитория github/docs. Вкладка \"Действия\" выделена оранжевым контуром.](/assets/images/help/repository/actions-tab-global-nav-update.png)\n\n3. Если в вашем репозитории уже используется рабочий процесс, нажмите кнопку **Создать рабочий процесс**.\n\n4. На странице \"Выбор рабочего процесса\" показан выбор рекомендуемых шаблонов рабочих процессов. Найдите dotnet.\n\n5. В рабочем процессе .NET нажмите кнопку **\"Настроить**\".\n\n6. Измените рабочий процесс по мере необходимости. Например, измените версию .NET.\n\n7. Щелкните **Зафиксировать изменения**.\n\n   Файл `dotnet.yml` рабочего процесса добавляется в `.github/workflows` каталог вашего репозитория.\n\n## Указание версии .NET\n\nЧтобы использовать предустановленную версию пакета SDK .NET Core в GitHubразмещенном `setup-dotnet` средстве выполнения, используйте действие. Это действие находит определенную версию .NET из кэша инструментов в средстве выполнения и добавляет необходимые двоичные файлы в переменную `PATH`. Эти изменения будут сохранены для остальной части задания.\n\nЭто `setup-dotnet` рекомендуемый способ использования .NET сGitHub Actions, так как обеспечивает согласованное поведение между различными средствами выполнения и различными версиями .NET. При использовании локального средства выполнения необходимо установить .NET и добавить его в `PATH`. Дополнительные сведения см. в описании действия [`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk).\n\n### Использование нескольких версий .NET\n\n```yaml\nname: dotnet package\n\non: [push]\n\njobs:\n  build:\n\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        dotnet-version: [ '3.1.x', '6.0.x' ]\n\n    steps:\n      - uses: actions/checkout@v6\n      - name: Setup dotnet ${{ matrix.dotnet-version }}\n        uses: actions/setup-dotnet@v4\n        with:\n          dotnet-version: ${{ matrix.dotnet-version }}\n      # You can test your matrix by printing the current dotnet version\n      - name: Display dotnet version\n        run: dotnet --version\n```\n\n### Использование определенной версии .NET\n\nВы можете настроить задание для использования конкретной версии .NET, например `6.0.22`. Кроме того, можно использовать синтаксис семантической версии, чтобы получить последний дополнительный выпуск. В этом примере используется последний дополнительный выпуск .NET 6.\n\n```yaml\n    - name: Setup .NET 6.x\n      uses: actions/setup-dotnet@v4\n      with:\n        # Semantic version range syntax or exact version of a dotnet version\n        dotnet-version: '6.x'\n```\n\n## Установка зависимостей\n\nGitHub-размещенные средства выполнения установлены диспетчером пакетов NuGet. Вы можете использовать CLI .NET для установки зависимостей из реестра пакетов NuGet перед сборкой и тестированием кода. Например, приведенный ниже код YAML устанавливает пакет `Newtonsoft`.\n\n```yaml\nsteps:\n- uses: actions/checkout@v6\n- name: Setup dotnet\n  uses: actions/setup-dotnet@v4\n  with:\n    dotnet-version: '6.0.x'\n- name: Install dependencies\n  run: dotnet add package Newtonsoft.Json --version 12.0.1\n```\n\n### Кэширование зависимостей\n\nМожно кэшировать зависимости NuGet для будущих рабочих процессов с помощью необязательных `cache` входных данных. Например, YAML ниже кэширует папку `global-packages` NuGet`Newtonsoft`, а затем устанавливает пакет. Второй необязательный вход`cache-dependency-path`, можно использовать для указания пути к файлу зависимостей: `packages.lock.json`\n\nДополнительные сведения см. в разделе [Справочник по кэшированию зависимостей](/ru/actions/reference/workflows-and-actions/dependency-caching).\n\n```yaml\nsteps:\n- uses: actions/checkout@v6\n- name: Setup dotnet\n  uses: actions/setup-dotnet@v4\n  with:\n    dotnet-version: '6.x'\n    cache: true\n- name: Install dependencies\n  run: dotnet add package Newtonsoft.Json --version 12.0.1\n```\n\n> \\[!NOTE]\n> В зависимости от количества зависимостей может быть быстрее использовать кэш зависимостей. Проекты с большим количеством крупных зависимостей должны выигрывать в производительности из-за сокращения времени скачивания. Проекты с меньшим количеством зависимостей могут не получать значительного выигрыша в производительности, либо производительность может даже немного снижаться из-за того, как NuGet устанавливает кэшированные зависимости. Производительность варьируется от проекта к проекту.\n\n## Создание и тестирование кода\n\nВы можете использовать те же команды, которые используются для создания и тестирования кода в локальной среде. В этом примере показано, как использовать `dotnet build` и `dotnet test` в задании:\n\n```yaml\nsteps:\n- uses: actions/checkout@v6\n- name: Setup dotnet\n  uses: actions/setup-dotnet@v4\n  with:\n    dotnet-version: '6.0.x'\n- name: Install dependencies\n  run: dotnet restore\n- name: Build\n  run: dotnet build --no-restore\n- name: Test with the dotnet CLI\n  run: dotnet test --no-build\n```\n\n## Упаковка данных рабочего процесса в виде артефактов\n\nПосле завершения рабочего процесса можно отправить полученные артефакты для анализа. Например, может потребоваться сохранить файлы журналов, основные дампы, результаты теста или снимки экрана. В следующем примере показано, как использовать действие `upload-artifact` для отправки результатов теста.\n\nДополнительные сведения см. в разделе [Хранение и предоставление общего доступа к данным с артефактами рабочего процесса](/ru/actions/tutorials/store-and-share-data).\n\n```yaml\nname: dotnet package\n\non: [push]\n\njobs:\n  build:\n\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        dotnet-version: [ '3.1.x', '6.0.x' ]\n\n      steps:\n        - uses: actions/checkout@v6\n        - name: Setup dotnet\n          uses: actions/setup-dotnet@v4\n          with:\n            dotnet-version: ${{ matrix.dotnet-version }}\n        - name: Install dependencies\n          run: dotnet restore\n        - name: Test with dotnet\n          run: dotnet test --no-restore --logger trx --results-directory \"TestResults-${{ matrix.dotnet-version }}\"\n        - name: Upload dotnet test results\n          uses: actions/upload-artifact@v4\n          with:\n            name: dotnet-results-${{ matrix.dotnet-version }}\n            path: TestResults-${{ matrix.dotnet-version }}\n          # Use always() to always run this step to publish test results when there are test failures\n          if: ${{ always() }}\n```\n\n## Публикация в реестрах пакетов\n\nВы можете настроить рабочий процесс для публикации пакета .NET в реестре пакетов после прохождения тестов CI. Вы можете использовать секреты репозитория для хранения любых токенов или учетных данных, необходимых для публикации двоичного файла. В следующем примере создается и публикуется пакет для GitHub Packages использования `dotnet core cli`.\n\n```yaml\nname: Upload dotnet package\n\non:\n  release:\n    types: [created]\n\njobs:\n  deploy:\n    runs-on: ubuntu-latest\n    permissions:\n      packages: write\n      contents: read\n    steps:\n      - uses: actions/checkout@v6\n      - uses: actions/setup-dotnet@v4\n        with:\n          dotnet-version: '6.0.x' # SDK Version to use.\n          source-url: https://nuget.pkg.github.com/<owner>/index.json\n        env:\n          NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}\n      - run: dotnet build --configuration Release <my project>\n      - name: Create the package\n        run: dotnet pack --configuration Release <my project>\n      - name: Publish the package to GPR\n        run: dotnet nuget push <my project>/bin/Release/*.nupkg\n```"}