Hi @daveschafer, very well documented. This was first discovered as #1190, and we verified what you are seeing back in September timeframe. We have this in the backlog to fix so it works as documented. It turns out it was a bug in NuGet.Core that wasn't respecting this setting correctly.

Hi @ferventcoder
We also have this problem with different customers and can't rollout any controlled softwareupdates with chocolatey. When do you expect that this bug is fixed.
thank you

@sudoturnkey
I played with this months ago and I THINK if you edit chocolatey.config and change the sources to the order of your preferences, you'll get the results you want.

i.e. move your source above:
<source id="chocolatey" value="https://chocolatey.org/api/v2/" disabled="false" bypassProxy="false" selfService="false" adminOnly="false" priority="0" />

I could be wrong. Try it and see what results you get.

as long as this issue persists, you could "automatically" fix the sources by doing something like

$ErrorActionPreference = "Stop"

$cfgLocation = (Join-Path $env:ChocolateyInstall "config/chocolatey.config")
if (-Not (Test-Path $cfgLocation)) {
  throw "no config found at $cfgLocation"
}

[xml]$cfgXML = Get-Content $cfgLocation

$sources = $cfgXML.chocolatey.sources
$sources.source | Sort-Object -Property priority | ForEach-Object { 
	$sources.AppendChild($_) | Out-Null
}

$cfgXML.Save($cfgLocation)

I am just getting into Chocolatey and bumped into this issue. After searching the net I found this report. Based on the info I found here I tried to work arround it by changing the Repo order in the chocolatey.config by removing the public Repo all together, adding my private repo's and then adding the public repo back again. As a result my private Repo's are positioned above the default chocolatey public repo in the chocolatey.config. I even gave my two private Repo's a priority of 1 and 2 and gave the public one a prio of 99. For some reason the Public repo still seems to take precedense over my privates. Am I doing something wrong or is this workarround not fixing the issue? Or could the fact that my privates are UNC based repo's have something to do with this? Thanks in advance..

@martinisoft1 No, this workaround never worked for me (or anyone else?) either. The priority and the order of repos does not seem to have an impact, Choco Repo gets choosen any way.
This issue is still open and I hope that @ferventcoder takes a look at it sometime.

When I find the time I will take a look into the code.

@daveschafer I'm quite certain the workaround I've suggested above has been working for me in the past.
have you checked the contents of your chocolatey.config file?

edit: not so sure anymore..

• just tried reproducing the above presented "solution", it looks as if the source priority is just being ignored, changing the order of the sources in chocolatey.config doesn't seem to have any effect.

@daveschafer @martinisoft1 @sudoturnkey currently the best way to handle this is to remove or disable the sources that don't apply.

@daveschafer @martinisoft1 @sudoturnkey currently the best way to handle this is to remove or disable the sources that don't apply.

Well, the thing is that I do need the public repo for some standard applications. At the moment I am using a prefix for the packages in my private repo's to prevent duplicates, not ideal but good enough for now.

The thing that I find strange about the behavior is that I don't see why Choco would even know that it deals with its own Public repo. Even when I change the Prio, the Order and even the name (and yes I checked the chocolatey.config) the issue persist. One would think that in this case Choco would handle it as just an other Repo but in some way it seems to recognizie it as its Public Repo and give it the highest priority.

@martinisoft1 I don't think it is that. I think it is that it is checking all the repos instead of giving priority, I know it is in fact - I've seen the code in NuGet.Core that does this - it's a NuGet.Core code base bug.

@ferventcoder Is this issue linked to this NuGet issues?

I took a look into the code and played around with some choco commands, I think a good workaround for this problem, which I verified, is the use of the --source parameter.

# list sources
choco source
chocolatey - https://chocolatey.org/api/v2/ | Priority 0|Bypass Proxy - False|Self-Service - False|Admin Only - False.
bob - http://1.1.1.1/api/v2 | Priority 0|Bypass Proxy - False|Self-Service - False|Admin Only - False.

-----

# to install a new package from YOUR source
choco install --source=bob packagexyz

#and to update only from YOUR repo
choco update --source=bob all/packagexyz

What does not work is when you install "package X" from your source and run a "choco update" without specifying a source. The source with the newest packages gets chosen, priority does not matter here.

So like in the NuGet issue mentioned, you would need like a 'source' or 'priority' tag for every choco package seperately, to distinguish from where it should get its updates, which is kinda overkill (but a possible solution).

I hate to have this roll another release, but we have some fixes that need to get out soon and this may be a big undertaking on its own. This is something we want to get fixed sooner than later though!

Are there any news about this topic?

Maybe this will help someone who has the same issue:
I have a local source on a UNC path which has the priority 1 and kept the default "chocolatey" source with priority 0. When I installed a package, the default chocolatey source was used.
The reason for me was, that the version of the package was higher on the default chocolatey source, than the version of my source. The solution was to specify the version of the package and everything worked fine.

Maybe there are other issues with your source. You can check this using this command:

choco list -s \\SOMEFILESVR\networkinstallation

Hello, is there any status update on this? In my organization we really need the ability to have priority respected properly. We have the following use case:

Computers on our internal network reach out to our hosted chocolatey source via our corporate proxy.
However due to COVID we have many people with laptops and VPN connections - the internal proxy does NOT work over our VPN and as such they cannot reach our hosted repo. Because we have the default chocolatey source disabled on all computers, the VPN laptops have no other source to pull from. If Chocolatey could follow source priority regardless of package version, we would be able to enable the default repo to allow laptops to reach out to the community repo while allowing internal workstations to still use our hosted repo.

There have been some performance related problems with the changes associated with this issue (choco outdated command taking much longer to run than normal), as such, we are going to back out the changes associated with this issue, and continue investigation on the problem.

Adding Zendesk ticket for additional customer facing this issue