dotnet-restore(1)

👑 dotnet-restore(1) — .NET Documentation ✨

okay bestie, welcome to the manual page for dotnet restore 💖 the manual name is literally right there in the title, dotnet-restore(1), so now you know what you're reading.

This article applies to: ✔️ .NET 6 SDK and later versions. yes, only the cool newer SDKs. periodt.

---

🎀 NAME 🎀

dotnet-restore — Restores the dependencies and tools of a project.

lowkey the whole personality in one line, and honestly? iconic.

---

🌈 SYNOPSIS 🌈

dotnet restore [<PROJECT>|<SOLUTION>|<FILE>]
  [-a|--arch <ARCHITECTURE>] [--configfile <FILE>] [--disable-build-servers]
  [--disable-parallel] [-f|--force] [--force-evaluate]
  [--ignore-failed-sources] [--interactive] [--lock-file-path <LOCK_FILE_PATH>]
  [--locked-mode] [--no-dependencies] [--no-http-cache]
  [--os <OS>] [--packages <PACKAGES_DIRECTORY>]
  [-r|--runtime <RUNTIME_IDENTIFIER>] [-s|--source <SOURCE>]
  [--tl:[auto|on|off]] [--ucr|--use-current-runtime] [--use-lock-file]
  [-v|--verbosity <LEVEL>]

dotnet restore -h|--help

---

🦋 DESCRIPTION 🦋

so here's the tea ☕ a .NET project usually references external libraries that live in NuGet (https://www.nuget.org) packages, and those packages are what give your project the extra functionality it needs. those external dependencies get referenced in the project file (.csproj or .vbproj). when you run the dotnet restore command, the .NET CLI pulls up NuGet to go looking for those dependencies and downloads them if it has to. it also makes sure every dependency the project needs actually plays nice with all the others, and that nothing is beefing with anything else (no conflicts, we don't do that here 💅).

once the command finishes, all the dependencies your project needs are chillin' in a local cache, ready for the .NET CLI to build and run the app. slay.

most of the time you do not need to explicitly type dotnet restore, because if a NuGet restore is necessary, these commands just run it implicitly behind your back:

• dotnet new
• dotnet build
• dotnet build-server
• dotnet run
• dotnet test
• dotnet publish
• dotnet pack

but sometimes running that implicit NuGet restore with those commands is just… inconvenient, ngl. for example, some automated systems — build systems and stuff — need to call dotnet restore explicitly so they can control when the restore happens, which means they get to control network usage. makes sense. and if you wanna stop the implicit NuGet restore from happening, you can use the --no-restore flag with any of those commands. bye 👋

Signed package verification during restore operations requires a certificate root store that is valid for both code signing and timestamping. For more information, see NuGet signed package verification.

---

💜 Specify feeds 💜

to restore the dependencies, NuGet needs the feeds where the packages are actually located. feeds are usually handed over via the nuget.config configuration file, and a default configuration file comes pre-installed when you set up the .NET SDK. wanna specify extra feeds? do one of these:

• create your own nuget.config file in the project directory. for more info, see Common NuGet configurations and nuget.config differences later in this article.
• use dotnet nuget commands like dotnet nuget add source.

and psst — you can override the nuget.config feeds with the -s option. 👑

for info on how to use authenticated feeds, see Consuming packages from authenticated feeds.

---

🍓 Global packages folder 🍓

for dependencies, you can pick where the restored packages get placed during the restore operation using the --packages argument. if you don't specify it, the default NuGet package cache is used, and that lives in the .nuget/packages directory in the user's home directory on all operating systems. for example, /home/user1 on Linux or C: on Windows.

---

🧚 Project-specific tooling 🧚

for project-specific tooling, dotnet restore first restores the package that the tool is packed in, and then goes on to restore the tool's dependencies as specified in its project file. one step at a time, bestie.

---

🌸 nuget.config differences 🌸

