Is Mono.Cecil strictly compatible with AOT / trimming?

[josephmoresena]

I’ve happily used Mono.Cecil for quite some time, including in projects that compile with NativeAOT, and I was pleasantly surprised to find that it is fairly usable (at least for workflows that involve editing external assemblies IL).

I validated this by running into several trimming warnings and a few errors, which I was able to resolve either by suppressing trimming warnings or by preserving certain types from being trimmed (for example, Mono.Collections<>). Overall, the experience has been positive.

Because of this, I think it might be worth documenting and explicitly constraining how Mono.Cecil can be used in NativeAOT scenarios.

Based on the warnings and errors I encountered, I believe that the basic "external assembly IL edition" feature produces a trimming false positive related to the debug symbol provider load. This could potentially be addressed by adding unconditional suppression annotations internally (since the public attributes are only available starting with .NET 5.0), and by statically allowing the loading of the symbol providers implemented across the different Mono.Cecil assemblies. I’m not sure which of those providers are or are not AOT-compatible.

There are also other modules that I believe are inherently incompatible with AOT, such as ImportReference, which requires the executing IL assembly to be available at runtime (something that does not exist under AOT).

Would it be worthwhile to set up Mono.Cecil for these scenarios and document the limitations of certain APIs when used in AOT/trimming contexts?