dotnet-restore

Restore dependencies for a .NET project or solution in the current directory

$ dotnet restore

$ dotnet restore [path/to/project_or_solution]

$ dotnet restore --no-cache

$ dotnet restore --force

$ dotnet restore --ignore-failed-sources

$ dotnet restore [[-v|--verbosity]] [quiet|minimal|normal|detailed|diagnostic]

dotnet restore [PROJECT_OR_SOLUTION] [options]

[PROJECT_OR_SOLUTION]
    An optional path to the project or solution file to restore. If not specified, the current directory is searched for a project or solution file.

-s | --source
    Specifies a NuGet package source to use during the restore operation. Can be specified multiple times.

--packages
    Specifies the directory where restored packages are placed. If not specified, the default global packages folder is used.

--configfile
    The NuGet configuration (nuget.config) file to use. If specified, only the settings from this file will be used.

-r | --runtime
    Specifies a runtime for which to restore packages. This is used when restoring platform-specific packages.

--disable-parallel
    Disables restoring packages in parallel. Useful for troubleshooting.

--no-dependencies
    When restoring a project with project-to-project (P2P) references, restores only the root project, not its P2P references.

--interactive
    Allows the command to stop and wait for user input or authentication. Useful for protected feeds.

--force-evaluate
    Forces restore to re-evaluate all dependencies even if a lock file exists. This can ensure the latest compatible versions are resolved.

--no-cache
    Prevents restore from using HTTP cached packages. Forces a fresh download.

--ignore-failed-sources
    Only warn about failed sources if there are packages that satisfy the version requirement from another source.

--verbosity
    Sets the verbosity level of the command. Allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic].

-h | --help
    Prints out a short help for the command.

The dotnet restore command downloads all the necessary dependencies and tools for a .NET project or solution file. It's crucial for building, running, and publishing .NET applications, as it ensures all required NuGet packages are available locally.
When executed, dotnet restore analyzes the project's dependencies, typically defined in the .csproj, .fsproj, or .vbproj file, and then fetches them from configured NuGet package sources (like nuget.org or private feeds). It populates the project.assets.json file, which contains information about the resolved packages, their versions, and their locations, effectively acting as a dependency graph. This command is often run implicitly by other commands like dotnet build, dotnet run, and dotnet publish, but can be executed explicitly to pre-fetch packages, especially in CI/CD environments or when troubleshooting dependency issues. It plays a vital role in enabling reproducible builds across different machines.

* Requires the .NET SDK to be installed on the Linux system.
* Internet connectivity is generally required to download packages from remote NuGet sources.
* The project.assets.json file, generated by restore, should not be manually edited and is typically excluded from source control.
* Large projects with many dependencies can take significant time and consume bandwidth.
* Package sources must be configured correctly, either globally via nuget.config or per-project.

While dotnet restore is often implicitly called by commands like dotnet build or dotnet run, explicitly running it is beneficial in several scenarios:
* CI/CD Pipelines: To ensure all dependencies are downloaded before a build step, allowing the build step to run offline or faster.
* Troubleshooting: To diagnose dependency resolution issues by observing its output directly.
* Pre-fetching: To download all packages upfront, especially before working offline or when network conditions might be unstable.
* Lock File Generation: To update or generate the project.assets.json file explicitly.

The .NET SDK 6.0 and later versions enable implicit restore for most commands that require it. This means you typically don't need to run dotnet restore explicitly before dotnet build, dotnet run, dotnet test, or dotnet publish. However, it's good practice to understand its function and when explicit execution might be necessary.

The dotnet restore command became a cornerstone of the .NET Core (now just .NET) ecosystem, evolving from the previous NuGet restore command used in earlier .NET Framework projects. With the introduction of .NET Core, the dotnet CLI (Command-Line Interface) became the primary interface for managing .NET projects across platforms, including Linux. dotnet restore was integrated into the CLI to streamline the dependency management workflow, making cross-platform development more consistent and efficient. Its design focused on performance improvements and better integration with build systems compared to its predecessors. It's a fundamental step in the modern .NET development lifecycle.

dotnet build(1), dotnet run(1), dotnet publish(1), dotnet clean(1), dotnet add package(1)