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.

Excellent. Thanks for letting me know, Alana.

To solve this, make sure to have the following nuget.config file in the same dir as the .sln file. <?xml version="1.0" encoding="utf-8"?> <configuration>   <packageSources>   <clear />   <add key="ProGet" value="https://your-proget-server/nuget/feed-name/" protocolVersion="2"/>   </packageSources> </configuration>

It sounds like your load balancer is somehow trying to interact with the Docker protocol in some manner... there's nothing on the ProGet side that should cause that message in the client. It's hard to say, however, given that the load-balancer is forwarding requests to the ProGet software..

Those features shouldn't be available in free versions; if so, that's an oversight/bug.

Unfortunately, no, I was not. I'm in the process of taking a look at ProGet running in containers again, I will test in the near future and let you know. I don't expect it to be working unless something changed with the containers in the last several months.

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.

Sorry but I run the indexer and it fails... Creating C:\ProgramData\ProGet\Packages.maven2\I22 if necessary. Opening C:\ProgramData\ProGet\Packages.maven2\I22\next-index.gz to write feed index. Writing local artifact info to feed index. Writing connector http://xcdeveljees2:8081/artifactory/novagalicia-repository artifacts to feed index. Unabled to open Lucene index for connector 31 Index generation complete.

We do not provide a migration utility or tool, but if you create one we would be happy to share it with the community.

You'll need a different path for the ServiceTemp Path. Both Web Site and Service unpack to that directory and load files from there... so there will be a collision.

If you have Windows Integrated Authentication enabled, then it will not be possible to do this. The 401 is occurring before the request even makes it to ProGet, which is how WIA is designed. You can also set up a second site in IIS without WIA enabled. That would lalow the request to get to ProGet, and if you have an "Anonymous" pseudo-user configured with permissions, then the lack of a credential will be ignored.

Thanks, that fixed it.

This was a breaking change NuGet team made in NuGet 3.4 (I think). We did not want to not implement, as the change would impact a lot of our customers who rely on the quirks of "non-normalized" versions. So, as a compromise, the NuGet team implemented a searching strategy in the client to try a normalized version of the number (like 0.0.0.0), and then try non-normalized version (0.0.0) if not found. At this time, you'll need to do the same for your searches; if we ever decide to implement the normalized version, this strategy will be backwards compatible.