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.

Yes, though it wasn't properly noted in release notes. I just checked; this fix was included in InedoLib v511, and we shipped InedoLib v513 (a newer version which included other changes) in ProGet v5.0.1

We plan to make the next beta release (5.0.1) available as a Docker image - most likely this week. Unfortunately we weren't able to get one out for the initial beta due to some issues with the PostgreSQL database update scripts, but we have since resolved those.

Hello Julien, I've filed this as PG-1147 and a fix should be coming in the next version of ProGet.

Please find some helpful tips for symbol server diagnosing here. https://inedo.com/support/documentation/proget/feed-types/nuget/symbol-and-source-server If the GUID is incorrect, then you certainly have the incorrect PDB file locally. It's perhaps embedded in your NuGet package (which will cause problems, since it can't point to a source server), or is being pulled from a cache elsewhere on your disk.

Package promotion is a paid feature; please see Features by Edition.