I managed to perform the upgrade. I had to stop IIS before running the process and run the following command: ProGetSetup4.0.9.exe /Upgrade /S /BackupDatabase=false

It's a false positive; see KB#1113 - Anti-malware False Positives, Code Signing, and Safety of Inedo Products for more information. Please let your malware protection provider know about the false positive; the more people who do, the greater the chance they won't flag these in the future.

Thanks. I want that Administrators won't do it either to prevent accidental problems.

Take a look at the Getting a Simple Application into BuildMaster Tutorial for a good way to get started!

Well, there is literally no js error since the browser loads forever and never returns. There is also no logs in the admin section.

If you have locked yourself out of ProGet, then you can use ProGet.Service.exe to reset the Admin account.

The easiest option is to put them directly in the URL of the repository: https://username:password@domain/

This error is coming from NuGet.org; unfortunately, certain long quriers will sometimes cause that error. It's intermittent. This is planned to be addressed with an "offline package index" in a future proGet release.

There is no special path; a cached packages is stored under the feed's package store, alongside regular packages.

A "legacy" NuGet feed is a single folder; it's possible it's a different location than \Packages\Default if you configured it later.

When the new SQL Server is installed, simply backup and restore the existing ProGet database to the new server, then update the connection strings in the .config files located in the Service and WebApp install directories so that they point to the new server.

UPDATE: This is a breaking behavior change planned for NuGet 3.4. https://github.com/NuGet/Home/issues/2298 This may not have a large/widespread impact, and it might be difficult for us to fix server side without breaking everything other than NuGet 3.4... so for now our advice is "don't upgrade to 3.4 or don't rely on that behavior". Please update/share if this issue impacts you.

Nevermind. It was due to my local cache in ~\AppData\Roaming\npm-cache so npm never tried to fetch them from the server. I cleaned it out and ran npm install and now everything works! Sorry for the noise.

I am getting this same issue, i guess the best thing to do is to use a third party app like Long Path Tool. Just download it and use it to solve this issue. I hope this would help.

Thanks. That would be great to, app to app, I am referring to within an app itself. But it sounds like both would be the same so that would be perfect. Looking forward to 5.

That's unfortunate, but understood. Thank you for your timely response. However, I certainly wouldn't classify the workaround as easy with an actively released package such as EasyNetQ. Am I right in assuming the workaround would require manually monitoring for new versions on NuGet and pulling the new packages to ProGet whenever a new version is released? If so, that is quite an administrative overhead. I'm sure there are other packages on NuGet which have crossed the 100 releases boundary (or are nearing it), so this is probably not an isolated case.

In this case, you will need to diagnose why your computer (client) is unable to connect to the server (ProGet). It could be so many things.... bad wireless reception, the server is turned off, or anything in between. Suggest to use Wireshark to see where packets/information is being lost, or work with your network engineers to see why this is happening.

Unfortunately there's not enough information provided for us to provide any assistance. I'm not sure what feed/package type this is (NuGet, npm, etc), what version you upgraded from, how you're trying to use ProGet, what specific errors you're receiving, etc.