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

The sales team does not check posts on this forum. Please use the ProGet Quote Request form for quote inquiries: https://inedo.com/proget/pricing/request-quote

The issue that you linked has since long been resolved; it was a problem with our beta v4. At that time, the problem was the ProGet was "leaking" some connections (i.e. not properly disposing, as your DBA noted). So, if you're seeing the problem now, it's unfortunately not so "simple" of a problem to fix. It basically means that there is some sort of latency between the web/database servers and/or the database is not able to respond to queries as fast as the web server is making them. There's a lot of things that can cause these, from fragmented indexes to low resources on the database server. Do you know what changed recently? Etc. I'm afraid increasing the connection pool likely won't help :/

ProGet is licensed per server, so if you were to have two servers (even if one is just a test / pre-production environment), you would be required to a purchase a separate license. However, if it's just for migration purposes, then you can use your existing license for the migration period.

Basically you need to make sure all three servers have the same machineKey in the machine.config section. OrchardCMS has a nice docs page on it: http://docs.orchardproject.net/en/latest/Documentation/Setting-up-a-machine-key/

Hey! It did solve my problem, thank you so much! Have a great week-end. :)

Make sure you change the proget webservice to run as a user account that has domain access and not use the local system account on the server.

I'm afraid there's not any further configuration. This will happen on any server, physical or virtual, when the SQL Server cannot be contacted. It's usually related to network connections, or the SQL Server is just totally bogged down from other things. See if rebooting fixed it, that will often help.

Please review KB#1161 for instructions on how to update this.

This is by design; it is the responsibility of a package author to license a package, and make sure that it's a standard license. This way, automated licensing monitoring can catch it. However, as you've noticed, this isn't the case for a lot of open source packages. So, in this case, you'll want to use a different workflow. Just create a "approved packages" feed, and promote approved packages into these feeds.

Understood, thanks for the explanation! So this is an issue on the Jetbrains end. We will definitely contact them and see the course of action that's available. Thanks again!

I'm not familiar with Zabbix, but there are two things you can do to check about the status of the components (Database, Web, Service): If the database (SQL Server) wasn't working, or there was a problem with the website configuration, then visiting / will yield a 500 or some other not available message. You can just query the ProGet service run state directly. You could parse the text on the /connectors page or use the native API to get a status of the connectors.

This will be addressed in next maintenance release as PG-1294 . As a workaround, you can access the package directly by version number even without this fix.

Your best way to do this, would be to use the nuget client, and then pull the cached packages to your feed. "Pulling with dependencies" as a feature in ProGet would require implementing every dependency resolution algorithm of every version of every client, including the non-deterministic dependency resolution used by the npm client, and then somehow letting you select the algorithm version and the additional content required by the algorithm (such as .net framework target version).