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.

Sorry, but I can't complete Create Account form because I have registered one sometime ago for this email.

Can you share a screenshot of your retention policy, and show you what you expect to be deleted? It might be easiest to submit a ticket for this.

We plan to make the next beta release (5.0.1) available as a Docker image - most likely this week. Unfortunately we weren't able to get one out for the initial beta due to some issues with the PostgreSQL database update scripts, but we have since resolved those.

When this build finishes, docker pull inedo/proget will fix the issue with special characters in the database password: https://hub.docker.com/r/inedo/proget/builds/bi8ds7thvriyfldkbh2daj6/

Please find some helpful tips for symbol server diagnosing here. https://inedo.com/support/documentation/proget/feed-types/nuget/symbol-and-source-server If the GUID is incorrect, then you certainly have the incorrect PDB file locally. It's perhaps embedded in your NuGet package (which will cause problems, since it can't point to a source server), or is being pulled from a cache elsewhere on your disk.

Our MyInedo site uses our ticket tracking system's (YouTrack) API to pull this information, and there is currently a bug in the hosted version that returns all comment bodies as the body of the original post. This is apparently already fixed on their end, but not our hosted instance was not upgraded yet so until that happens responses are duplicated: https://youtrack.jetbrains.com/issue/JT-44298 This however should not prevent you from receiving response emails from the system, are you not getting those? I guess I will try to up the priority in upgrading our hosted version.

Thanks Ben that did the trick :-)

It would be the Windows Event/error Logs, specifically the Windows Service Manager. If ProGet isn't able to run/load, then it wouldn't be able to log anything.