Home: VS solution restore does not read project level nuget config file

[mishra14]

Details about Problem

NuGet product used: VS 15.7 P3

NuGet version (x.x.x.xxx): 4.7.0.5039

Detailed repro steps so we can see the same problem

1. Take this projectA.zip

2. Open solution in VS and try solution restore.

Expected

The project should restore correctly.

Actual

The project restore fails because reference toNuGet.Build.Tasks cannot be found as the exact version's source is in the project specific nuget config file.

Its important to note that running dotnet restore projectA.Sln works fine.

Related

Duplicate report
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/597899

[mishra14]

cc: @jainaashish @nkolev92 @dtivel

[nkolev92]

This was done by design in VS, and we should probably consider changing the respective docs to represent the current behavior.
At least until we decide to do it otherwise.

https://developercommunity.visualstudio.com/content/problem/217493/visual-studio-nuget-package-manager-ignores-nugetc-1.html
https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior#config-file-locations-and-uses

[anangaur]

Why is this by design?
How does one override the settings for a given project?

[nkolev92]

@anangaur
That's how it's always been in VS.
VS has had 1 set of settings for a solution for forever.

The per project feature is the one that was added later. That's the one that changed the experience.

We'd need to talk about hierarchical settings in VS so we can actually display what settings you have configured in a meaningful way.

Now that we are integrated in MsBuild, and you can configure almost everything project related through it, we need to think hard whether we want to add more dependencies for a project build in an auxiliary file.

[jainaashish]

before everything else, who's asking for this?

[ncarandini]

I was asking for it for two good reasons:

1. Documentation says project level NuGet.Config is allowed and used by VS (so this is not a feature, is a bug, of VS or docs, as you like);
2. This is really bad because if you use Visual Studio Code you may not have the solution folder at all!

BTW, this caused an "unable to build" state with the Blazor project (at his early stage, when bits were only available on nightly builds and the NuGet source was specified in a NuGet config file at project level). But the VS Code and the CLI build worked as expected. So if this is a feature of VS IDE, it's wrong and should be changed.

[nkolev92]

@ncarandini

1. Documentation says project level NuGet.Config is allowed and used by VS (so this is not a feature, is a bug, of VS or docs, as you like);

We'll discuss and likely amend the documentation at least in the short term.
This would be quite a significant undertaking and it would take some time to get it out.

1. This is really bad because if you use Visual Studio Code you may not have the solution folder at all!

It doesn't have to be next to a solution folder. It just needs to be in the recursive path of all projects.
So you have

NuGet.Config
build.ps1
src
    projectA
       projectA.csproj
    projectB
        projectB.csproj

This should work in both VS Code and VS.

Just to get more information about your setup.

Why are you using project level config files?
What are you changing in those config files? Is it the sources only?
What are the restore project style of the projects in your collection/solution? PackageReference vs packages.config

[ncarandini]

@nkolev92
thanks for your kind and detailed response.

I run into this problem using early stage of Blazor bits, where the NuGet.Config file was inside the project. I wrote a post to help many others to solve the issue, frequently asked in the Blazor Gitter group.

Actually they have updated their README to include instructions on how to write a proper NuGet.Config file and were to put it, so the issue is no more... an issue! :-)

[nzgeek]

I've got a different situation which would benefit greatly from per-project NuGet.config files.

My employer has a strict policy around third party library approvals. We've got 2 separate MyGet.org feeds that can be used: one for packages that have been strictly reviewed for production use, and one for packages that have been loosely reviewed for internal use only.

We've just encountered a situation where a team wants to reference the internal-only feed for an integration test project in a solution. This is logically ok, because the integration tests aren't released with the production code. However, this does make managing the project hard.

Our current options are:

1. Have a single .sln file for all of the projects, with a single NuGet.config file. This is the easiest to manage, but potentially allows the production-bound projects to load packages from the internal-only feed.
2. Have separate .sln files in different directories, each with their own NuGet.config file. One .sln contains the production projects. The other .sln contains any internal-only projects, plus whatever production projects are needed as dependencies.

Having per-project NuGet.config files would allow the just the internal-only projects to have access to the internal-only feed.

[nkolev92]

@nzgeek

What are your project types? Packages.config vs PackageReference?

There are ways you can achieve this without hurting your workflow.
I'd assume on CIs you can just use a commandline version of restore, which works with project level configs.

Regarding the dev scenario.
NuGet stores packages in the global packages folder per machine per user.

If you're using packages.config, doing a commandline restore would be your best option.
Because of the aforementioned global packages folder, you'd only need to that once on that particular machines. The next time you do a "git clean", NuGet will pick up the packages from the global packages folder.

In the PackageReference scenario, you can set the sources via a property in the csproj, RestoreSources, but take into consideration the following issue.
Repeating myself again, but once you've restored on that machine, unless you have floating versions/badly writtn nuspec files, everything should just work after restoring once from the commandline.

Happy to provide more ideas if you have some other scenarios.

[nzgeek]

@nkolev92 It's an old code base that's targeting .NET 4.6.2, and is only just moving onto VS2017 build servers. We're stuck with packages.config files for the time being.

As you say, we do have the option of using a command line restore as part of the build script. It could look for any directories that contain a NuGet.config file, then any projects under those directories, and do a nuget restore into the solution's packages directory.

This gets around the build issues, but doesn't work nicely for maintaining the project inside VS. There's no way to grab new or updated packages from the internal-only feed, because VS doesn't know that the feed exists. The only options are to use the package manager console, or to have a separate solution and NuGet.config just for maintaining the packages.

[JohanPetersson]

I would like to add another scenario. I have a template (dotnet new) with a 4.x project and depending on the solution structure and where one uses the template in the structure the Reference/HintPath in the project file may point to the incorrect directory since the packages are always restored relative to the solution. So I always want to specify a repositoryPath directory relative to the project, not the solution, only then can I guarantee that HintPaths are correct.

Documentation still mentions 'project-specific nuget.config' here https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file.