the behavior of the dotnet restore command is affected by the settings in the nuget.config file, if it's there. for example, setting the globalPackagesFolder in nuget.config puts the restored NuGet packages in the folder you specified. that's an alternative to passing the --packages option on the dotnet restore command. for more info, see the nuget.config reference.

and listen — there are three specific settings that dotnet restore straight up ignores:

• bindingRedirects

Binding redirects don't work with <PackageReference> elements, and .NET only supports <PackageReference> elements for NuGet packages.

• solution

This setting is Visual Studio specific and doesn't apply to .NET. .NET doesn't use a packages.config file and instead uses <PackageReference> elements for NuGet packages.

• trustedSigners

Support for cross-platform package signature verification was added in the .NET 5.0.100 SDK.

---

⭐ Workload manifest downloads ⭐

when you run this command, it kicks off an asynchronous background download of advertising manifests for workloads. and if that download is still running when this command finishes, the download gets stopped. for more info, see Advertising manifests.

---

🫶 ARGUMENTS 🫶

• PROJECT | SOLUTION | FILE — the project or solution or C# (file-based app) file to operate on. if you don't specify a file, MSBuild goes searching the current directory for a project or solution.
  • PROJECT is the path and filename of a C#, F#, or Visual Basic project file, or the path to a directory that contains a C#, F#, or Visual Basic project file.
  • SOLUTION is the path and filename of a solution file (.sln or .slnx extension), or the path to a directory that contains a solution file.
  • FILE is an argument added in .NET 10. the path and filename of a file-based app. file-based apps are contained within a single file that is built and run without a corresponding project (.csproj) file. for more info, see Build file-based C# apps.

---

💅 OPTIONS 💅

• -a | --arch <ARCHITECTURE> — specifies the target architecture. this is a shorthand syntax for setting the Runtime Identifier (RID), where the value you provide gets combined with the default RID. for example, on a win-x64 machine, specifying --arch x86 sets the RID to win-x86. if you use this option, do not also use the -r|--runtime option (pick a lane bestie 🙈). available since .NET 6 Preview 7.
• --configfile <FILE> — the NuGet configuration file (nuget.config) to use. if you specify it, only the settings from this file get used. if you don't, the hierarchy of configuration files from the current directory gets used. for more info, see Common NuGet Configurations.
• --disable-build-servers — forces the command to ignore any persistent build servers. this option is the consistent way to disable all use of build caching, which forces a build from scratch. a build that doesn't rely on caches is super useful when the caches might be corrupted or just plain wrong for some reason. available since .NET 7 SDK.
• --disable-parallel — disables restoring multiple projects in parallel. one at a time, we're being chill about it.
• --force — forces all dependencies to be resolved even if the last restore was successful. specifying this flag is the same as deleting the project.assets.json file. same energy, different button.
• --force-evaluate — forces restore to reevaluate all dependencies even if a lock file already exists.
• --ignore-failed-sources — only warn about failed sources if there are packages meeting the version requirement.
• --interactive — allows the command to stop and wait for user input or action. for example, to complete authentication. it'll just sit there waiting for you, patiently 🥺
• --lock-file-path <LOCK_FILE_PATH> — output location where the project lock file is written. by default, this is PROJECT_ROOT.lock.json.
• --locked-mode — don't allow updating the project lock file. it's locked, it said what it said.
• --no-dependencies — when restoring a project with project-to-project (P2P) references, restores the root project and not the references.
• --no-http-cache — disable HTTP caching for packages.
• --os — specifies the target operating system (OS). this is a shorthand syntax for setting the Runtime Identifier (RID), where the value you provide gets combined with the default RID. for example, on a win-x64 machine, specifying --os linux sets the RID to linux-x64.

Introduced in .NET SDK 10.0.100

