Move to System.Reflection.Metadata

[agocke]

There are a couple reasons this is important:

1. SRM is the platform the C# compiler uses as its emit backend, meaning if C# emits any new IL patterns, they are guaranteed to be present in SRM immediately
2. SRM has a matching servicing lifetime to each trimmer release
3. SRM doesn't require a detailed object model, is immutable, and could significantly improve performance

[jkoritzinsky]

System.Reflection.MetadataLoadContext might also be interesting here if it's still desirable to have a more detailed object model for reflection analysis.

[am11]

From what we are moving to SRM, Cecil?

[mateoatr]

From what we are moving from to SRM, Cecil?

Yep

[agocke]

Yup away from Cecil. Another good candidate, built on top of srm, is the native aot managed type system. Native aot already has linker analysis so there's probably a lot of potential sharing.

[MichalStrehovsky]

The managed type system that we use in crossgen2, ILVerify, and the NativeAOT compiler provides a lot of niceties that can be useful for analysis such as virtual method resolution (which both Cecil and MetadataLoadContext lack - forcing IL Linker to roll its own scary version of it). It interops well with System.Reflection.Metadata (can hydrate type system entities out of SRM entity handles and provides back MetadataReaders and handles for things it represents). It's also threadsafe, lockfree (for readers), and tuned for high performance.

[marek-safar]

Just to be clear this is post-net6 work proposal, right?

We have discussed this in the past and there were two areas of work that we thought should happen first

• Simplify existing custom steps to allow smoother migration
• Better support for debug symbols in SRM (native PDB and automatic symbol updating for method bodies were the primary concerns if I remember it correctly)

[agocke]

Yup that's why I created the "Future" milestone for post .NET 6.

Given that native PDBs aren't supported xplat, I'm not sure why native PDBs were a blocker for us.