Hi Alex, thanks for the feedback and the sneak peak at Proget 2024. Just a little background on how this came up: A developer actually came to me the other day and asked "Hey, can I use packages with license XYZ?", and my initial reply was "Well, just check what our Proget server says about that license" (we also have a written policy on how to handle the most common open source licenses, but it's not as frequently updated as our Proget license rules), but then I realized "Oh wait, you probably can't see whether there is an explicit rule about that license, because you don't have access to the license rule page..." I'm looking forward to those new features in Proget 2024, and I'm pretty sure they might change some of our workflows. If after testing Proget 2024 I still feel like there is a need for developers to see details about rules, even though they can't edit them, I will update this post. Have a nice weekend!

Hi @devops-services_2004 , In this case, can you open a ticket and send us that tar.gz file (attach on the ticket)? From there we will load it in a debug version of ProGet and identify where the problem is occurring. Not something that will be easy to spot by inspecting a file :) Thanks, Dean

You are an amazing person! Thanks for the assistance, that worked. @dean-houston

Hi @Ricardo_C_RST , For EC2 (a virtual server), you can just follow the ordinary Inedo Hub installation process. As for HTTPS and Domain, that's a setting probably easiest to do in AWS. I'm not familiar with AWS, but something like CloudFront might help? Dean

@jon-benson Hi John. How was your experience in setting up ProGet on EC2 and joining it on your existing domain? Any issues you encountered or tips you can share?

Hi @devadmins_4004, I haven't tried to reproduce this yet, but I looked the code briefly and am not sure why it wouldn't work. Is this ProGet 2023? What is the specific response? Response code + body if possible. I wonder if you could try to use the username of api and the password of your api key? Thanks, Alana

@rhessinger, I can confirm that 2023.3 has fixed the issue. Thank you very much!

Hi @MaxCascone , Thanks for pointing these out; we will get the RPM icon fixed (probably a minor CSS thing), and then then hide the option on the Manage Asset Directory page (via PG-2540). This view is intended mostly for ProGet ISV Edition use cases, and we likely won't expand on this in ProGet 2024, since you're probably first person who commented on it Cheers, Dean

Thank you. The problem seems to be caused by Web.ConcurrentRequestLimit setting. If the server receives lots of requests and needs to query itself, these requests will be queued when the limit is reached. So they never finish in time and the original request throws the timeout exception.

Hi @cshipley_6136 , We recommend using the /health monitoring endpoint. As you can see, it makes a connection to the database by calling that stored procedure. We do not recommend calling other URLs; and there is no reason another page would work. Calling other pages will impact performance and likely yield incorrect results. You're right, it might have to do with a "connection pool" problem -- but that's all managed at the driver level. You can control connection pool settings by changing connection string values, but to be honest we have no idea what the impact will be. Your best bet is to open a case with Microsoft, who has the expertise to know how to troubleshoot these intermittent "error 40's". They may have specialized tools or "secret debugging commands" you can use. This is all happening at the operating-system or driver-level, and while we're doing our absolute best to help you troubleshoot, but we have never seen this happen before and our main resource is searching google. And this is not an easy error to search for,..as you've probably noticed. Please keep us in the loop. Best, Alana

Hi @c-schuette_7781 , This error is occurring on the remote server (i.e. nuget.devexpress.com). This error can happen when a server is overloaded... so you're basically doing a DoS on DevExpress's server. You'll need to try again or contact DevExpress for help,. I believe that DevExpress wrote their own, custom NuGet server. We've had several issues with it in the past. While talking to them, you should also suggest they switch to ProGet ISV Edition like some other component vendors Best, Steve

@rhessinger

@valeon @miles-waller_2091 @olivier @It-purchasing_9924 @entro_4370 Took a bit, but CRAN (R) feeds have arrived https://blog.inedo.com/inedo/introducing-cran-feeds-in-proget/

Hi Steve, Moving the API key to the header worked - thank you very much! Kind regards, Mark

Hi @pallavi-tarigonda_9617, Adding an entry to the hosts file should not cause a "blocked" connection, so it sounds like there's definitely something strange going with your machine's configuration. I'm not sure how to troubleshoot this further. Self-connectors work fine in testing Free edition, and other users don't have an issue. If it helps, here's the code that ProGet uses to determine if a connection is local: public bool IsLocal { get { var connection = this.NativeRequest.HttpContext.Connection; if (connection.RemoteIpAddress != null) { if (connection.LocalIpAddress != null) return connection.RemoteIpAddress.Equals(connection.LocalIpAddress); else return IPAddress.IsLoopback(connection.RemoteIpAddress); } if (connection.RemoteIpAddress == null && connection.LocalIpAddress == null) return true; return false; } } I would explore the hosts file issue; the fact that a loopback (127.0.0.1) entry wouldn't work sounds like there was some kind of data entry error/typo in your hosts error, but hard to say. Best, Steve

Hi @ivan-magdolen_6846, An "Invalid credentials specified" basically translates to "invalid username/password". In this case, it doesn't matter that the user has permissions or not (authorization) -- they simply can't login (authentication). I would try this without chocolatey; you can simply visit the API urls in an "incognito" browser directly, and enter the username/password prompts from the browser. This should be a browser-prompt, and not the ProGet log-in page. Once you can access the API urls, that will give you an idea of whether the LDAP is workikng or not. Cheers, Alana

Hi @kigiwow570_6179, I don't have enough information/specifics to answer the questions; it really depends on the API queries being made, etc. Some API calls result in errors, others do not. In general, doing a NuGet restore will not result in errors being logged. Best, Dean

Hi @kigiwow570_6179 , These errors are being "forwarded" from NuGet.org, and if you're seeing them it means that "something" on your network is making requests to a ProGet feed that has a connector to nuget.org. This is typically an old, outdated tool or script. You'll need to track this down and update/disable it. It could also be a self-connector that is connecting to a feed that also has a connector to ProGet using the V2 APi - so double check your self-connectors. Best, Dean

@dean-houston About the missing files (FileNotFoundException), I made a mistake in my docker-compose file, so the packages volume wasn't persistent. Noob error , sorry about that. Best regards PhilippeC.

Hi @stevedennis I was just looking to configure Proget as good as possible. This part was a little bit fogus for me I thought this was a bug ... Thanks for your reply Best regards PhilippeC.