Thanks for the update @mness_8576; based on this, it sounds like there's definitely a Gateway problem, and that the Gateway is misconfigured / misreporting some error condition from ProGet due to a quirky package request. That's a pretty common thing we've seen as well.

Hi @stevedennis, Thanks for the reply. It turns out my default nginx server was intercepting all http traffic and not allowing requests to get to the Proget server. I solved the issue by disabling the default server (removing it from sites-enabled) and making some config changes to the Proget nginx config file to stop the server from redirecting http traffic to https.

Yeah, that's a nightmare and a half and I can see why you did that. Currently I've tried repackaging the nuget but it brings about other errors, where it restores properly but later on in compile I get build errors. Right now I'm using the legacy version/older version of the nuget URL instead of the current v3 one until they get off of that package and I can remove it from my feed. It follows the format: https://url.domain/nuget/feedName/ instead of https://url.domain/nuget/feedName/v3/index.json .

Hello; I'm not able to reproduce this on the latest ProGet, and I'm thinking the problem may have been the package file was on disk from the previous version. Here's what I did: Create a new Feed with a connector to NuGet NuGet Download package using the URL /nuget/nuuget-public/package/ProxyKit/2.3.3+build.0 File on disk is ProxyKit.2.3.3.nupkg Cheers, Alana

Thanks for the information :)

Thanks John. We have tried the FindPackagesById endpoint and this is completing in 75ms which is much more expected. We are going to continue with this API to see if we can get what we need from it.

Hi, Thanks for letting us know. Looks like the error message is wrong - actually the problem is caused by build metadata being present in a version number that is not a semver2 version. We've filed this as PG-1655 to make parsing these versions more permissive - it will be fixed in the next ProGet release (5.2.23), currently scheduled for Jan-17.

Thanks for the detailed information, that's very interesting and a great assessment. We wouldn't have found this using all of these variables, especially the different Windows desktop version I suspect this might be a bug in the underlying libraries? We just use an HttpListener and a HttpWorkerRequest, both which should handle all of this, in the simplest way possible. I'll ask around and see if anyone knows. But I guess, at least you found a work-around which I'm glad to hear!

Hi Eyal, What version of ProGet are you using? This was a known issue that should have been fixed in version 5.1 Let me know if this is not that case. Thanks! Jason

Hi, We are still discussing this issue internally. I am wondering if the issue could be with the endpoint.. can you change to /nuget/default instead of /feeds/default/nuget Thanks, Jason

The error message you are getting (There must be exactly one package.) is essentially saying the file that you are trying to push doesn't exist. And since I can see that the file is created in the previous pack command, My thought is that file creation is not fully complete or the file is still in use by the pack command. I am thinking it might be useful to add a Start-Sleep -s 5 command between the pack and push commands.

Hi Anderson , Of course, a lot of our customers host ProGet in the cloud, and just install it on their own server in the cloud. But, we found it wasn't so popular to pay us to do that. The pricing was basically hosting costs + license costs + overhead, so something like $150/mo, depending. We stopped offering it, because we found most customers were either looking for a cheap, multi-tenant service (like $20 to $50/mo), or for really advanced infrastructure far beyond our capabilities (like dozens of servers globally linked, at like $10k/mo+). We are planning to launch “bring your own license” VM/Container in the cloud services at some point, and may leverage that as a hosted option. Any datapoints or insights you might have are always welcome, and I’ll share those to our leadership!

You can host ProGet in the cloud (AWS or Azure), but Inedo does not offer hosting of ProGet at this time. It is on our future roadmap, but there is very little interest it based on previous research.

Thank you, in my case this is an internal Nuget package that is deployed directly to Proget. I unlisted a package version in Proget and I see the listed property is false via fiddler but it still shows up in a visual studio search. By the way, I just created a new topic for my issue here. https://forums.inedo.com/topic/3514/unlisted-package-version-still-shows-up-in-visual-studio

I took a while to get back to this thread, but here goes: Today we upgraded to the MSSQL backed version of ProGet, that is currently on the Docker hub (5.2.9.11), and most of it went smooth. However, when restoring all the packages, I did get the unresponsive errors again. But this time the server came back and we could see the log messages. After changing the connection string, things seem to be more stable now when doing a full restore. The new connection string has this appended to it: "Max Pool Size=200;" Hopefully this version keeps us happier, as the old version needs a reboot every other day.

I see; in this cases, go to Advanced Settings, and change the base url property.

Unfortunately we can't figure out any reason that Age would be returning an empty string. We're thinking there must be something else... can you share the entire NUSPEC file so we can reproduce it better.

The root of the issue is the NuGet team's decision to force SemVer: https://github.com/NuGet/Home/issues/3050

As a followup, it's worth mentioning that this occurs specifically when directory providers are switched. The "Active Directory (New)" user directory requires the user@domain.tld format, so switching from the previous "LDAP & Active Directory" user directory (which supported netBIOSdomain\user) no longer can impersonate.

The groupName refers to the package's group name, and it's optional. A universal package is identified by group + name + version. The files do need to be artifacts; that's what will be zipped up and sent to ProGet.