Thanks for your suggestion, @atripp, that's definitely something we'll look into when we find time to do so. In the meantime we have implemented the workaround described above, so thanks again for your help.

Thank you very much for your precision. I realy appreciate it. I personaly work with non conterize Postgres database in order to avoid data corruption issue; but I understand your make this decision. Hava a good day, Mathieu HOFERT

You need to create an API in the ProGet UI; API Access and API keys

I think that guide is more for when you host a domain controller in azure as IaaS. Im after connecting to Azure AD in the form of SAML, or OpenIDConnect (Federation) I'll keep an eye on release notes to see when SSO gets released. Thanks

This will be fixed in PG-1273 for the next maintenance release.

I can answer the first three questions pretty easily: ProGet does not support being installed as a sub-application; some users have done a reverse proxy successfully, but we really don't support that configuration The Feed url is based on the name of your feed, so it can be whatever you want. You can't do further customization. That's not a problem But I'm afraid I really don't understand the situation about 4-6. ProGet does have some extensibility hooks that you may be able to use.

You can request it at my.inedo.com, or just ask as a note on the Otter Quote Request Form. What's nice about going through the pre-sales/quote process, is that we can work together beyond just random forum / Q&A posts, as obviously we are generally motivated to help you prove a success to enable a sale ;)

I'm afraid Linux doesn't support Windows Integrated Authentication. As a work-around, you can create a second site in IIS that points to the same path, but doesn't have Windows Integrated Authentication enabled.

I discovered one more error detail. BuildMaster logged an error that it couldn't use the folder (for the "get latest" copy on the build server) because it belonged to a workspace for a different account. I believe this is because I changed from using a domain account to a local account on the TFS server machine for the TFS connection from the BuildMaster machine. I deleted the workspace for the previous account. I edited the TFS connection in BuildMaster, entered the account information for the local account that I am now using, and saved it without doing a "Test Connection". Now, everything seems to be working okay. This installation of BuildMaster has been through many upgrades. Maybe someday I will do a full uninstall and a clean install of the latest version, and build new applications in that version, etc. If anyone needs to know, I found (and then deleted as needed) the TFS workspaces as follows (this is using TFS 2017 and Visual Studio 2017). On my workstation with Visual Studio 2017 installed, I ran the "Visual Studio 2017"-"Developer Command Prompt". This opens a command prompt window with all the appropriate environment variables set to allow the "TF" command to be used. Then, run: tf vc workspaces /owner:* /computer:* /collection:"http://URL-for-TFS-collection/" to show all the existing workspaces (this shows username and workstation as well). To delete an existing workspace, use a command like this (note that this uses the singular form "workspace" where the previous command uses the plural "workspaces"): tf vc workspace /delete /collection:"http://URL-for-TFS-collection/" WORKSPACE-NAME;USERNAME-for-the-workspace This will let you know if there are any pending changes in the workspace, and ask if you are sure you want to delete the workspace.

hi Markus, you should be able to put credentials in your Connector. Then you should be able to connect.

I don't believe the NPM protocol allows for anonymous pushes. You could certainly have your CI put it in a drop folder however, which the ProGet would pick-up.

If you have Windows Integrated Authentication enabled, then it will not be possible to do this. The 401 is occurring before the request even makes it to ProGet, which is how WIA is designed. You can also set up a second site in IIS without WIA enabled. That would lalow the request to get to ProGet, and if you have an "Anonymous" pseudo-user configured with permissions, then the lack of a credential will be ignored.

Thanks, that fixed it.

Ah, I see it. I use Caddy as my reverse proxy which doesn't support this feature.

Ok I figured out what I was doing wrong. I was setting the URL in build.gradle to: http://<user>:<password>@proget-server But it should look like this instead publishing { repositories { maven { credentials { username "$mavenUser" password "$mavenPassword" } url "http://proget-server" } } } With the mavenUser and mavenPassword being defined in ~/.gradle/gradle.properties

This should not impact your ProGet installation

Auth tokens are now supported for npm feeds; you'll need to create the token as a ProGet API Key. Please see the API & Access Key documentation to learn more. This is an updated answer; earlier the answer mentioned the feature was not supported.

The "Pull from Another Repository" actually requires the Feeds_PullPackage privilege; so make sure to grant anonymous that as well. Then it should work as expected!

It looks like there was a regression in 4.6.0 that is causing this change in behavior. We'll have it fixed in ProGet 4.6.3, which will should be released by tomorrow at the latest.

Verified - the problem is resolved after upgrade to 4.6.1. Thanks!