Nevermind, apparently, the installation was messed up because of the failed previous upgrades (due to the antivirus). The program was not registered anymore so the installer didn't detect it for upgrade. I simply installed over the previous installation and it worked! Now running on 4.0.9! Thanks a lot for the info and help!

The privileges are cached; if you "invalidate cache" on the privileges page or restart the web application, that should fix it.

I assume, you are looking to deploy a package for deployment later? If this is the case, take a look at this guide, which goes over how to package and deploy an application for deployment using Otter. Otherwise, you can just use standard NuGet.exe client tools to package and publish your packages to the ProGet feed

Thanks for the report, we will investigate this further. We already know of an issue where there is disparity in the UI if the service is in the process of stopping/starting.

By default, Visual Studio 2012 and later does not use the source server even if the PDBs contain the correct source indexing information. To enable the source server, go to Tools > Options, Debugging, General and check "Enable source server support". This is disabled by default as it's a security risk. The mechanism for the source server encodes a command to execute into the PDB file, therefore untrusted PDB files could execute arbitrary code. Users have to opt in. See "Use Source Servers" in Specify Symbol (.pdb) and Source Files in the Visual Studio Debugger for more information.

I was able to get this working. I had to change the license key to something else and save it, then change it back to the proper key and save it again. Once I did that, it asked me to manually validate.

ProGet supports the latest versions of all the major browsers. However, please note that only IE v11 is supported by Microsoft. We do test in IE9, and offer limited support. IE8 and earlier will probably exhibit some issues, but will mostly work most of the time; we do not test with those anymore.

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