There is nothing in particular on ProGet's side that would cause this to happen; you'll really need to explore package-by-package what's wrong. Check some of the other posts, and of course this documentation for how to debug this... https://inedo.com/support/documentation/proget/feed-types/nuget/symbol-and-source-server

There's just the two connection strings (web and service)... you shouldn't be getting timeouts, however. It might be network related?

OMG I totally overlooked that. Thanks!

I am one of the developers, which is why I can assure to you that ProGet is not issuing a 503. This is IIS. However, based on the new information you've provided, it's likely happening because of an abrupt Application Pool termination such as a access violation, stackoverflow, etc. In such a situation, it's not possible for ProGet to log anything; the program (AppPool) immediately crashes. Then IIS issues the 503 error. However, IIS should be logging these in the Windows Event log; so if you can look into what it is, then we can try to debug it further. This is an easy scenario for us to set-up, and it's a common error condition, but we cannot reproduce it.

This may be fixed by ILIB-19, which makes buffering of Docker layer uploads happen in a temporary file instead of in memory. It's very possible that SlimMemoryStream has a bug that only manifests when it has several gigabytes of data in it. microsoft/windowsservercore has a 7GB foreign layer, and I assume you're using the allow-nondistributable-artifacts option on the Docker daemon because you mentioned the system is not connected to the internet, so the next version of ProGet will stop that 7GB upload from being buffered in memory.

Thanks for the answer and bummer I didn't connect that dot when reviewing the upgrade procedures.

Hello Tristen, Are you using a custom package store, such as AWS or Azure, or are the files stored in the default (local filesystem) package store?

Yes. Just remove the "Anonymous" user from any tasks you've given it to permission to; Admin > Security > Tasks.

Thanks Alana. We double checked the PDB files that were being created, and only the .NET 4.5 version was a "full" PDB. After additional investigating we have found the issue. When working with a SDK style project in Visual Studio 2017, the UI does not accurately set the DebugType Full property in the project. For us it left a condition on the PropertyGroup which only applied the DebugType Full element to the net45 version of the assembly. After removing that condition, we are now getting full PDBs created for each version of the assembly.

Alana, thank you for the update. I guess we can consider this closed until such time as we know otherwise.

Hi, please see: https://inedo.com/support/kb/1072/proget-vs-nugetserver

ProGet does not distinguish requests based on http or https (that's a different layer), so there is an error somewhere else in the stack. Are there any relevant logs from PowerShellGet?

I believe there was a fix for this (issue: BM-2392 - FIX: Variable bulk edit for releases and release packages checks for Admin_ConfigureBuildMaster task instead of Releases_Manage) in v5.6.9

That worked. Also, I did not need to specify the API key since the user uploading the vsix was a service account with permissions.

The NuGet library is definitely coming! Actually we wrote one for use in Romp, and will just ship that. We'll publish as a pre-release, and once we get it properly documented and whatnot, ship it. But it's fine to use now (the code is really simple).

Hello Javier, There is an error in the PostgreSQL version of NuGetPackagesV2_GetLatestStable, which was introduced in the 5.0 beta. I've filed this as PG-1164 and submitted a fix for my co-workers to review.

The promotion API endpoint does not use a NuGet API key, it uses a ProGet API key. It is unfortunate that the terminology is similar, but feed endpoints are handled independently from ProGet API endpoints, so creating a ProGet API key will not interfere with normal dev use of the NuGet feed. You need to create an API Key in the Admin > API Keys section, and that API key will only be used for ProGet API endpoints (i.e. package promotion, package deployment, and the future "feed management" API).

Please make sure that your root path and feed paths are set; this sounds like an empty root path.

Jon I've run into the same issue before dealing with the npm feeds. I ended up hosting the proget site twice in IIS under different hostnames. In IIS we have two websites: proget.mycompany.com Windows Auth enabled Forms Auth disabled Anonymous Auth disabled formsauth-proget.mycompany.com Anonymous Auth enabled Both sites use the same physical path of your proget installation. The host name in the binding must be different though. That is so IIS knows which way to go, the website with Windows auth or the site with the anonymous auth. We've been using this for several months with no problems. I hope it helps in your situation. Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

Outstanding, thanks Alana