3 ms·

UWP never required AOT, it was an opt-in performance boost (that has since been rebuilt to support all of .NET in ".NET Native"). Today's post-UWP C#/WinRT bin

UWP never required AOT, it was an opt-in performance boost (that has since been rebuilt to support all of .NET in ".NET Native"). Today's post-UWP C#/WinRT bindings don't require AOT either. Beyond WinRT, .NET (Core) has supported all the raw COM, including COM component hosting since at least .NET Core 3.0. It's Windows-Only, of course, to use that, but that should go without saying. It's mostly backwards compatible with the old .NET Fx 1.0 ways of doing COM and a lot of the old code still "just works". .NET has proven that with .NET 5+ and all the many ways it (again) supports raw Win32 fun in the classic WinForms ways. (And all the ways that even .NET Fx 1.0 code has a compatibility path into .NET 5.) It would have been nice if Windows had stronger embraced .NET, but WinRT is still closer to .NET in spirit than old raw COM anyway.

pjmlp 3y ago
UWP always deployed via AOT on the store. .NET Core doesn't do COM type libraries like the Framework does, you are supposed to manually write IDL files like in the old days. Additionally CCW/RCW infrastructure is considered outdated and you should use the new, more boilerplate based COM APIs introduced for COM and CsWinRT support. Lots of changes, with more work, for little value.