Please note, the 4.0 upgrade notes discussed the changes to permissions. So in v4, you will just need to edit the "task" that you want to give privileges to.

You can use the "Anonymous" pseudo-user, but note that "Windows Integrated Authentication" is a protocol (not unlike HTTPS) that requires negotiation by the client/server before getting to the application layer... and unfortunately it's not possible to have WIA enabled on some urls/feeds and not others.

It's hard to say... 3.6 was almost a year ago, and I know the npm api/format specification has likely changed since then. So, it could be a related to that...

If the JIRA release operation should happen anywhere other than when the release is deployed in BuildMaster (i.e. using the event listener), you'll have to add a custom action or use PowerShell, etc. Alternatively you could fork https://github.com/Inedo/bmx-jira and add it that way, here is the tutorial for that: http://inedo.com/support/tutorials/cloning-and-patching-an-inedo-extension

There weren't any major, systematic changes that would have caused this to occur. Most likely ,the service isn't running, etc... I would roll back to the old version, then try to do the upgrade again.

Hi Owen, you can just run the ProGet.Service.exe, and there will be an option to reset the Admin info and directory provider.

FYI - that's the "Operation" for our Otter product, but the BuildMaster Action works about the same... But in either case you will need to have an agent installed in order to stop the app pool on that server. Alternatively, you could use powershell script to do it, but that would require additional ports and the like be open on the remote server (RPC, maybe?)

Unfortunately the behavior of Visual Studio's Debugging/Symbol Serving can be a bit strange; there's not much we can do to control that... however if you carefully follow the tutorial, it should help you get set up!

Please see http://inedo.com/support/questions/4360

Yes, all of our the free/express versions of our products allow for commercial use! Thank you for your interest.

When I changed IIS to use ONLY Windows Authentication and then changed Proget to Integrated mode, all my problems went away.

Most definitely :) We don't have a target date just yet, but it's on our ProGet Roadmap. I'll add a +1 to the feature. Thanks.

Hi Stephen, Although we don't offer reseller discounts, we are happy to (and often do!) work with any software reseller. If you have an approved reseller on your list, chances are they have already purchased from us before... and if not, we make it very easy. They can just submit a purchase order to us (or start by requesting a formal quote), and we will go from there. Does that help? best, Alana

Believe me, we really wish it was feasible to provide "Integrated Windows Authentication" (i.e. 401/NTLM challenges) for some feeds, and "Anonymous" for others. The problem is that this is implemented at the HTTP.SYS stack level (a kernel-level service), which far below IIS. NTLM/Kerberos authentication is not something we can feasibly implement ourselves... even if we did, the TGS Exchange cannot really run in a protected environment (like an app pool user). This has been a known issue by Microsoft for at least 10 years, and they are planning to introduce some new libraries/options with Server 2016. There are rumors they will drop it altogether in favor of federated authentication (i.e. Azure style). But, it's not huge on their priority list I think.

this should be resolved in ProGet 4.0.8.

Hi, the package is superagent-mocker 0.3.0 fetched from registry.npmjs.org: see display in the npmjs.org : display of superagent-mocker 0.3.0 in npmjs org see display in proget

npm does not support Windows Auth. Unfortunately IIS/ASP.NET does not allow for some things to be Anon, some things to be Windows -- the whole site is one or the other. Best workaround is to create two IIsSites on the site server with different ports. You can point both of them to the same application directory. Note this does not require a separate license because it's considered the same instance, and largely a workaround for the authentication problem.

We're still working it... currently there are some issues surrounding the .NET 4.5 implementation in the Mono distribution, which we hope to see resolved soon!

When I trying after remove all connectors, NuGet.exe install command works without any exceptions. :(