The dotnet restore command uses NuGet to restore dependencies as well as project-specific tools that are specified in the project file. By default, the restoration of dependencies and tools are performed in parallel.
Starting with .NET Core 2.0, you don't have to run dotnet restore because it's run implicitly by all commands, such as dotnet build and dotnet run, that require a restore to occur. It's still a valid command in certain scenarios where doing an explicit restore makes sense, such as continuous integration builds in Visual Studio Team Services or in build systems that need to explicitly control the time at which the restore occurs.
In order to restore the dependencies, NuGet needs the feeds where the packages are located. Feeds are usually provided via the NuGet.config configuration file. A default configuration file is provided when the CLI tools are installed. You specify additional feeds by creating your own NuGet.config file in the project directory. You also specify additional feeds per invocation at a command prompt.
For dependencies, you specify where the restored packages are placed during the restore operation using the --packages argument. If not specified, the default NuGet package cache is used, which is found in the .nuget/packages directory in the user's home directory on all operating systems (for example, /home/user1 on Linux or C:\Users\user1 on Windows).
For project-specific tooling, dotnet restore first restores the package in which the tool is packed, and then proceeds to restore the tool's dependencies as specified in its project file.
The behavior of the dotnet restore command is affected by some of the settings in the Nuget.Config file, if present. For example, setting the globalPackagesFolder in NuGet.Config places the restored NuGet packages in the specified folder. This is an alternative to specifying the --packages option on the dotnet restore command. For more information, see the NuGet.Config reference.
For more details, visit the official website.
- ///