Actually, reading your last sentence again, it sounds like I shouldn't use API keys in cases where I want to keep a feed secure. This is probably the best answer correct? Yes, pretty much. I suppose you could think of it as two different sets of doors that could secure a feed --- the first door (LDAP) is quite secure and can be user/group controlled, whereas the second door (API Key) is quite weak and works a bit like a skeleton key that everyone shares. There's zero point in requiring users to unlock two different doors, which is why we say using an API key doesn't make sense when you've enabled LDAP. If you want to use only an API key, then you must bypass the first door by allowing anonymous. This is less secure and generally not recommended.

Thanks! We will have this fixed in ProGet 4.0.14, which will be released within the hour.

Thanks, Tod, but I want to keep all the actions on the client side. I found that I can just do a GET and a PUT, and once I constructed the multi-part form data correctly and added a boundary to the content, it worked.

Connectors can only be filtered by ID, so you'll have to rely on the client to filter by pre-release versions. You can clear the cache on the Manage Feed page.

Hi, upack is the command line client for ProGet universal feeds. We will soon have it available to download from Chocolatey and Inedo.com, but for now you can find it directly at this URL: http://cdn.inedo.com/downloads/proget/upack1.0.0.zip

I'm afraid we don't have that tutorial yet; but we'd like to soon!

ProGet is the server, so it just hosts your private packages. If you want to push something to a different feed, use the -Source ... argument in the nuget.exe client. Connectors for NuGet are simply a convenience that make it easy to cache nuget.org packages and provide a single endpoint to download them.

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.