Eric StJohn

`SystemEvents` cannot know that the `WindowsFormsSynchronizationContext ` is broken here and it's been established that it waits on finalization. I think we need a fix in `WindowsFormsSynchronizationContext` to not block...

> Referencing the package Microsoft.Extensions.Logging.Abstractions will means including the source generator twice in the compilation which will cause the generated code produced twice and cause compilation error because of the...

I took a look at the repro. The problem here is due to WPF's _CompileTemporaryAssembly Target. WPF generates a temporary project and compiles that - that project it's not running...

I see this is in Future milestone - you might want to have a look sooner than that. Seems like something changed here recently that's regressing folks. @singhashish-wpf

TL;DR A simple workaround here would be to make sure conflict resolution runs in WPF's generated project: ```xml ``` Simply add this to any WPF project with this issue. ----------------------------------...

API Compat finding new issues in new major versions is an expected thing. We typically treat that as a desirable feature. It has it's own baselining system to ignore those....

IMO tying this to TFM update is not a good user experience. APICompat rules have nothing to do with the TFM. They are more functions of the language / metadata....

@copilot please address feedback

I think HttpHandler should fail. Maybe this task wasn't observing the failure? That can sometimes happen if the task is leaked. @chcosta do you recall what was on the stack...

@wfurt this looks like a `while(true)` loop in HttpClient and a couple possible failure paths that could cause it to continue looping without incrementing the retry count. https://github.com/dotnet/runtime/blob/228a12c99c7819b45726a9a0e08f2e79c0091cae/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/ConnectionPool/HttpConnectionPool.cs#L521-L545 Probably we...