I just noticed you actually have already released 2.2.5 I confirm that it does resolve our issue. Great support, thank you!

Feeds_DownloadPackage refers to a user downloading a package from the feed (via NuGet client, VS client, etc.) regardless if it's hosted locally or downloaded from a connector. Feeds_PullPackage refers to pulling a package down from a connected feed into the ProGet-hosted feed. There's a button that does this on the package details page.

Apologies for the delay, but as of v3.0.3, you can configure your feed so that the PDBs are not stripped out.

We managed to resolve this - it turns out that the proget feeds were being ignored because the version of proget was not compatible with NuGet 2.7.1. An update to the latest version of ProGet resolved the issue. Thanks for the response though! :)

If the Anonymous user isn't granted privileges for viewing feed and the request doesn't have an auth header then ProGet will return a 401 response for viewing the feed via API. When this happens, NuGet will issue a credential prompt, and resend the request with whatever credentials you enter. Can you do a fiddler trace to see where things are going wrong?

Hello Please ignore my question. The downloaded nupkg file was faulted. Thanks

Thanks for the update; we do have a work item (PG-130) for improving indexing of .pdb/source on large packages. This will come in a future version, hopefully soon.

We actually have two use cases for delete: maintenance scripts (we have beta packages published for each commit so we need to perform periodically cleanup) automatic validation of new ProGet releases (so we can quickly "validate" a new release before move it into production) I know they aren't common use cases but it will be useful.

Does this happen with all packages, or just one package? Can you try pulling a package to the feed (like JQuery), and then deleting it? Can you disable friendly error messages (webCustomErrors=off in advanced config), and post stack trace?

I am sorry. The package that still caused problems had a version number like 3.40.0000.0. This seems to bother a nuget 2.7 client, but not a nuget 2.6 client. The problem disappeared when rebuilding the package using the 3.40.0.0 version number.

Hi John, I just tested the fix, and it indeed solves the problem. I am impressed how quickly this was handled! Thanks a lot!

Hello, We've identified a bug that's causing this.... it will be fixed in ProGet 2.1.3. In the meantime, if you email support at inedo.com, we will send a patch to resolve this. Thanks, Steve

Unfortunately that issue PG-119 was moved to a future a release because of the priority of the other issues listed in the release notes: http://inedo.com/proget/release-notes#2.1.3 We will try to get this in 2.1.4.

Ah, yes, that is indeed a bug. The home page "Browse" should link to the first available feed. I've logged this as PG-121 and we will fix in a future version of ProGet. The "Feeds" navigation link, however, will show the available packages.

Hey, This is great news! Thanks for getting this sorted out so quickly! Gary

Hello, Thanks for the reply. I have started pushing just the Symbols package, and this seems to be working really well. Thanks Gary

We uncovered the cases in which it might lock... this should be addressed in ProGet 2.1.2 (released today).

Great, many thanks for your support!

There's no specific error message, aside from the SQL error that's being thrown. Since you have both on the same server, perhaps it'd be best to have a single SQL Server instance (SQL Express), and have the BuildMaster and ProGet databases hosted in that server.

Thank you Alex, as you suggested, the issue has been solved increasing the maximum allowed content length in IIS.