PM UI Package Source dropdown Default Selection should be Configurable again

[ImGonaRot]

At one point in time, the user could edit the nuget.config and add "aggregate source" in the "activePackageSource" so that VS would list local repositories along with the default nuget server repository. AKA "ALL" was the our new default.

Now it just defaults to "nuget" server and if we set it to default to our "local" repository, it hides the remote nuget repository.

We need to see both our local and the remote nuget repository at one time. AKA we want "ALL" as the default. This causes confusing and wastes time hitting the dropdown in VS each time we want to add / remove nugets.

[jainaashish]

If you select ALL in VS dropdown then it persist that selection as long as you're in that VS instance irrespective how many times you add/ remove nuget feeds. Now depending on how often you update your feeds, but realistically this should be good enough. Besides with PackageReference NuGet anyways uses all the active sources to install/ update or restore packages so this only become relevant for UI search.

So given all this, I'm not of the option to add this option back. But open for more reasoning. @anangaur @rrelyea to comment further.

[ImGonaRot]

I agree that if you select "ALL" in the VS dropdown that it will persist for that instance of VS but that is not the issue I am pointing out. I'm not sure why it was removed or even what harm it was causing since the developer had to manually edit the config file to force it to "ALL" in the first place.

I work for a company that uses both an "Internal" and an "External" NuGet feed. Our company is adding several class libraries a month for integration engines that are constantly being written for new and existing customers. When our developers open the NuGet manager we would like them to see "both" feeds at once and be able to search both feeds without clicking on the dropdown each time they want to search for both internal and external packages. We have hundreds of packages internal for our libraries and some are wrappers to common packages like EntityFramework.

At one point in time our developers were able to type EntityFramework in the package manager and they could see both our internal EntityFramework wrapper NuGet package and the external official EntityFramework NuGet package. Now since they only see either our internal or external, they are not noticing that there are 2 packages to choose from.

Yes we can default to our internal NuGet feed but then it is time consuming to look for external packages.

Again, my point is that I'm not sure why it was removed or even what harm it was causing since the developer had to manually edit the config file to force it to "ALL" in the first place.

[jainaashish]

Again, my point is that I'm not sure why it was removed or even what harm it was causing since the developer had to manually edit the config file to force it to "ALL" in the first place.

I'm not sure what was the reason to deprecate that. For that matter, I don't think anyone on the team currently aware about those reasons. But @anangaur @rrelyea are good contacts to take this forward.

[ImGonaRot]

Here is the link I am referring to about the deprecation of "activePackageSource" https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file#activepackagesource

(2.x only; deprecated in 3.x+)

[cremor]

Unless I'm remembering something wrong, activePackageSource still worked some time ago in Visual Studio, even though it was already officially deprecated. But I just tested it again with the latest version of Visual Studio 2017 and it now doesn't work any more. Therefore I agree that we need a new option to get the "all" setting chosen in the UI by default.

[karann-msft]

@ImGonaRot - implementation aside, are you looking for a way to persist "all" sources even after VS is restarted?

[ImGonaRot]

@karann-msft My company has its own internal NuGet server but we also still use the external "nuget.org". When our developers go to update an "internal" package, they have to remember to change the "nuget.org" to "All" in the dropdown else we don't know there are any "internal" updates because the "Updates" tab will have "0" until we point to our internal NuGet server. So yes, we do want it to always default to "All" in the dropdown anytime VS has been opened. Right now we do this be deploying a master "nuget.config" file on all the developer machines.

[karann-msft]

@ImGonaRot - what does this master "nuget.config" contain that helps you achieve this behavior today?

[ImGonaRot]

@karann-msft I guess there is some confusion / misunderstanding. "Currently" my nuget.config contains the following key <add key="All" value="(Aggregate source)" /> under "activePackageSource" BUT based on the link (2.x only; deprecated in 3.x+) it is either

1. Going to be deprecated in the near future (hope not)
2. Is already deprecated but not in the version I am using
3. Is a misprint from MS

I'm not sure which of the above is true but I really don't want to see this option deprecated and I know I am not the only company in the world with their own internal NuGet server. I'm not sure why it is being deprecated or what issue it is currently causing.

