Home: Configuration override and defaults problem

[mmajcica]

Given the following scenario:

In the %ProgramData%\NuGet\Config\NuGet.config file, I will add the following:

<?xml version="1.0" encoding="utf-8"?> <configuration> <config> <add key="repositoryPath" value="E:\packages" /> </config> <packageSources> <add key="Nexus NuGet Proxy" value="http://blabl/service/local/nuget/feed/" /> </packageSources> <disabledPackageSources> <add key="nuget.org" value="true" /> </disabledPackageSources> </configuration>

now, the user specific config file %AppData%\NuGet\NuGet.config is not present.
If I do execute 'nuget sources list' the %AppData%\NuGet\NuGet.config gets created with the following content:

<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" /> </packageSources> <disabledPackageSources> <add key="Nexus NuGet Proxy" value="true" /> </disabledPackageSources> </configuration>

Now, why is the nuget.org package source automatically added?
How so that my custom package source is automatically disabled?

Is this a bug or is there a workaround?
NuGet client is the latest available version. Some older version like 3.2.1 have even more unexpected behavior as non respecting the disabledPackageSources and ignoring attributes.

[zhili1208]

that's because all NuGet.Config files in %ProgramData%\NuGet\Config\ are machine wide config, If %AppData%\NuGet\NuGet.config is not present, NuGet will do some initialization which add nuget.org and disable remote machine wide source for performance. So in your case, if you don't want nuget.org source, just keep %AppData%\NuGet\NuGet.config and disable nuget.org there. then there is no initialization any more.

Put following content in the %AppData%\NuGet\NuGet.config

<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" /> </packageSources> <disabledPackageSources> <add key="nuget.org" value="true" /> </disabledPackageSources> </configuration> 

[mmajcica]

Seems a bit counter-intuitive. Think about the case of settings a build server. If you want to push some machine wide settings, you will need to know about the user that is going to be used to run the agent, and only once it logged in, you will be able to change those settings. If later the user on which the agent runs changes, you will need to maintain this user specific file.

[mesheets]

@mmajcica - I agree; we are dealing with the exact same issue.

@zhili1208 - The machine configuration was created and exists for a reason. Automatically creating and/or making changes to the user configuration in such a case is unacceptable: in our case, this auto-generated user configuration file is actually breaking the configuration specified by the machine configuration.

In addition to the build server scenarios that @mmajcica mentioned, in environments with managed machine images, machine configuration highly preferable to requiring each user to have to perform some additional setup (and, as @mmajcica also mentioned, subsequently maintain it). Dealing with service account that don't have logon rights is another issue....

[zhili1208]

@mesheets @mmajcica I think you need to use NuGetDefault.Config, it will work for your case.https://docs.nuget.org/consume/nuget-config-defaults

[mmajcica]

@zhili1208 we are using it. The problem is that for every new user that logs on that machine, values that are in the default config file are then overridden in the user specific config file.

[alienisty]

@zhili1208 I think that when you implemented #663, you didn't properly analyze the problem. In my opinion, the better way of implementing it would have been to add support to NuGetDefault.Config to disable such sources, rather than doing so by default within the user configuration.
Actually, if you read the documentation as it is at the moment of this writing, the disabledPackageSources section allows you to do exactly that, without the need of the change introduced with #663.
Also, introducing such counter-intuitive change because of a single user need seems quite arbitrary.
Sorry, I don't mean to be offensive, but we should be very careful with changes to such a widely used tool and make sure we do not break any documented behavior, because that could cause hours of head scratching and loss of productivity.
Unless I'm missing something here, I propose to revert the "feature" and have users properly use the NuGetDefault.Config to disable unwanted sources by default. At the very least, only this well known curated sources should be disabled, not all sources.

[alienisty]

I would like to present a full example of how this change breaks the documented behavior and also breaks NuGet altogether.
Imagine you are in a big organisation and you want to provision NuGet to all your developer machines with a default configuration to add your internal feeds (say a Nexus server) and disable the nuget.org feed so that all developers can use that cached packages from the internal feed.
According to the documentation, you can do so by creating the NuGetDefault.Config in the appropriate location and put the following in:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <packageSources>
    <add key="local" value="https://myfeed.local/packages/" />
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>

  <disabledPackageSources>
    <add key="nuget.org" value="true" />
  </disabledPackageSources>
</configuration>

