Avoid System.Private.CoreLib Reference from .NET Core 3.1 Process Runner

[OwlchemyDawson]

What is the best way to avoid having Mono.Cecil add a reference to the System.Private.CoreLib assembly when the external process executing my IL modification code (outside my control) was upgraded to target .NET Core 3.1? Alternatively, is there a way within my IL modification code to properly remove the System.Private.CoreLib reference and fix-up any usage to point to mscorlib instead?

Background:
I have a custom ILPostProcessor assembly that functions properly in Unity 2020.3 with a Unity project that is using .NET Framework API compatibility. The ILPostProcessor is executed by the Unity ILPostProcessorRunner.exe against all assemblies in the project and each assembly is built against .NET Framework 4.0. However, when upgrading the same project to Unity 2021.3 Mono.Cecil adds a reference to System.Private.CoreLib to all modified assemblies.

In debugging the issue I have found the root cause to be that ILPostProcessRunner.exe was changed from targeting .NET Core 2.0 to .NET Core 3.1 between Unity 2020.3 and 2021.3. With the ILPostProcessorRunner change, imports of anything that references types like System.Void (i.e. a method return type) now point to System.Private.CoreLib rather than mscorlib as they did with the Unity 2020.3 ILPostProcessorRunner.exe; this is of course the case even though the assemblies being processed are still built against .NET Framework 4.0. This poses an issue in Mono.Cecil.DefaultReflectionImporter.ImportMethod (Import.cs at line 397) when, for example, importing the constructor of an Attribute class since this will force Mono.Cecil to add the System.Private.CoreLib reference due to the System.Void return type and it all seems to be outside my control.

As an example, the Attribute class constructor import line is as follows:

assemblyMainModule.ImportReference(typeof(CustomILProcessedAttribute).GetConstructors().First())

Debugging my IL Weaver code run via Unity 2020.3 verses Unity 2021.3 clearly shows the issue even external to any Mono.Cecil calls as the assembly qualified name for System.Void for a 2020.3 run is in mscorelib where it is in System.Private.CoreLib for a 2021.3 run.

Also, I did test code to remove the System.Private.CoreLib reference after all modifications are complete but that caused a TypeLoadException for System.Action`3 that I could not figure out; mscorlib of course remains referenced in all cases.

[ltrzesniewski]

When you use ImportReference with a parameter type like System.Type or anything from System.Reflection, you will inject a reference to the assembly where that type/field/method is defined, which means you'll add a dependency on the runtime used to execute the code that uses Mono.Cecil.

Use an ImportReference overload which uses a parameter type defined by Cecil (TypeReference, MethodReference etc). Make sure to get these references from the target environment, not from the environment which executes your Mono.Cecil code. For instance, use ModuleDefinition.TypeSystem for system types, and references from resolved assemblies for custom types.

[OwlchemyDawson]

Thanks for the response, @ltrzesniewski.

Unfortunately, I am new to Mono.Cecil and was pretty naïve in the implementation of my ILPostProcessor so I used ModuleDefinition.ImportReference with System.Type a bunch. This has me looking at a decent amount of rework before I can complete the Unity 2021 upgrade. However, I implemented a horrible hack last night where I write out the modified Assembly to memory so it builds out the full type reference table then I reload that in-memory assembly, fix-up all of the type references with a scope to System.Private.CoreLib so they point to mscorlib instead, remove the System.Private.CoreLib reference, and finally write out the final modified assembly. This should work as a stop-gap hack and allow me to complete the upgrade (pending a bunch of testing) while I work through fixing up the ILPostProcessor to use Mono.Cecil in a better way.

I am curious if there are helper methods I may be missing to take things like a System.Type or System.Reflection.ConstructorInfo and properly convert them to a Mono.Cecil type?

[ltrzesniewski]

I am curious if there are helper methods I may be missing to take things like a System.Type or System.Reflection.ConstructorInfo and properly convert them to a Mono.Cecil type?

These helper methods are the ones you're using. 🙂

I suppose this wasn't a problem in the early days when the only available runtime library was mscorlib - both the loaded assembly and the code running Cecil targeted the same runtime. It became an issue when other runtimes showed up, and the helper methods became a trap (maybe I'm wrong, but that's my understanding).

And in the general case, it's not straightforward to convert runtime types back to metadata types. For instance, on .NET Core, you are supposed to use reference assemblies (like System.Runtime), but those are mapped to other assemblies at runtime (like System.Private.CoreLib) via the type forwarding system. That's why, in order to do things properly, you need to load the reference assemblies of your SDK in Cecil, and use those.

It's a bit of a mess, and you need to be really careful when using Cecil because of that.

[Zastai]

The helper methods are great for the use case where you're generating an assembly from scratch (e.g. "compile" a script to code before running that code), for your own later use.

But when IL weaving you do indeed need to be very careful about where you get (new) types from. For core types, module.TypeSystem is great. Anything else: beware. If you're post-processing something that will always already have a reference to an assembly that's under your control, then a useful approach is to add helper types/methods there so that you're mostly just adding references to things that are already available in a properly resolved assembly (correct system library, no clashes between (transitive) dependencies, etc.)