.NET and Native AOT improvements for CsWinRT 3.0

[Sergio0694]

This epic tracks all work items across .NET 10 and Native AOT, related to supporting CsWinRT. We're currently working on a new version (see CsWinRT/fhl/cswinrt-3.0) that will be built on top of .NET 10, and designed with trim/AOT as a first class citizen. We're also taking the opportunity to fix a number of known issues (both in terms of perf, binary size, memory use, and usability) that have accumulated in CsWinRT over time. Some of them would require new APIs or changes in .NET (and/or Native AOT), which are all linked here, so it's easier to see all of them at once. We're planning on adopting .NET 10 and CsWinRT 3.0 in the Microsoft Store, as well as in other inbox apps and Windows components.

Note

I'm listing both supporting work for CsWinRT 3.0, as well as general asks from the WinRT side in general (eg. PGO).

Runtime support

• [API Proposal]: "*App*" wildcard for [UnsafeAccessor] assembly name #106216
• [API Proposal]: UnsafeAccessorTypeAttribute for static or private type access #90081
• Interop Type Mapping #110691

ComWrappers and COM generator APIs

• [API Proposal]: Allow the user to provide state for a ComWrappers.GetOrCreateObjectForComInstance operation #113622
• [API Proposal]: 'ComWrappers' methods to get runtime-provided 'IUnknown' CCW vtable entries #114133
• Proposal: allow exception marshallers via '[return: MarshalUsing]' on generated COM interfaces methods without '[PreserveSig]' #109522
• 'ComWrappers.ReleaseObjects' also passes aggregated objects #114043
• Update '[GeneratedComInterface]' to emit ILC-friendly vtables for RVA folding #114468

Native AOT

• Support precompiling CCW vtables in ILC cctor interpreter (Native AOT) #114024
• Support precompiling 'ComInterfaceEntry' vtables in ILC cctor interpreter (Native AOT) #114355
• Support precompiling 'ComInterfaceEntry.IID' fields from RVA span fields in ILC cctor interpreter (Native AOT) #114455
• Support folding feature switch conditions in ILC cctor interpreter (Native AOT) #114499
• Proposal: expose 'IlcDehydrate' as a supported option #112927
• ILC fails to detect and trim some dependency cycles (interface -> attribute -> [DAM] -> type impl -> new()) #112029
• Native AOT: Re-order method bodies using PGO data #114093

Collections (nice to have)

• Make mutable generic collection interfaces implement read-only collection interfaces #31001
• Collection<T> and ObservableCollection<T> do not support ranges #18087

Misc (nice to have)

• [API Proposal]: extend 'Attribute' model for feature APIs for custom feature switches #112969
• [API Proposal]: ConditionalWeakTable<TKey,TValue>.GetOrAdd #89002
• [API Proposal]: ConditionalWeakTable<TKey,TValue>.Remove overload #111925
• [API Proposal]: change 'Unsafe.AsPointer' parameter to be 'ref readonly' #114189
• [GeneratedComInterface] in CCW-only mode produces CA2256 warning #90922
• [API Proposal]: 'ConcurrentDictionary<TKey, TValue>.AlternateLookup<TAlternateKey>.GetOrAdd' overloads #112974

Bugs (CoreCLR/AOT)

• Stack overflow from static constructors taking locks on Native AOT #113949
• Deadlock in loader lock (CoreCLR) from background GC in XAML apps #114182

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[agocke]

It’s probably too late to start an epic for .NET 10. We can probably get some of these in, but some stuff may slip past .NET 10. In general, themes of this size should be discussed around the start of release planning in November.

[Sergio0694]

Yup, that's completely fair. To clarify, we did discuss most of these early on (eg. the type map conversation has been going on for a while, and CsWinRT is not the only consumer), but we didn't think of creating a tracking epic for all these changes before. It's not a problem if not all of these get into .NET 10 (eg. I know we talked about the feature switch analyzer most likely slipping past .NET 10), but hopefully this at least helps to see all related changes in a single place (it certainly helps us with that too) 🙂

[jeromelaban]

Thanks for putting this up, I'll add my concerns about CsWinRT 3.0 on two parts.

As long as cswinrt (or at least the default version) is bundled with the .NET SDK, this will cause a cascade of forced upgrades. For instance, 9.0.200 updated cswinrt, and this required consumer of nuget packages to also upgrade to 9.0.200., if the produced updated its build-time SDK. It is then not clear for developers that this dependency exists when using WinAppSDK, causing all sorts of confusion around why version mismatches happen and where/how to fix them (whether it's a nuget package producer or consumer problem).

If cswinrt stays part of the .NET SDK, adding breaking changes to cswinrt will cause a break in the ecosystem, requiring all the existing nuget packages to upgrade to that newer version. This generally takes a long while to happen.

In short, please don't break any APIs if you keep including cswinrt in the .NET SDK :)

[agocke]

As long as cswinrt (or at least the default version) is bundled with the .NET SDK,

I may be out of the loop here. Is CsWinRT part of the .Windows piece of the SDK? It's definitely not in the core framework...

[Sergio0694]

CsWinRT Is bundled as a targeting pack with the -windows TPM in the .NET SDK. But please let's not go off topic in this issue, this is only meant to track runtime/BCL additions for CsWinRT. We have not shared any exact plans for rolling out CsWinRT 3.0 at all, and it's something that can be discussed in a separate issue in th CsWinRT repo, not here 🙂

[michael-hawker]

CsWinRT Is bundled as a targeting pack with the -windows TPM in the .NET SDK. But please let's not go off topic in this issue, this is only meant to track runtime/BCL additions for CsWinRT. We have not shared any exact plans for rolling out CsWinRT 3.0 at all, and it's something that can be discussed in a separate issue in th CsWinRT repo, not here 🙂

Thanks for the clarification @Sergio0694, will you link to the CsWinRT issue when that gets filed (will that happen soon as work is underway on this project)? It'd be great if it could address some of the concerns raised here in the process.