actions/setup-dotnet: .NET core sdk
A GitHub Action to set up a .NET CLI environment with specific SDK versions, caching, and package source authentication.
What is actions/setup-dotnet: .NET core sdk?
setup-dotnet is an official GitHub Action that installs and configures the .NET SDK for use in CI/CD workflows. It solves the problem of inconsistent .NET environments across GitHub-hosted and self-hosted runners by allowing precise version selection, architecture targeting, and dependency caching. The action ensures builds are reproducible and fast by managing SDK installations and NuGet package restoration.
Developers and teams building .NET applications who use GitHub Actions for continuous integration and deployment. It is essential for projects requiring specific .NET versions, testing across multiple SDKs, or integrating with private package feeds.
Developers choose setup-dotnet because it is the officially maintained, feature-complete solution for .NET in GitHub Actions. It offers reliable version management, built-in caching for faster builds, and seamless authentication for private package sources, reducing pipeline configuration complexity.
Overview
Set up your GitHub Actions workflow with a specific version of the .NET core sdk
Use Cases
Best For
- Installing specific .NET SDK versions (e.g., 8.0.x, 9.0.308) on GitHub Actions runners
- Caching NuGet packages to speed up dotnet restore in CI/CD pipelines
- Configuring authentication for private package feeds like GitHub Packages or Azure Artifacts
- Running matrix tests across multiple .NET versions in a single workflow
- Setting up .NET workloads (e.g., WASM, MAUI) for cross-platform development
- Ensuring consistent .NET environments across self-hosted and GitHub-hosted runners
Not Ideal For
- Projects using CI/CD platforms other than GitHub Actions, such as GitLab CI or Azure DevOps pipelines
- Local development environments where manual SDK installation via dotnet-install scripts or system package managers is preferred
- Simple .NET applications that rely solely on preinstalled SDK versions on GitHub runners and don't require version pinning or caching
- Teams prioritizing containerized builds with Docker images for complete environment isolation and portability across CI systems
Pros & Cons
Pros
Supports exact version installation (e.g., 9.0.308) and flexible syntax for latest patches or channels, ensuring consistent builds across runners. Evidence: The README details syntax like A.B.C for exact versions and A.B.x for latest patches.
Automatically caches and restores packages using lock files (packages.lock.json), speeding up workflow execution. Evidence: The action uses toolkit/cache under the hood and requires lock files for caching, with examples for monorepos.
Configures authentication for private package sources like GitHub Packages and Azure Artifacts with environment variables, simplifying secure deployments. Evidence: Examples show setting source-url and NUGET_AUTH_TOKEN for various feeds.
Enables testing across multiple .NET versions via GitHub Actions matrix strategy and installs additional workloads (e.g., MAUI, WASM). Evidence: The README includes matrix testing examples and a workloads input for SDK extensions.
Cons
Caching only works with NuGet lock files and requires .NET SDK 2.1.500+, potentially causing NU1403 errors without extra MSBuild properties like DisableImplicitNuGetFallbackFolder. Evidence: Warnings in the README note lock file availability and error mitigation steps.
Version updates like V5 introduce breaking changes (e.g., Node 24 upgrade) that require runner updates, and default behavior depends on preinstalled SDKs which can change unexpectedly. Evidence: The README highlights breaking changes and warnings about default SDK selection.
Setting up caching in monorepos or ensuring precise version control in matrix tests requires manual steps like cache-dependency-path or temporary global.json files. Evidence: Examples show extra configuration for monorepos and matrix testing with global.json creation.
Exclusively designed for GitHub Actions, making migration to other CI/CD systems difficult and limiting use outside the GitHub ecosystem. Implicit from being an official GitHub Action with no cross-platform support.
Frequently Asked Questions
Related Projects
actions/setup-node: Node.jsSet up your GitHub Actions workflow with a specific version of node.js
actions/setup-python: PythonSet up your GitHub Actions workflow with a specific version of Python
actions/setup-java: JavaSet up your GitHub Actions workflow with a specific version of Java
actions/setup-go: GoSet up your GitHub Actions workflow with a specific version of Go
Found a gem we're missing?
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.