Thanks for the additional troubleshooting. I suspect this is due to the way we are migrating dates from the old table to the new. I've created an issue to track this here. (It may not be publicly accessible yet, it's a new project and the permissions may not have propagated)

Otter, BuildMaster, Hedgehog, and ProGet for Windows all require any supported version of Microsoft SQL Server. So, 2017 would be supported, since Microsoft supports it still. 2005, however, not.

Sadly, for me, the given DLL cannot just be dropped into the folder to replace the old DLL without producing a binding redirect error: [FileLoadException: Could not load file or assembly 'ProGetCoreEx, Version=5.1.3.10, Culture=neutral, PublicKeyToken=20535527eaf4e568' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)] Inedo.ProGet.WebApplication.<BeginFirstRequestAsync>d__2.MoveNext() +0 System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start(TStateMachine& stateMachine) +114 Inedo.ProGet.WebApplication.ProGetHttpModule.BeginFirstRequestAsync(HttpApplication app) +90 Inedo.Web.<HandleBeginFirstRequestInternal>d__28.MoveNext() +306 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 Inedo.Web.InedoHttpModule.ProcessEnd(IAsyncResult ar) +117 System.Web.AsyncEventExecutionStep.InvokeEndHandler(IAsyncResult ar) +219 System.Web.AsyncEventExecutionStep.OnAsyncEventCompletion(IAsyncResult ar) +159 System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() +31 System.Web.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +611 System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +213 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +131 ProGetCoreEx is version 5.1.3.9, however it expects 5.1.3.10

This will be fixed with PG-1313

Update: I've filed this bug with Docker: https://github.com/docker/distribution/issues/2649

It's fixed. Not only that, but listing the packages also seems faster. Thanks!

If you need to supply credentials when connecting to the domain, make sure "Specific list..." is selected, and enter it as: domain.local,CredentialName Where CredentialName is the name of set of Username & Password resource credentials created via Admin > Change User Directory > Advanced > AD Credentials > Create

Thanks for the quick update John. Definitely looking forward to the 5.1 release now, once it is out of Beta.

Ok, I use this KB 2 days ago and i added netbios name, fqdn but same problem. I try to change the user context but same pb. Error 503 - service unvailabable I will change my stack of web and i will go to install IIS...but is strange for an editor to indicate don't use "web integrade proget server" Thanks.

Copying from associated support ticket: It's not a bug per se, more of a design flaw with the introduction of external package stores. Basically, it checked to see if the package could be opened and if not, deleted it from the DB. However, there are many reasons a package might not be accessible (network down, invalid S3 credentials, disk inaccessible, S3 down, etc.), so this functionality was removed since then.

Good questions; You can configure ProGet to block packages with "unassessed" vulnerabilities; this is not the default configuration because a lot of times vulnerabilities are discovered after you've already been using a package anyways That's true, but maybe we could expand webhooks? I'm not sure, but it seems like it could be a feature request if it's something you'd actually want to use, etc.

The tracking issue for this is here: PG-1309

This is actually an artifact of the OData specification from when ProGet was first developed - that was actually the preferred format specified, and NuGet.org didn't support $format=json, so we just followed the OData spec. Anyway, those are just .NET DateTime Ticks in there (and the +0 just indicates UTC), so in your example it would just be: new DateTime(636650168208570000, DateTimeKind.Utc) Of course, if we had it to do over again, it would be something more sensible like ISO-8601.

Hello William, This will be fixed in ProGet 5.1.2. (PG-1294)

The error is generic and there are many reasons why the SSL/TLS negotiation may fail. ServicePointManager.SecurityProtocol property selects the version of the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to use for new connections; existing c# connections aren't changed. Make sure the ServicePointManager settings are made before the HttpWebRequest is created, else it will not work. Also, you have to enable other security protocol versions to resolve this issue: ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 SecurityProtocolType.Tls SecurityProtocolType.Tls11 SecurityProtocolType.Ssl3; //createing HttpWebRequest after ServicePointManager settings HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") If you create HttpWebRequest before the ServicePointManager settings it will fail and shows the error message.

Hi George, Do you have any suggestion that I can do to fix this issue?. Thank you.

Confirmed that was the issue, thanks Tod.

It's possible it may work (I can't verify) if you specify the port in the domain controller host value under advanced settings (i.e. enter your-dc-server:636 as the value). See the LDAP Advanced Settings documentation for info on how to find that page to configure that value. If that doesn't work, I suspect a code change is needed - it is not clear via the Microsoft documentation what the default AuthenticationType is for this call: https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ADUserDirectory.cs#L268