That's not a known bug. It's really hard to say; the function should work, and an error should be logged if it's not deleting. You may find errors in Admin > Erros.

Hello Phil, This appears to be a bug where NuGet packages with no stable versions keep their first-uploaded version as the "latest". I've filed PG-1201 with a fix. As a workaround, uploading a version of the package with a version number that does not include a hyphen (with a lower version number than the actual latest version of the package) will make the latest version update correctly.

It looks like this is just an oversight on our part, because the unlisted package is the latest version. I've logged this as PG-1194 and scheduled to fix in a maintenance release.

Hi @mikhael_3947, I have updated our Docker documentation to include this information about using a proxy with ProGet. I have also included more information about insecure registries and using self-signed certificates with Docker registries, Thanks, Rich

Ok, I see that my issue is exactly what is described in https://inedo.com/support/questions/7450. Thanks for the quick reply. I'll update to v5 when it comes out of beta.

If it's an "active" DR (i.e. the servers are running, it's used for testing purposes, etc) then each server would require a license. If it's something like, a snapshot of a server (and isn't running... but could be as soon as production goes off), then you can use the same license. It's similar to a lot of Microsoft (and other vendors) licenses for non-production environments.

There's a bug, PG-1211, that will ship in 5.0.9 that should resolve this API Key issue!

This was caused by a connector that was returning a 500 server error. Inedo might want to look into better handling of these errors.

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