Now, if a new user logs in, or a user deletes its user config file (%APPDATA%\NuGet\NuGet.Config on Windows), NuGet will (re)create the file automatically and, according to the documentation, should use the specified defaults to populate it. According to what is documented we should get a user configuration file that looks like

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="local" value="https://myfeed.local/packages/" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>

  <disabledPackageSources>
    <add key="nuget.org" value="true" />
  </disabledPackageSources>
</configuration>

Instead you get the following

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="local" value="https://myfeed.local/packages/" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>

  <disabledPackageSources>
    <add key="local" value="true" />
    <add key="nuget.org" value="true" />
  </disabledPackageSources>
</configuration>

which actually means that the user will have no sources at all and NuGet will not be able to restore any package.

[zhili1208]

@alienisty I agree with you, https://github.com/NuGet/Home/issues/663 is to disable slow machine wide source by default, it should not disable source from NuGetDefault.Config, it's a bug, we should fix it

[trondhindenes]

Did anything happen here? We're struggling with nuget disabling our custom machine-wide sources. I need to provision global sources for our build server automation without interacting with the user that will be running nuget. Is there any flag I can set that allows the machine-wide sources to come up as enabled by default?

[anxkha]

Bumping this. I am running into the exact same problem at my company as well. Machine NuGet.config is getting stomped on by the auto-generated AppData config. Not cool :(

[emgarten]

Does this repro in nuget.exe 4.4.1?

[Vilmir]

Bump on this topic.
My company has an on premise Nuget source that requires the VPN connection on.

When I forget to turn it on and restore some packages, the on premise source is automatically disabled without me being notified.

Then restore always fails, and the developer has to be aware of this auto disabledPackageSources in the Nuget.config at user scope...

[emgarten]

@Vilmir that does not sound related to the issue of the default nuget.config automatically disabling sources. There are other issues tracking that scenario.

[Vilmir]

@emgarten haaa you are right. Good to know my scenario is tracked, it is a major pain.

[mjring]

bump. Also having this same issue with the build server scenario, as described by others above.

In our case, trying to stand up a TFS 2018 RTM build agent that relies on the NuGet Install build task (which uses NuGet 4.0.0.2283).

Is this still outstanding or is there a version that resolves this issue.

[vicp-iq]

bump. I'm also experiencing this issue. My scenario is that I I have a pool of build agents, and I regularly swap new agents into and out of the pool, and I create new agents programatically all the time. It used to be fine for me to just plop a config file into "C:\Program Files (x86)\NuGet\Config" when the new agent is getting initialized, but now I need to wait for the user account used by teamcity to get initialized and then invoke code to enable the package source for that user. And If any developer wants to log in as themselves to reproduce a broken build, they are going to encounter a new and unexpected error.

All I need is an option to override this behaviour at the machine level.

[medianick]

Same issue here. We're expanding our Jenkins build infrastructure to incorporate dynamically provisioned Azure VMs, and the process of provisioning these from a sysprepped base image causes our list of intentionally chosen/enabled NuGet sources to get disabled, and builds fail.

Unless there's something that can be done to NuGet configuration _prior_ to the sysprep operation that would survive through it, my only option at this point seems to be to use nuget.exe as part of a VM initialization script to manually re-enable those sources prior to any builds running on the VM.

[medianick]

Follow-up to the above comment: I added NuGet.CommandLine 4.5.1 (current version) to the base image (via Chocolatey) and am doing this as my agent initialization:

nuget sources enable -Name nuget.org nuget sources list

Nevertheless, the output I get when the agent is connected, and the above two commands are run, looks like this:

````
Package source with Name: nuget.org enabled successfully.
Registered Sources:

1. nuget.org [Disabled]
   https://api.nuget.org/v3/index.json
   ````

I'm really sure what's going on with these disabled package sources, or how to get around it in this dynamic VM scenario.

[trondhindenes]

We ended up spending _tons_ of time creating custom psexec scripts to run nuget configration commands as the "build user" in our environment during the deployment phase. This should be totally unnecessary. It's really worrying that there doesn't seem to be any activity on this issue.

[PatoBeltran]

We have been working on improving the experiences around nuget.config… As part of this wave of work, we have removed the disabling http sources by default from machine wide configs when creating the user wide config. This means that we will still add nuget.org as a default source in a newly created nuget.config, but it won't be disabling any existing source from a machine wide config. Hopefully this unlocks the scenarios discussed above and improves your experience!

This changes will ship in the next release.

[PatoBeltran]

Closing this as it should have been fixed in 15.9. Feel free to reopen is this issues are still reproing.