This is a good change since the protocol version shouldn't make the entry unique from one that doesn't have that attribute specified. @zivkan: What happens when a package source has a protocolVersion="3" and a user opens the Tools -> Options -> Package Source page, then just clicks OK? With this change, it should no longer be adding a second entry in the nuget.config, but will it update the package source item and remove the protocolVersion attribute? Or will it leave that attribute alone? It would be good to know what is happening in that scenario to see if it's expected behavior or if we have to make changes there as well.

I just tested this branch with a nuget.config that has just nuget.org with protocolVersion="3" and if I make an unrelated change in the Package Source Options dialog, such as adding another package source and click OK, it removes protocolVersion="3" from the nuget.org entry in the nuget.config. This feels wrong to me. If we aren’t supporting the PackageVersion property in the Package Sources UI, we should probably not be removing it either then unless this was a conscious design decision we made at some point.

Unfortunately, a new CompareTo method isn't going to solve all problems. The bug the PR fixes (a duplicate source being added to the config) is more or less the same code that causes protocolVersion to be removed with this PR's current fix.

The package source options page ultimately calls into PackageSourceProvier.SavePackageSources with a list of all package sources. The options page has stripped the protocolVersion out of the package source, so from NuGet.Configuration's point of view, it's doing the correct thing removing the protocolVersion from source, since that's presisely what the VS code is asking it to do.

To fix this, we'd have to at the very minimum make the VS options page remember the protocolVersion from package sources loaded from config. A better solution would be to add protocolVersion to the VS options page, but that's a much, much bigger change. Which should be done eventually, but do we want to migrate the page to WPF before or after making such a change?

I'll investigate having options just remember the previous protocolVersion. Hopefully it's not a major change, but this is one of the older parts of our code (after all it's still using WinForms) that hasn't had as much refactoring/modernization over the years.