[cremor]

@ImGonaRot See my last comment here. The last time I tested it, that key didn't have an effect on VS2017 any more.

[ImGonaRot]

@cremor It works great on my VS 2017 and the other developers in my shop. Before we added this key it was not keeping the "All" each time we closed and re-opened VS 2017. Unless some new update has changed this? I will remove it from the nuget.config file and test again after a reboot.

[ImGonaRot]

@cremor I just checked and VS 2017 still is not defaulting to "All" yet the "activePackageSource" is still working in VS 2017. Here are the steps I followed:

1. Closed all VS 2017 instances
2. Delete the nuget.config stored in "Program Files (x86)\Nuget\Config\" that contained the "activePackageSource" key.
3. Opened VS 2017 and created a new Windows Form project in C# 4.5.2
4. Opened the NuGet manager for the project and "Nuget.org" was selected.
5. Selected "All" and closed VS.
6. Opened the project created in step above and "All" was selected, so I closed VS.
7. Opened VS and created a new Windows Form project in C# 4.5.2
8. Opened the NuGet manager for the project and "Nuget.org" was selected.
9. It is not keeping "All" between new projects.
10. Closed VS and added back the nuget.config file with the "activePackageSource" key of "All"
11. Now when I create new projects in VS it is always defaults to "All"

[cremor]

@ImGonaRot I tested it with version 15.9.7 back in February.

But I didn't test it with the global NuGet.config in the programs folder. I tested a NuGet.config that is placed in the repository (in the same folder as the solution file) so that it is automatically shared with colleagues.

[ImGonaRot]

@cremor We place it in a nuget.config file on the developer computers through group policies this way we don't have to "remember" to add it to each solution. This is handy since new developers might "forget" to add it. Anyway the point is that we use <add key="All" value="(Aggregate source)" /> and would really like for it to NOT be deprecated.

[OutgoingOpossum]

I would like to second on this issue.

Re-enabling this configuration option would allow companies running their internal package repositories to default to the "All" package source, allowing the following scenario:

Repositories in order of how a package should be resolved:

1. Internal package repository (sonatype Nexus, JFrog Artifactory, ...)
2. Official NuGet package repository

[rrelyea]

In NuGet 3.4, we added the all choice, but had some issues near ship so we didn't make it the default. We should consider changing this to default to "All" now. There are some pros and cons.

[zkat]

@anangaur @chgill-MSFT @donnie-msft y'all might want to look at this. I believe it's a fairly small change but requires some product decision making.

[donnie-msft]

My opinion... there's a reasonable need here to be able to control the default PM UI source. I believe it should certainly be configurable and not simply a "default for PMUI".

Since Restore always hits all sources, I assume that was some of the motivation for removing the aggregate source in NuGet.config. But again, this broke a PM UI functionality which shouldn't be related to that change..

We should either simply return this NuGet.config setting (or create a more specific one) or have the VS Setting be persistent and configurable.

[anangaur]

I do not think a nuget.config setting is required here as it only affects VS. IMO, VS should remember the customers' selection across projects and sessions. So once "All " is selected, it will remain selected.

@ImGonaRot @cremor will it solve the issue?

[donnie-msft]

@anangaur simply "remembering" is an improvement, but omits their goal of having it configurable via policy. I'm not certain, but I don't think any VS config can access our Package source dropdown, today.

[donnie-msft]

across projects and sessions

This is exactly why I advocate for it being configurable. If I open a file -> new project, and want to use nuget.org, now my Internal-only project will have its source set to nuget.org? I think project configuration is key.

[anangaur]

Too many configurations ruin the experience with configurations 😉. We should choose the right config and its applicability.

[donnie-msft]

Relevant code bit with comment stating we don't persist Package Source dropdown in settings: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Clients/NuGet.PackageManagement.UI/Xamls/PackageManagerControl.xaml.cs#L504

[cremor]

I wouldn't really need an configuration option for it. I don't see a use case for anything other than "All" to be selected by default. So if Visual Studio would always select "All" I would be happy.