We removed that simply because it was confusing having both actions like that, your best bet is to use the Execute Command Line action, or a PowerShell script in the script library that does what you need.

This is a known issue in the NuGet client v3.2; it does not support integrated authentication (i.e. 401 challenges). This is supposed to be resolved in NuGet v3.3.

I would suggest to reset your admin password using the ProGet.Service.Exe, there is an option in there. And then try to set-up LDAP again.

Yes, but that's because project.json is used client-side; ProGet is really only sent the package id and version, not the project file.

I see, while that works for some projects, not all of our projects uses a build server which complicates the process of deployment. Thanks

It's only a UI issue that's preventing the checkbox from being displayed. Here is the workaround click on the Configure Symbol Server link check "Enable symbol and source server for this feed" uncheck "Strip symbol files from packages downloaded from this feed" uncheck "Enable symbol and source server for this feed" Save

We don't have a tutorial or guide on creating one, but it basically just involves making a UserDirectory class, and then implementing the methods. Note that in BuildMaster 4.9, we changed the interfaces a bit to be more inline with ProGet. You can use a disassembly tool to see how the current ones work, or request the source.

Yes, but note ProGet is licensed for each server it's installed on, so if you keep both servers active, then you'll need an additional license.

You can either: not grant Anonymous any privileges (Anonymous does not belong to any groups so it doesn't have any by default) specifically add a Restriction to the Administrator role for Anonymous (this actually means Anonymous is restricted from performing any tasks that an Administrator could do, which is all of them)

Thanks Tod! One of the downsides of moving to a beta-version of any product of course ;-). Looking forward to the next update. I'll try moving forward without the test, results are looking promising. Thanks!

Maybe you want to write an Extension for ProGet that is invoked whenever a apackage is pushed to a certain feed. Once triggered, you cando whatever you need to do in your extension.

Hi Matt, I would suggest to attach fiddler, and see what's going on. That XML you pasted is what a NuGet endpoint looks like; from there you can append /Packages to the URL, and see more of the exposed API.

ProGet is currently on-prem only, though you could install an instance in the cloud quite easily (a lot of people do that). We will likely have a SaaS/hosted version in middle of next year.

Based on the message, it would appear the registry is not pointing to ProGet, but is instead pointing to npmjs.org. I would do a wireshark or fiddler trace to see where it's actually going, and note what's being passed through.

That should work; but if not, I would make sure that the instance is actually named that (that's the default name), and that the SQL Server is actually running. It's possible the service has stopped.

There is nothing in ProGet you can change at this time that would get around this. Maybe you could create another website that for example, redirects requests from http://repo.ingresso/nuget/ingresso-nuget to http://nuget.ingresso/ ? I'm not sure how well that would work though as it relies on the clients themselves following redirects. You also may have some luck with IIS URL Rewiting.

Unless something has changed, you cannot use Integrated Authentication with npm because the client doesn't support it: http://inedo.com/support/questions/2647 However, if you enable LDAP authentication in ProGet and then disable Integrated Authentication, you'll be able to use your Windows credentials. If it's the backslash that isn't supported, try the Active Directory provider, which supports the user@domain syntax.

Yes, we are in the investigation phase of adding this feed type. If it turns out it's as simple as sharing the functionality of the NuGet feed, it will be released earlier rather than later, but we do not have a scheduled date yet as to when it will be shipped.

The size and last modified/write date are used to determine if a file changed, but in pre-4.9 versions, the local time the server creating the artifact is used in the zip file (instead of UTC), which meant the deployed timestamp could be wrong. That said, it wouldn't cause a full redeploy... only an incorrect timezone. So, let us know if you see behavior like this (or can repro it with a smaller, less important deployment). It's possible the SSH library we're using handles returning dates differently, and there's an edge case we need to address.

Yes, that's just fine!