Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"dotnet nuget remove source nuget.org" doesn't work the first time #10745

Closed
heng-liu opened this issue Apr 9, 2021 · 7 comments · Fixed by NuGet/NuGet.Client#3907
Closed
Labels
Priority:1 High priority issues that must be resolved in the current sprint. Product:dotnet.exe Type:Bug

Comments

@heng-liu
Copy link
Contributor

heng-liu commented Apr 9, 2021

@aortiz-msft commented on Fri Feb 12 2021

Inside the interactive container, run

dotnet nuget list source

It will list nuget.org as a source:
“Registered Sources:
1.
nuget.org [Enabled]
https://api.nuget.org/v3/index.json

Run

dotnet nuget remove source nuget.org

It will say “Package source with Name: nuget.org removed successfully.”
Run (again)

dotnet nuget list source

Expected behavior:
The list should be empty. Nuget.org should no longer be a source to pull packages from.
Actual behavior:
“Registered Sources:

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

    Observations:
    Trying to remove the source a second time seems to do the job of removing the source for good. The third attempt fails, and the list of sources is empty as expected. However, if you trust the output messages and exit codes of the first commands you might very well end up with believing that you have removed the nuget.org source when in fact you have not.

@heng-liu commented on Fri Feb 12 2021

Tried to repro in following three cases:
1.I could repro when nuget.org is the only feed in user-wide NuGet.Config file.

2.If there is a second feed(e.g. secondFeed /home/henli/packages) there, and I remove the nuget.org feed, the nuget.org will not be added back automatically when running dotnet nuget list source.

3.If I remove the second feed first, then remove the nuget.org, and run dotnet list source, it will show "No sources found.
" and nuget.org will not be added back anymore.

The reason might be: NuGet will create a default user-wide NuGet.Config file( with only nuget.org feed) when the NuGet.Config file doesn't exist, or the setting is empty there.
The code is:
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Configuration/Settings/Settings.cs#L551-L564
But I haven't figured out why case 3 doesn't add nuget.org back. I still need some investigation.


@heng-liu commented on Fri Feb 12 2021

Tried to patch and debug and found the root cause is in the following code:

line1   if (File.Exists(defaultSettingsFilePath) && userSpecificSettings.IsEmpty())
line2   {
line3     var trackFilePath = Path.Combine(Path.GetDirectoryName(defaultSettingsFilePath), NuGetConstants.AddV3TrackFile);
line4
line5     if (!File.Exists(trackFilePath))
line6     {
line7        File.Create(trackFilePath).Dispose();
line8
line9        var defaultSource = new SourceItem(NuGetConstants.FeedName, NuGetConstants.V3FeedUrl, protocolVersion: "3");
line10      userSpecificSettings.AddOrUpdate(ConfigurationConstants.PackageSources, defaultSource);
line11       userSpecificSettings.SaveToDisk();
line12    }
line13 }

So we have only one nuget.org source in NuGet.Config file,
when we run dotnet nuget remove source nuget.org, for the first time,

  1. It actually removes the nuget.org feed from the NuGet.Config file.
  2. There is no track file (.trk) generated besides the NuGet.Config file.

When we run dotnet nuget remove source nuget.org for the second time, it will found there was no track file in line5, so it will
1.Generate a track file in line7
2.Generate a default NuGet.Config file with only nuget.org feed, and save it to disk in line9-11.

When there is a track file generated, it will skip line6-12 to generate a default NuGet.Config file.
So from now on, dotnet nuget list source, or any other commands would access the NuGet.Config file, will get the right contents(empty, no source) of NuGet.Config file.


@heng-liu commented on Fri Feb 12 2021

Found the PR adding track file: NuGet/NuGet.Client#458

I could repro on NuGet.exe 3.4.4.


@zivkan commented on Thu Feb 18 2021

This bug, or at least a summary, would be valuable for customers so should be on NuGet/Home, especially so that when this ships GA there's an issue for customers to read in the release notes. At least, in my opinion.


@heng-liu commented on Thu Feb 18 2021

Thanks @zivkan . I'll move it to home.
Do you have any concerns? @aortiz-msft

@heng-liu
Copy link
Contributor Author

heng-liu commented Apr 9, 2021

Closed as fixed.

@heng-liu heng-liu closed this as completed Apr 9, 2021
@nkolev92 nkolev92 added Priority:1 High priority issues that must be resolved in the current sprint. Type:Bug Product:dotnet.exe labels Apr 13, 2021
@nkolev92
Copy link
Member

@heng-liu
You should make sure that the issue has correct labels and releases, otherwise it won't show up in the release notes.

@heng-liu
Copy link
Contributor Author

Thanks @nkolev92 !
Sorry that I forgot about adding labels after transferring it from Client.Engineering repo..

@gonzalocasas
Copy link

Could it be that this breaks default behavior of the nuget github action?
Starting today I get errors on github actions trying to install a package because the nuget.org default feed is not listed there anymore:
image

(Notice that I'm not using nuget's restore here, it's a plain nuget install command line)

@zivkan
Copy link
Member

zivkan commented Apr 29, 2021

@gonzalocasas please see actions/runner-images#3038 and #10586

@gonzalofernandezmoya
Copy link

I was suffering exactly this but I hadn't got the NuGet.org source.

I will leave here the content of the XML so it may help anyone

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

@Mailaender
Copy link

This is still a problem in .NET 6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority:1 High priority issues that must be resolved in the current sprint. Product:dotnet.exe Type:Bug
Projects
None yet
6 participants