• --packages <PACKAGES_DIRECTORY> — specifies the directory for restored packages.
• -r | --runtime <RUNTIME_IDENTIFIER> — specifies a runtime for the package restore. this is used to restore packages for runtimes that aren't explicitly listed in the <RuntimeIdentifiers> tag in the .csproj file. for a list of Runtime Identifiers (RIDs), see the RID catalog.
• -s | --source <SOURCE> — specifies the URI of the NuGet package source to use during the restore operation. this setting overrides all of the sources specified in the nuget.config files. you can provide multiple sources by specifying this option multiple times. stack 'em up 💅
• --ucr | --use-current-runtime — use the current runtime as the target runtime.
• --use-lock-file — enables the project lock file to be generated and used with restore.
• --tl:[auto|on|off] — specifies whether Terminal Logger should be used for the build output. the default is auto, which first verifies the environment before enabling terminal logging. that environment check verifies the terminal is capable of using modern output features and isn't using a redirected standard output before enabling the new logger. on skips the environment check and enables terminal logging. off skips the environment check and uses the default console logger.

Terminal Logger shows you the restore phase followed by the build phase. during each phase, the currently building projects appear at the bottom of the terminal. each project that's building outputs both the MSBuild target currently being built and the amount of time spent on that target. you can search this info to learn more about the build. when a project is finished building, a single "build completed" section gets written that captures:

• the name of the built project.
• the target framework (if multi-targeted).
• the status of that build.
• the primary output of that build (which is hyperlinked).
• any diagnostics generated for that project.

this option is available starting in .NET 8.

• -v | --verbosity <LEVEL> — sets the verbosity level of the command. allowed values are q[uiet], m[inimal], n[ormal], d[etailed], and diag[nostic]. the default is minimal. for more info, see <xref:Microsoft.Build.Framework.LoggerVerbosity>.
• -? | -h | --help — prints out a description of how to use the command. the classic "help me help you" move 🫶

---

okay bestie that's the first half of the vibe check — there's more where that came from, so don't go anywhere 🌈✨

✨ EXAMPLES ✨

okay bestie, here's the tea — real commands you can literally copy-paste 💅

• Restore dependencies and tools for the project in the current directory:

dotnet restore

• Restore dependencies and tools for the app1 project found in the given path:

dotnet restore ./projects/app1/app1.csproj

• Restore the dependencies and tools for the project in the current directory using the file path provided as the source:

dotnet restore -s c:\packages\mypackages

• Restore the dependencies and tools for the project in the current directory using the two file paths provided as sources:

dotnet restore -s c:\packages\mypackages -s c:\packages\myotherpackages

• Restore dependencies and tools for the project in the current directory showing detailed output:

dotnet restore --verbosity detailed

---

🔒 Audit for security vulnerabilities 🔒

Starting in .NET 8, dotnet restore comes with NuGet security auditing built in. Not me running a whole security audit without even being asked 😭 This auditing produces a report of security vulnerabilities with the affected package name, the severity of the vulnerability, and a link to the advisory for more details. Receipts included, periodt.

Wanna opt out of the security auditing? Totally valid. Set the <NuGetAudit> MSBuild property to false in your project file. bye felicia 👋

To retrieve the known vulnerability dataset, make sure you have the NuGet.org central registry defined as one of your package sources:

<packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>

You can also configure the level at which auditing will fail by setting the <NuGetAuditLevel> MSBuild property. Possible values are low, moderate, high, and critical. So for example, if you only want to see moderate, high, and critical advisories, you can set the property to moderate. vibe check your threat tolerance fr fr ⚠️

In .NET 8 and .NET 9, only direct package references are audited by default. Starting in .NET 10, NuGet audits both direct and transitive package references by default. glow up fr 💖 You can change the mode by setting the <NuGetAuditMode> MSBuild property to direct or all.

For more information, see Auditing package dependencies for security vulnerabilities. go read it, iykyk 📚✨

---

and that's the whole page bestie!! you made it to the end, so proud of you 🥹💅

this slay of a manual page is from the dotnet-restore(1) source, dated 2025-10-30 — shoutout to the date stamp for keeping it iconic 👑

okay ily, now go restore something and hydrate 🫶🌸🦋