I'm a bit of a loss, because we haven't seen such an error before... and it's not something that ProGet would be doing. You may have some IIS setting enabled, that's intercepting requests and ... doing "something" with them? It's really hard to say, because it simply doesn't make any sense, and the solution will not be found looking in ProGet settings/installation. Would suggest to use the integrated web server in this case. Or, use a fresh IIS installation.

This error appears to be related an extension missing. I would stop/start the agent, which should cause the extension to reload

This is OS & .NET Framework dependent. Many users have reported that setting the follow registry will resolved this issue: Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 Value: SchUseStrongCrypto Data: 1 Note that this will involve a reboot. See this guide on TLS in .NET for more information

Version 1.1.0 of the upack command line tool is now available from http://inedo.com/support/documentation/proget/reference/upack. The chocolatey version has been submitted and will be available once it's approved.

Final results for curl -X PUT... I was able to change C:\Program Files\ProGet\WebApp\Web.config (yes, my server is on Windows 10), and increase the transfer size from 1Gb to 3Gb I then restarted the ProGet Web Service I then tried to upload a zip file 2.02Gb in size..and, it worked.

This is addressed in 4.7.6; was a regression.

That is exactly what I was looking for. Thank you.

Ok, I've found the problem: Docker image manifests have a really complicated way to compute their digest: Parse the manifest as JSON, keeping key order. Remove the "signatures" key of the root object. Re-encode the new root object as JSON, with 3(!) space indents, LF newlines, and no newline at the end. Compute a SHA256 hashsum. The problem was that on Windows, ProGet re-encoded the new root object with CRLF newlines. This is fixed for the next version. (4.7.7)

Well... the error is a bit strange, because EnumerateFileSystemInfos is in fact a method on System.IO.DirectoryInfo. It's a core .NET class, so this error is "impossible" then... I'm wondering if there's an older version of powershell or .net on the server? There has to be some other difference between the servers I would think... You can trigger the RoutineServerChecker under Admin > Service. Hopefully you'll find some clues by running it repeatedly...

Solution found, wrong app pool user. thks all

I suspect the two messages are unrelated... but unfortunately it's really hard to know what would cause the first problem. 99% of the time, especially over long-running things like this, it's a result of problematic network connections. The new Inedo Agents (available in v5) are a bit more resilient to this.

This may be fixed in a new version of ProGet; however please note that in NuGet 3.4 client, they added framework monikers abbreviation ("net" instead of "net45") that seem to be occasionally used. These will be supported in the next maintenance release of ProGet, udner PG-560 (Add Support for new NuGet 3.4 Framework Abbreviations).

We have been running the update since it has been out and it does look like it has fixed our issues with random failing npm restores. Running my LinqPad test script now (which makes 32 concurrent requests for the same resource), still makes it "fail", but now with a 404 as you described, instead of returning an empty package. (Which is still quite weird behavior IMO...) Thanks for the quick response and help on solving this!

I bumped into this issue as well. It turns out if you wanna use existing local SQL server, you need to add an account "NT AUTHORITY\NETWORK SERVICE" to your SQL database. To be clear, this account is added to ProGet database during installation but it didn't mark as "Public" in server role.

this should be resolved in ProGet 4.0.8.

Dismiss my recent answer It works fine At some point the connector was removed from the feed which explains why nothing got listed even though the connector was fine. I'm really sorry for this! Thanks for the support!

Today it's working fine. So definitely a temporary outage on nuget.org.