The url is wrong, and we will update this in the next maintence release

Thanks for clarifying that about the Nuget feeds. Awhile back I understood the behavior had been changed so new Nuget feeds did not function the same way. It was a discussion related to Jenkins so I may have misunderstood where the change was.

I had to change 2 things when I had this problem on my windows computers. 1: I could not use the ip-address because of SSL errors - I had to use the host name. 2: I had to make sure that I logged on to the correct port. Your example was 88 in both login and push, but I forgot to use the port in the login command (I was using port 443). Perhaps this will help someone having the same issue.

Thanks, will try IIS rewrite module for that.(

Here is an example path to a .pdb file, the same folder contains .dll: C:\Users\nsitnikov.dnx\packages\JA.AppCentral.Logging\0.1.7-Build1\lib\dnx451\JA.AppCentral.Logging.pdb Package folder also contains the source in C:\Users\nsitnikov.dnx\packages\JA.AppCentral.Logging\0.1.7-Build1\src folder

Great! Thank you for the quick response, and also for an excellent lead time. Impressive!

Hi Junaid, This is a known issue with npm; basically it's sending a JSON document with two "dist" properties. For example... { "dist": "value1", ..., "dist": "value2" } The JSON Library we're using isn't too keen on that, and we already have a fixe (PG-603) planned/scheduled for the next release.

Is there anything listed on the Administration > Error Log page that relates to this? Errors listed there will have additional context (feed, connector, etc) If it doesn't appear there, I guess you could enable 1 at a time to see which one is the culprit.

Chocolately packages are, essentially, nothing more than a powershell script that downloads and runs an installer from some url on the internet. It would be virtually impossible to inspect arbitrary powershell scripts and determine what they would download when run, and then download/proxy those installers. So, if you want full control over all aspects of the chocolatey packages (including the installers that are downloaded), you will just have to create your own based on the contents of the open-source packages.

The error you shared was: An error occurred processing a PUT request to {url}: Invalid user name or password. A PUT request is what the NuGet client does to push packages to a feed. You'd want to look for a message related to GET or other requests. But, if you're seeing an unknown, then the problem is likely authentication related, but you'd have to look in the error log, it could be a bad url too... You can always try run fiddler, and attach ProGet to the fiddler proxy server to see precicely the requests that proget is making as well.

Can you share both the .nuspec and packages.config file? That would help quite a bit.

Sorry for a late follow up on this. So one place where this solution falls apart is that your Jenkins add-on for BuildMaster does not support the meta-tags in the version field.

Aha! Thank you! I didn't realize the feed wasn't at the root, since normal 'nuget push' and 'nuget install' commands worked with just the root URL as the '-Source' parameter. Only the 'nuget restore' failed.

This may be fixed in a new version of ProGet; however please note that in NuGet 3.4 client, they added framework monikers abbreviation ("net" instead of "net45") that seem to be occasionally used. These will be supported in the next maintenance release of ProGet, udner PG-560 (Add Support for new NuGet 3.4 Framework Abbreviations).

In my original example that I used, the web user did have permissions. In fact, the user I used was the admin user. I did both create a special user with delete attributes and test the admin user. Both results were the same. Success was reported, but the package never really was deleted. I'm not using a feed APIKey, I'm only using users that have appropriate rights to do certain things, like delete.

Thank you for the report - this will be resolved in v4.0.7 which is due out later today.

RE: Retention Policies - those checkboxes are filters against the set of all packages, so if none are checked, then all packages would be deleted. Each checked box adds an additional restriction to or limits what would be deleted.

The issue turned out to be more of a Nuget issue, I believe. According to Nuget's docs, I should be able to mirror my package by specifying the push package URL in the following format: (proget server)/api/v2/package/. However, this just grabs the first feed under /package. Instead I needed to specify the feed name: (proget server)/api/v2/package/myfeed

I assume you can see the package when you browse the feed in ProGet? If so, then Visual Studio is filtering out your package because it's targeting a different framework than your package is configured for. For example, you may have a net45 package and are trying to make a net35 project.

not currently, but it's definitely on our roadmap to do a caching in a similar manner