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

Thanks for your response. I'm glad to see that this will be fixed in the next release. For the time being, could you please specify which URL individual users should use, because every URL I've tried so far results in a SecuredTaskDeniedException

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.

Those 2 steps are working now. I can work on adding back the other steps in the plan/pipeline. Thanks for your help.

When you download a package, then package is cached by default; if you download aggin, it will use your local cache instead of re-downloading from npm. The caching is transparent, so they will not show up as local packages.

Thanks Alana. Could you guide me to-what table should I be making what changes?

This is by design; symbols work quite weirdly for native packages, and don't follow consistent conventions like .NET packages. So, we can't arbitrarily strip all .pdb files (we only remove them from the /lib path). In this case, we suggest to make a separate symbols feed.

We will explore this further; NuGet 3.4 added new abbrebrivations that we will be supporting in the next maintenance release.

This is a bug in the free edition; we will resolve it in the next mainteannce release of ProGet.

Are you able to do this from the Admin > All Settings button? There should be a checkbox to enable load balancing. Also, FYI -- as an enterprise customer, don't hesitate to fill out a ticket or email us at support - Inedo - com, and include a couple screenshots or more info so we can better help resolve. This Q&A site tend to get a lower priority, so we may respond slower!

I think we've identified this and will fix this in the next maintenance; it only impacts the free version, but you can workaround as you've noted.

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).

Unfortunately symbols/source can be a little complicated to set up and debug; please review the various resources on the symbols tag, such as the tutorial and questions.

We have been running the update since it has been out and it does look like it has fixed our issues with random failing npm restores. Running my LinqPad test script now (which makes 32 concurrent requests for the same resource), still makes it "fail", but now with a 404 as you described, instead of returning an empty package. (Which is still quite weird behavior IMO...) Thanks for the quick response and help on solving this!

Thank you. That was the solution. I had already rebooted once, because the Windows Powershell update required it. I rebooted the machine again and now BuildMaster is reporting the correct version. Thanks again.

Hi again, My mistake, I selected the latest one and didn't notice that MINUTES before the 4.0.13 version was released and corrects this issue (Mine was 4.0.12 after all). Very, very, very fast guys. Awesome! Thanks!

The BuildMaster NuGet Extension is a wrapper around the nuget.exe client. So it really depends on the client version you're using and how you've configured it. See InstallPackagesOperation.cs

Please note a lot of these errors are coming from third-party tools, like svn or msbuild, so it's not possible to know precisely how to fix it without knowing more information. Unfortunately it's really difficult to diagnose or provide further troubleshooting with the information you've provided so far; if you paste/share the entire logs, we might be able to provide more insight. Please see KB#1052 - Troubleshooting Failed Builds and Deployments for more help on how to diagnose.

Hi Ryan, That's definitely unusual! There should definitely be a bunch of logs here, especially showing the exact SCM command-line command that was run. So, something quite unexpected is happening... What source control provider are you using? And also, what happens when you test connection? Can you share the configuration of the provider (a screenshot should be ok), you can send this to us at support - at Inedo dot com.

the execute command-line action will run a process directly. So, if you run the java.exe as the command-line action, and then specify those arguments, it will work in the way you'd like