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

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?

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.

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

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

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.

I have tracked down the root cause of this issue. NuGet feeds (but not NuGet (quirks) feeds) in ProGet 5 generate a list of symbols, but never actually put them in the database. The fix is filed as PG-1195 and will be coming in the next version of ProGet 5. It includes a button in the feed management page to re-index all symbols in a feed, and packages affected by this bug have a message with a link to the feed management page in the place where the list of symbol files would normally be.

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

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?

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).

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 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; it's not the drop path, but the package source path. You can set this in the ADmin > Advanced Settings, and also in each feed.

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

The 400 (Bad Request) status code indicates that the server cannot or will not process the request because the received syntax is invalid, nonsensical, or exceeds some limitation on what the server is willing to process. It means that the request itself has somehow incorrect or corrupted and the server couldn't understand it. The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method . Therefore, it prevents the website from being properly displayed. The main thing to understand is that the 400 Bad Request error is a client-side error. The cause of a 400 error can be a wrongly written URL or a URL that contains unrecognizable characters. Another cause of the error might be an invalid or expired cookie. Also, if you try to upload a file that's too large. If the server is programmed with a file size limit, then you might encounter a 400 error.

I've logged PG-1192 as a change to sort alphabetically, with exception of latest.

That's the default root directory. Each feed can be customized to have its own path (or use a different storage provider, like Amazon S3).

"End of Central Directory record could not be found." sounds like you have sound corrupt zip file / nuget packages. I recommend you to clear your cache and try again. As long as you configure NuGet correctly, then protected feeds works fine.

Figured out that my specific package is a pre-release and thus required the prerelease option to be set on the nuget install command.

Copying the explanation from the private ticket in case anyone else has this issue: Inedo products store timestamps in the database as UTC, but our PostgreSQL library (Npgsql) "helpfully" converts DateTime objects to the local time zone. They added a way to change this behavior in their 3.3 release, but the currently available version of Npgsql is 3.2.5. I've written a workaround for this, where DateTime objects will be converted to UTC by the database middleware. I've filed this as ILIB-7.