I believe there was a fix for this (issue: BM-2392 - FIX: Variable bulk edit for releases and release packages checks for Admin_ConfigureBuildMaster task instead of Releases_Manage) in v5.6.9

That worked. Also, I did not need to specify the API key since the user uploading the vsix was a service account with permissions.

The NuGet library is definitely coming! Actually we wrote one for use in Romp, and will just ship that. We'll publish as a pre-release, and once we get it properly documented and whatnot, ship it. But it's fine to use now (the code is really simple).

Hello Javier, There is an error in the PostgreSQL version of NuGetPackagesV2_GetLatestStable, which was introduced in the 5.0 beta. I've filed this as PG-1164 and submitted a fix for my co-workers to review.

The promotion API endpoint does not use a NuGet API key, it uses a ProGet API key. It is unfortunate that the terminology is similar, but feed endpoints are handled independently from ProGet API endpoints, so creating a ProGet API key will not interfere with normal dev use of the NuGet feed. You need to create an API Key in the Admin > API Keys section, and that API key will only be used for ProGet API endpoints (i.e. package promotion, package deployment, and the future "feed management" API).

Please make sure that your root path and feed paths are set; this sounds like an empty root path.

Jon I've run into the same issue before dealing with the npm feeds. I ended up hosting the proget site twice in IIS under different hostnames. In IIS we have two websites: proget.mycompany.com Windows Auth enabled Forms Auth disabled Anonymous Auth disabled formsauth-proget.mycompany.com Anonymous Auth enabled Both sites use the same physical path of your proget installation. The host name in the binding must be different though. That is so IIS knows which way to go, the website with Windows auth or the site with the anonymous auth. We've been using this for several months with no problems. I hope it helps in your situation. Please note, I do not work for ProGet, I'm a fellow customer offering assistance.

Outstanding, thanks Alana

That's the default root directory. Each feed can be customized to have its own path (or use a different storage provider, like Amazon S3).

It's certainly possible, many of these are already built-in Operations in BuildMaster.

To resolve this on our end, I had to use local paths to the extension folders instead of relative in the Advanced Settings page. I was hoping to use relative in our 3 web node NLB environment.

Figured out that my specific package is a pre-release and thus required the prerelease option to be set on the nuget install command.

"End of Central Directory record could not be found." sounds like you have sound corrupt zip file / nuget packages. I recommend you to clear your cache and try again. As long as you configure NuGet correctly, then protected feeds works fine.

It's really hard to say; if the built-in testing functionality within the user directory screens aren't providing any useful information, then you'll need to run the same code that BuildMAster does to try to isolate/trap further errors. https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/Common.BuildMasterOtterProGet/UserDirectories/ADUserDirectory.cs This is the user directory code; it's quite simple, and is using Microsoft's LDAP libraries.

Yes, though it wasn't properly noted in release notes. I just checked; this fix was included in InedoLib v511, and we shipped InedoLib v513 (a newer version which included other changes) in ProGet v5.0.1

It's probably worth mentioning that we also struggle with pushing packages to this Proget instance, unless we allow "Anonymous" access. The error message we see with nuget push is simply Response status code does not indicate success: 403 (Forbidden) It does not seem to make any difference whether we require an API key for pushing packages or not. We have tried the various solutions suggested in this thread, without luck: https://inedo.com/support/questions/2319

Copying the explanation from the private ticket in case anyone else has this issue: Inedo products store timestamps in the database as UTC, but our PostgreSQL library (Npgsql) "helpfully" converts DateTime objects to the local time zone. They added a way to change this behavior in their 3.3 release, but the currently available version of Npgsql is 3.2.5. I've written a workaround for this, where DateTime objects will be converted to UTC by the database middleware. I've filed this as ILIB-7.

Thanks for the report; we're unfortunately powerless against these, since they randomly come and go. I'm sure you're already aware, but just as an FYI, we have published KB#1113 that talks about false positives and code signing.

This was broken due to IIS authentication issue.

Hello Julien, I've filed this as PG-1147 and a fix should be coming in the next version of ProGet.