HttpClient concurrent behavior different when running in Powershell than in Visual Studio

Two things come to mind. Most microsoft powershell was written in version 1 and 2. Version 1 and 2 have System.Threading.Thread.ApartmentState of MTA. In version 3 through 5 the apartment state changed to STA by default.

The second thought is it sounds like they are using System.Threading.ThreadPool to manage the threads. How big is your threadpool?

If those do not solve the issue start digging under System.Threading.

When I read your question I thought of this blog. https://devblogs.microsoft.com/oldnewthing/20170623-00/?p=96455

A colleague demonstrated with a sample program that creates a thousand work items, each of which simulates a network call that takes 500ms to complete. In the first demonstration, the network calls were blocking synchronous calls, and the sample program limited the thread pool to ten threads in order to make the effect more apparent. Under this configuration, the first few work items were quickly dispatched to threads, but then the latency started to build as there were no more threads available to service new work items, so the remaining work items had to wait longer and longer for a thread to become available to service it. The average latency to the start of the work item was over two minutes.

Update 1:I ran PowerShell 7.0 from the start menu and the thread state was STA. Is the thread state different in the two versions?

PS C:\Program Files\PowerShell\7>  [System.Threading.Thread]::CurrentThreadManagedThreadId    : 12IsAlive            : TrueIsBackground       : FalseIsThreadPoolThread : FalsePriority           : NormalThreadState        : RunningCurrentCulture     : en-USCurrentUICulture   : en-USExecutionContext   : System.Threading.ExecutionContextName               : Pipeline Execution ThreadApartmentState     : STA

Update 2:I wish better answer but, you will have compare the two environments till something stands out.

PS C:\Windows\system32> [System.Net.ServicePointManager].GetProperties() | select nameName                               ----                               SecurityProtocol                   MaxServicePoints                   DefaultConnectionLimit             MaxServicePointIdleTime            UseNagleAlgorithm                  Expect100Continue                  EnableDnsRoundRobin                DnsRefreshTimeout                  CertificatePolicy                  ServerCertificateValidationCallbackReusePort                          CheckCertificateRevocationList     EncryptionPolicy            

Update 3:

https://docs.microsoft.com/en-us/uwp/api/windows.web.http.httpclient

In addition, every HttpClient instance uses its own connection pool, isolating its requests from requests executed by other HttpClient instances.

If an app using HttpClient and related classes in the Windows.Web.Http namespace downloads large amounts of data (50 megabytes or more), then the app should stream those downloads and not use the default buffering. If the default buffering is used the client memory usage will get very large, potentially resulting in reduced performance.

Just keep comparing the two environments and the issue should stand out

Add-Type -AssemblyName System.Net.Http$client = New-Object -TypeName System.Net.Http.Httpclient$client | format-list *DefaultRequestHeaders        : {}BaseAddress                  : Timeout                      : 00:01:40MaxResponseContentBufferSize : 2147483647