Hello Sam, This should be fixed in version 4.6.4 of progetx-amazon, which is currently being tested.

INdeed; actually, we've updated our documentation on this matter -- and we do have supporting the v3 api on our roadmap now that it's supported by Microsoft.

If you've removed the "Anonymous" pseudo-user from the privileges for the current user directory, then you will see "You are browsing as the anonymous user, therefore certain functionality may be missing. Click the User Icon in the top right to log in.". note that, if you've enabled Windows Integrated Authentication, you will always be logged in as yourself, so you will not be able to go "anonymous".

ProGet will not give this error code, so it's coming from another tool/service in between NuGet.exe and ProGet software. Please disable WebDAV, and any other things sitting in front of the ProGet server that would issue a 405 before relaying the request to ProGet.

Hi @mhull_0872, We just released the latest version of ProGet 5.2.26 on 2/28/2020 which includes the new Package Deployment API. You can learn more about the package deployment tracking feature here. We also have documentation on how to use the API endpoint here. Thanks, Rich

Unfortunately there's not enough information.. or a question here.. for us to be able to provide a meaningful answer. If this just happens as a one off, please ignore it. if it's preventing you from doing something, please describe in deatail what you're trying to do. I already see some strange things, such as "port 44300" that make the set-up seem not very obvious, so please describe that too.

Surfing Pikachu, That was one of the steps I mentioned in my original post. Did not work for this issue. Alana, Already attached Fiddler before original post. Just showed 404's for symbol requests. Downloading the package locally allows the symbols to be found; but using ProGet's symbol server doesn't work.

It's certainly planned on our end, but because it would require a major change to the way we do package indexing, which is a significant risk and thus could impact a lot of our enterprise customers.

Generally, you "subscribe" to a feed to get notifications; however, there will be a "webhook" feature coming soon that will allow you to send webhook notifications to other tools. We will be posting more information about it soon... stay tuned.

Nevermind, I had to grant the Feeds_AddPackage privilege to the Anonymous User.

Ah ha! Thank you so much. I'll look in to this right now :)

I would remove the "NuGet API Key" from your NuGet feed; that is a seperate thing from "ProGet API Keys", which makes it quite confusing. This is why it will be deprecated in v5. You don't need an API key; you can just publish using usename/[password.

As far as we can tell, ProGet has never returned a 409 response from that endpoint. A quick Google search reveals this NuGet bug: https://github.com/NuGet/Home/issues/2910 You can fix this by upgrading to NuGet.exe 3.4.5, NuGet.exe 3.5.0-beta2, or a later version.

A connector will transparently mirror all of the feed, including pre-release versions. So, if you don't want to see pre-release, then disable your connectors to NuGet.org or use multiple feeds.

Ben, That works. Thank you! TLDR; don't use "MultipartFormDataContent" when making this request.

Thanks, Tod. That works. I appreciate it!

In our testing, we couldn't get the maven feed to crash, but I was able to get an "invalid response" error in Google Chrome when requesting a snapshot from a connector, and I did notice that requesting an old version of a snapshot 404s because ProGet finds the correct version number and then overrides it with the latest version number. We're still investigating...

Hello Mark, This is not currently possible due to a bug, but I've filed PG-1059 and submitted some code that will fix this for review.

ProGet already supports SemVer2 for Universal Packages. Unfortunately, NuGet does not yet support this. Remember they also have a "quasi-support" for this quirky 4-party version number as well, which so many packages utilize. Please refer to the NuGet Team's documentation on SemVer. 3.0.0 and up support SemVer 2.0.0 with a limited capacity. Local folders and shares are unable to parse versions with multiple release labels or metadata due to the use of NuGet.Core.dll from the older 2.11.0 client. Project.json restore supports SemVer 2.0.0 and is able to read local folders correctly since it does not depend on NuGet.Core.dll. In some scenarios metadata is written to the disk folder path which causes. Multiple release labels are supported. Starting in NuGet Client 3.5.0-rc1 has added SemVer 2.0.0 for supported for local folders and UNC shares. It's a much more complicated issue than it appears at first, and with the velocity of the NuGet team's releases has slowed, and it's likely NuGet will not fully support this in a while (document was from Oct 2016). We may add some support for this down the line, but it would require a major change to the way we do package indexing, and thus could impact a lot of our enterprise customers. You ought to consider changing your requirement if you're going to use NuGet packages, given the limited supported from the NuGet team for it.