Ya thats goes well! thanks alot. Its working now.

hi, i think this is not an nuget or chocolatey specific thing. proget has to render the *.nuspec infos. like uget gallery https://github.com/NuGet/NuGetGallery/issues/2280 regards sundayout

Of course, it's possible that NuGet 3.4 works with your proxy servers differently. I don't know. But in either case, it's most definitely a bug in the 3.4 client; a "nuget push" is a very simple HTTP POST or PUT with a body containing a single file with a multi-part encoding, so if you are getting that error, then no file is being sent (unlikely multiple files). You can use cURL or any other tool to send file to ProGet like that. There is nothing we can change on the ProGet's end to work-around this bug, so please report this to the NuGet team. You should use Fiddler or Wireshark to capture the output from NuGet, and find precisely what requests it is struggling with, so you can share it with them.

You can visit this directly (it'll look a bit strange since it's designed to be a modal page): http://{proget-server}/administration/security/users/change-password Apparently you're correct that the link to that is missing, it's supposed to be in the dropdown beneath the user icon - we'll add it back in the next maintenance version.

You can install a separate website in IIS that points to the same home directory, which supports forms authentication, then use that separate URL for npm & bower. With a separate IIS site, upgrading won't touch it so it will upgrade as per normal with the installer.

There currently is no transform for this and it's unlikely we will add one.

This is correct, bower packages are not packages but simply URLs that point to a git repo. The git repo is the "source" of the package so without continually syncing the entire git repo it wouldn't be very useful. We may in the future add this (so no outside repos are requested similar to npm's and maven's indexing), but it's a ways off.

This means that packages with the same ID/version are being added to the feed, the only way to prevent this is either grant the privilege as described or don’t push the same unique package more than once.

Ok, it worked. If after created a connector the app asked to index and redirect to the scheduled task, it will be nice.

I would use .NET 4.5 with NuGet.exe to be safe.

There have been a few modifications since the version you're running to the symbol/source server that will likely fix the behavior you're experiencing. There is one issue in particular that involved reverse sorting of the symbol file's age value that I believe is related. When you upgrade to the latest, it should resolve the issues.

Well, strictly speaking, it doesn't work as advertised, because I was missing the $format. This gives the desired result. http://progetna11.atlas.cm.com/nuget/branch/Packages()?$format=json&$filter=Id eq 'Web'

Thanks. Once I gave the anonymous user delete package privileges, and passed the API key as a header, I was able to accomplish this. However, I find it odd that a successful DELETE call returns nothing.

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.