Hi TJ, That upgrade path is fine, and quite common; as long as the shared storage is the same (I assume it's already a UNC path), then when you start everything up again (webserver, indexing service), it should be the same. There isn't so much risk going from 3.5 -> 4.0, but please do read the ProGet upgrade notes just to see what's coming. Just make sure to do a quick test on the current (2005/single server) set up as 4.0 before moving that to new servers. You can always rollback if there is a realy big issue (though, we haven't seen any yet!) Best, Alana

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

Not in particular, but you might find limitations on intermediate network equipment when you try to download very large files (just like you might from over any web/HTTP point).

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.

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

Hi Alana, Thanks for the comprehensive answer. Looks like things are still quite away off then. It's a pity mono is not more stable right now, hopefully Microsoft will put in some investment, but it looks like SQL Server is not going to be available until for at least another year.

I think this was a regression 3.8.6; if you upgrade to the latest, you should be able to remove them.

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.

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

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.

See: http://inedo.com/support/questions/4487

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.

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.

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.

Please note, the 4.0 upgrade notes discussed the changes to permissions. So in v4, you will just need to edit the "task" that you want to give privileges to.

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.

It's hard to say... 3.6 was almost a year ago, and I know the npm api/format specification has likely changed since then. So, it could be a related to that...