I had a problem like this (for a different extension tho) and I just restarted the ProGet service, then it worked.

Hi Andrey You should read carefully this Proget support LDAP auth, but not for the free edition Cdt Philippe

Just as a quick update, this was added to our roadmap as an item we will be including. It'll be implemented likely using the same mechanisms as the Repository Monitors, so it gives a lot more flexibility with regards to what it can do (create builds, create releases, etc), and also uses cron-syntax for scheduling so you have even more flexibility. No ETA, but I've added this post to the project plan so that we will upate it once it gets started.

After looking into this issue further we have determined that sequentially ordering the parameters will resolve the issue. Thanks, Jason

We have a lot of customers who host an instance of ProGet in the cloud, but we do not offer hosting at this time for a number of reasons: better control of infrastructure; you can design your instance to fit for you, instead of in the limited buckets that would be provided choose your own provider; instead of being forced into using whatever cloud provider (or random datacenter) we choose, you can pick the one that you use full control over disaster recovery; no company will care about your data as much as you will, and getting a month free of hosting after losing all of your data probably isn't going to make any of your stakeholders happy As far as how to host a ProGet instance in the cloud, you would be safe simply using built-in authentication and installing it on a public-facing server with only the HTTPS port open. "Anyone" could access the log-in page, and any feeds that you give "Anonymous" access to, but on it's own, ProGet has been pen-tested and will be secure. You could also do any of the following: IP Restrict at the network level use ExpressRoute (a kind of VPN) integrate LDAP (Azure version) instead of built-in authentication sync Azure AD with your AD Those are progressively more difficult to configure, so it just depends on how much effort you want in a POC. Note: we don't recommend regular HTTP, because then a "man-in-the-middle" attack could capture authentication information. But if it's only a POC, maybe it's ok. Finally, some articles for your consideration; A Comparison: Artifactory vs ProGet Azure DevOps and BuildMaster Compared - this is specific to BuildMaster, but most of the points will apply to ProGet

Please refer to this topic for help uninstalling the product.

This came in 5.2 -- http://inedo.com/proget/5.2

hi Charlie, Can you provide us with a very specific reproduction case? Here is a very specific case where it's working as expected... { "name": "dfhack-test-1", "version": "0.44.12-r2.p190516000", "contents": [ { "type": "virtualDirectory", "source": "dwarffortress/core/linux64:0.44.12" }, { "type": "virtualDirectory", "source": "dfhack/core/linux64:0.44.12-r2" }, { "type": "virtualDirectory", "virtualPath": "hack/plugins", "source": "dfhack/plugin/weblegends/linux64-pre:0.44.12-r2.p190516000" }, { "type": "virtualDirectory", "virtualPath": "hack/plugins", "source": "dfhack/plugin/df-ai/linux64-pre:0.44.12-r2.p190516000" } ] } You can see this package live at https://proget.lubar.me/feeds/DwarfFortress-prerelease/dfhack-test-1/0.44.12-r2.p190516000

Hi Francois, The quickest way to get something like this implemented is by going through the feature request process this process really drives our roadmap. as for ETA, I wouldn't want to predict that, but we do release new versions on a frequent basis. Thanks, Jason

Hi Darren, We currently on provide filtering on package name and versions for Docker. However, we are very open to new feature requests. Thanks!

Yes. the latest version will work.

Eric, thank you! That was the issue, I didn't know about that issue.

The Active Directory user directory has since been open-sourced here: https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ADUserDirectory.cs

Typically this is caused by a Windows extension that hasn't been updated to the latest version following a BuildMaster v6 upgrade.

In what context would this protocol be used? My understanding is that BITS is used for background/asynchronous transfers, and in the common Otter use-case, the package needs to be available on the server in order to progress through a configuration plan, therefore the only benefit I can see is the network throttling.

This appears to be an issue with the TFS credentials provider - the 401 status code means credentials were not supplied (and the error message confirms that as well); but typically clients should followup with a 2nd request that includes credentials when the 401 is received. If credentials are actually sent and are invalid/forbidden, then a 403 would be returned by ProGet.

This can occur if the username/password credentials for Git are invalid, or more commonly, if a Git raft is configured as read-only (which probably doesn't require authentication e.g. GitHub) then is reconfigured to support write operations.

As a followup, it's worth mentioning that this occurs specifically when directory providers are switched. The "Active Directory (New)" user directory requires the user@domain.tld format, so switching from the previous "LDAP & Active Directory" user directory (which supported netBIOSdomain\user) no longer can impersonate.

Thank you for the report; this will be resolved by the following issue: BM-3364

That's great! Thank you Jhon.