VS Settings should include RestoreSources, RestoreAdditionalProjectSources & RestoreAdditionalProjectFallbackFolders

[nkolev92]

https://github.com/NuGet/Home/wiki/%5BSpec%5D-NuGet-settings-in-MSBuild

These properties take precedence over what the user sees in the UI.
We need to think about this and change the UI accordingly.

//cc
@emgarten

[natemcmaster]

I see this is in the 4.4 milestone. I'm using NuGet 4.5 in VS 15.5 preview, but this still doesn't appear to work. Can anyone provide a status update on this one?

cc @davidfowl

[nkolev92]

It's not done. I will change the milestone to something appropriate.
We haven't done the design work on this yet. Currently it's an advanced scenario not used by many as we havent really advertised it.

We have a lot of debt in this area with hierarchical settings.
So in my opinion we would need that resolved before continuing with this.
Bottom line, the user needs to know where these settings are coming from. And JUST adding these values to the Settings makes the experience worse imo.

[nkolev92]

Setting the same priority as the prerequisite issue #1820

[belkiss]

Hello!

Would be great to see this tackled, I have opened a (now closed...) bug report in VS about this: https://developercommunity.visualstudio.com/t/restoresources-or-restoreadditionalprojectsources/1404191.

Thanks!

[zivkan]

Adding a 👍 reaction to the first comment in the issue will help this issue bubble up all issues sorted by 👍. See also our submitting bugs and suggestions guide

[GSPP]

Configuring sources in the project file would allow the solution to become self-contained. Currently, every developer has to change global NuGet configuration to use an internal feed.

If you want to check in packages to source control, to make a project truly self-contained and not dependent on some external folder, you even have to configure one package source for each working copy that you check out. I find it a bit dubious that compiling a solution requires files that are not contained in source control. For that reason, I'd like to check in internal packages but the workflow for that is not very nice.

For that reason, making this feature full fidelity with UI support would make a great addition to the product.

[zivkan]

@GSPP You can check in a nuget.config file into your repo root, and use <clear/> in elements that support it. This makes the repo not depend on machine configuration. NuGet.Client repo, and basically every Microsoft repo, does this: https://github.com/NuGet/NuGet.Client/blob/dev/NuGet.Config

Reference docs: https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file

A quick way to bootstrap a sample nuget.config is with the .NET CLI: dotnet new nugetconfig.

[GSPP]

@zivkan Thanks! Can this be used to have the package source inside of the solution folder (like a /PackageSource folder)? And does this work with the Visual Studio NuGet UI?