{"meta":{"title":".NETでのビルドとテスト","intro":".NET プロジェクトのビルドとテストのための継続的インテグレーション (CI) ワークフローを作成する方法について説明します。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/actions","title":"GitHub Actions"},{"href":"/ja/actions/tutorials","title":"チュートリアル"},{"href":"/ja/actions/tutorials/build-and-test-code","title":"コードのビルドとテスト"},{"href":"/ja/actions/tutorials/build-and-test-code/net","title":".NET"}],"documentType":"article"},"body":"# .NETでのビルドとテスト\n\n.NET プロジェクトのビルドとテストのための継続的インテグレーション (CI) ワークフローを作成する方法について説明します。\n\n## はじめに\n\nこのガイドは、.NETパッケージのビルド、テスト、公開の方法を紹介します。\n\nGitHub ホステッド ランナーにはプリインストールされたソフトウェアのあるツール キャッシュがあり、.NET Core SDK が含まれています。 最新のソフトウェアの完全な一覧と、.NET Core SDK のプレインストールされたバージョンについては、[GitHub ホステッド ランナーにインストールされているソフトウェア](/ja/actions/using-github-hosted-runners/about-github-hosted-runners)に関するページを参照してください。\n\n## 前提条件\n\nYAMLの構文と、GitHub ActionsでのYAMLの使われ方に馴染んでいる必要があります。 詳しくは、「[GitHub Actions　のワークフロー構文](/ja/actions/using-workflows/workflow-syntax-for-github-actions)」をご覧ください。\n\n.NET Core SDKの基本的な理解をしておくことをおすすめします。 詳しくは、「[.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   ```\n\n`dotnet.yml` ワークフロー ファイルがリポジトリの `.github/workflows` ディレクトリに追加されます。\n\n## .NETのバージョンの指定\n\nGitHub ホステッド ランナーにプレインストールされたバージョンの .NET Core SDK を使うには、`setup-dotnet` アクションを使います。 このアクションは、各ランナーのツール キャッシュから特定のバージョンの .NET を見つけて、必要なバイナリを `PATH` に追加します。 これらの変更は、ジョブの残り時間にわたって持続します。\n\n```\n          `setup-dotnet` アクションを使用すると、異なるランナーおよび .NET の異なるバージョンの間で一貫した動作が保証されるため、GitHub Actions で NET を使用する場合の推奨される方法です。 セルフホステッド ランナーを使用している場合は、.NET をインストールし、それを `PATH` に追加する必要があります。 詳細については、[`setup-dotnet`](https://github.com/marketplace/actions/setup-net-core-sdk) アクションを参照してください。\n```\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```\n          `6.0.22` のような特定のバージョンの .NET を使うようにジョブを構成できます。 あるいは、最新のマイナーリリースを取得するためにセマンティックバージョン構文を使うこともできます。 この例では、.NET 6 の最新のマイナー リリースを使用しています。\n```\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パッケージマネージャーがインストールされています。 コードをビルドしてテストする前に、dotnetCLIを使って依存関係を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オプション `cache` の入力を使用して、将来のワークフローの NuGet 依存関係をキャッシュできます。 たとえば、次の YAML は NuGet `global-packages` フォルダーをキャッシュし、`Newtonsoft` パッケージをインストールします。 2 番目のオプション入力 `cache-dependency-path` は、依存ファイル `packages.lock.json` へのパスを指定するために使用できます。\n\n詳しくは、「[依存関係キャッシュのリファレンス](/ja/actions/using-workflows/caching-dependencies-to-speed-up-workflows)」をご覧ください。\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詳しくは、「[ワークフロー成果物を使ったデータの格納と共有](/ja/actions/using-workflows/storing-workflow-data-as-artifacts)」をご覧ください。\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\nCI テストに合格したら .NET パッケージをパッケージ レジストリに公開するように、ワークフローを構成できます。 バイナリを公開するのに必要なトークンや認証情報を保存するために、リポジトリシークレットを使うことができます。 次の例では、`dotnet core cli` を使ってパッケージを作成し、GitHub Packages に公開します。\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```"}