If it still doesn't work after you've granted anonymous to the feed, then one possibility is that you have WebDAV (caused from a Windows Update?), or a proxy server blocking the PUT request. I've seen that quite a bit..

ProGet does not push packages; but you can use a tool like BuildMaster to help build a pipeline for your own nuget packages, and push to different nuget servers along the way.

Yes, we're currently using dotnet nuget push to push packages. We're using the "legacy" *.symbols.nupkg format, though, to be safe.

Hello Ryan, Sorry about the delayed response. The Push to ProGet Visual Studio extension is for Universal (upack) feeds, not NuGet (nupkg) feeds.

Hello Martin, I've filed PG-1422 to stop ProGet from checking whether anonymous users have any feeds they can access. You may also want to check in SSMS whether any of the indexes need to be rebuilt or reorganized.

Please disable the "Overwrite Package" permission in Admin > Tasks. Then, you will get "Package Already Exists" error

Thanks, that helped a lot. I removed some connectors to myget.org and it's getting faster.

Could this be related to Quirks mode? https://inedo.com/support/documentation/proget/feeds/nuget#legacy

I'm not sure if I totally understand the question, but packages are designed to be immutable, and as such you really can't "update" them. You can delete or overwrite a package if you have permissions, but it's inadvisable and you should not make this part of your workflow. In addition to being against the fundamental package workflow/design guidelines, packages are cached by clients like Visual Studio, and won't see a "new version" of a "version" of a package.

There are no changes in ProGet that would cause this. Most likely the package file is invalid, something is cached, you're using the wrong URL, etc. If you can provide a very specific reproduction case using a new (empty) feed, and a specific set of packages that, when uploaded in a specific order, cause this behavior, we can investigate it further.

Hello George, thanks for your quickly answer. Well, I tried to change the proget configuration ports on docker from 6580:80 to 80:80 and the problems have resolved. I Understand that although proget resolve correctly the url request http://proget.local:6580 and redirect the answer to 80 port when i tried to download a package with choco pack -source http://proget.local (previusly correctly uploaded on proget trought the portal) this query always bound to 80 ports and because of this it´s not possible to find the package and download it. I reinforced these arguments when later saw in the dockerfile details that mount the proget image te next string: (/bin/sh -c ([ -f /usr/share/Inedo/SharedConfig/ProGet.config ] || echo '<?xml version="1.0" encoding="utf-8"?><InedoAppConfig>ConnectionString>'"$PROGET_DATABASE"'</ConnectionString><WebServer Enabled="true" Urls="http://*:80/"/></InedoAppConfig>' > /usr/share/Inedo/SharedConfig/ProGet.config) && mono/usr/local/proget/db/bmdbupdate.exe Update /Conn="$PROGET_DATABASE" /Init=yes && exec mono /usr/local/proget/service/ProGet.Service.exe run --mode=both) I hopesfuly to correctly understanded that the issue was here. In any case now I have two current proget running. One on docker on 80/80 ports and other on windows. Thanks for your help.

Hi Tod, Thanks for looking into this. I just checked and can confirm that the last time we received this error it matched up with an app pool recycle. I'm not sure yet whether this is the source of all our timeouts, but that's certainly given us something to work with. I'll post again if we suspect any other Proget related issues. Thanks again.

We can't reproduce this - in all cases we've tried the casing of supplied package ID's does not matter in requests to ProGet. If you capture the failing requests using Fiddler and attach them to a ticket, we can hopefully find out why it is not working for you.

The tracking issue for this is here: PG-1337

Of course, modifying a package file (i.e. stripping symbols/source) will cause the hash code to change, which is what the integrity check uses. There's no way around that. The stripping feature is important, because Visual Studio will not use a symbol or source server if the package has embedded symbols in it. You aren't supposed to put these in a nuget.org package, but some people clearly do (as the example above). So, just pick which is more important to you.

There is an ountstanding feature for this, and you can follow the progress here: PG-1331

Assuming you don't any server misconfiguration or SQL Server latency issues, then the biggest performance bottleneck tends to be the network. Each client/user will make dozens or hundreds of simultaneous requests, often using machines more powerful than the server, and these requests can be expensive... particularly if you're using connectors... because they have to be forwarded to another server. These requests "pile up" and eventually, the underlying infrastructure can't handle it (IIS, network card, etc), and you start getting timeouts like that. This is where load-balancing comes in, and is pretty important in your configuration as you add users and packages.

Hello all, ProGet 5.1.7 fixes an additional issue that was causing SemVer2 NuGet packages to fail to download: PG-1329

Hello Steven, Try visiting this page in a browser: http://<ProGet hostname>/feeds/<feed name>/NuGet.Frameworks/4.7.0-rtm.5148 There should be an error message like this: The version number provided is invalid, but would be valid if this NuGet feed were migrated to SemVer2. You can migrate a legacy NuGet feed to SemVer2 by clicking the button at the top of the feed management page.

Turns out I needed to migrate the feed to the "new format" that supports semver. Everything worked like a charm afterwards. Thanks