Not limited to CLI (even at release in .NET 7 it was possible to use it with ASP.NET Core with limitations and there were custom templates to make it work with some GUI framework I think, and MonoGame already worked partially), certainly not in .NET 8. I’m not sure about WinUI 3 itself, but a lot of things today are AOT compatible.
And naturally single-file + trimmed works almost everywhere, in some situations requiring to add attribute annotations for un-analyzable reflection usage patterns.
"Single file" has the annoying property that it unpacks all your assemblies at runtime and dumps them in a temporary directory. There's no good reason it couldn't byte-load them directly out of the executable instead.
Do you mean IncludeNativeLibrariesForSelfExtract attribute? This is a related but still separate feature. If you mean the managed assembles, then it works differently:
"Only managed DLLs are bundled with the app into a single executable. When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder. With this approach, the managed binaries are embedded in the single file bundle, but the native binaries of the core runtime itself are separate files."
For """embedding""" native dependencies into the binary without self-extract, you can't really do that, the closest alternative is statically linking them into AOT compilation instead (but that gets tricky with large dependencies).
> We're not observing an increase in successful connections after rolling back a recent change. We're working to evaluate additional mitigation solutions while we investigate the root cause.
Yep, I can imagine the feeling of doom when the rollback didn't work. Push back from the desk, head droops down, hand on forehead. Then I whisper, "Fuck".
