A module initializer will not be triggered when accessing a forwarded type

[DaZombieKiller]

This is a problem I encountered while investigating mitigations for #60573.

Imagine that we have Library, which contains a number of structures for interop. However, the native structures have differing packing for certain platforms.

To work around this, I split the project up as follows:

• Library
  • Contains Library.Platform.Windows and Library.Platform.Unix as embedded resources.
  • Contains a module initializer that subscribes to AppDomain.Current.AssemblyResolve to load the appropriate platform assembly.
  • Contains type forwarders pointing to Library.Platform.
• Library.Platform
  • Serves as a reference assembly for Library to compile against.
  • Contains all of the types that were originally in Library.
• Library.Ref
  • Contains all of the same code as Library and Library.Platform combined.
  • Is only compiled as a reference assembly.
  • The AssemblyName is set to Library.
• Library.Platform.Windows
  • Contains all of the same code as Library.Platform, but compiled with the WINDOWS define active.
  • The AssemblyName is set to Library.Platform.
• Library.Platform.Unix
  • Contains all of the same code as Library.Platform, but compiled with the UNIX define active.
  • The AssemblyName is set to Library.Platform.

A program would then compile against Library.Ref, but load Library. However, whenever an attempt is made to access one of the types, the program will throw a FileNotFoundException for Library.Platform due to the module initializer not being called when accessing forwarded types.

Is there any way to ensure that the module initializer is invoked in this situation without manual intervention from the API consumer? Or would it be possible to change the behaviour of module initializers to also run for forwarded types?

Workarounds

This can be worked around by exposing an empty static method on Library that consumers are required to call before accessing anything else, but this is certainly not an ideal solution.

I've also considered writing a C# source generator that emits the following into a consuming project:

[ModuleInitializer]
internal static void EnsureLibraryInitialized()
{
    Library.EnsureInitialized();
}

But naturally this would only work for C#.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkotas]

Module initializers are not triggered by referencing a type. They are only triggered by accessing a method or a static field. This is documented in https://github.com/dotnet/runtime/blob/main/docs/design/specs/Ecma-335-Augments.md#module-initializer

[DaZombieKiller]

I see. I suppose the workarounds I listed are probably the only options currently available then?

[jkotas]

The solutions that we use in dotnet/runtime in these situations are either:

• Package the whole library as platform-specific. Example: https://github.com/dotnet/runtime/blob/main/src/libraries/System.IO.Ports/src/System.IO.Ports.csproj#L3
• Compile the struct definitions with different alignment into same library and switch dynamically at runtime. Example:

  runtime/src/libraries/System.Data.OleDb/src/OleDbStruct.cs

  Line 574 in 691cf0f

  ODB.IsRunningOnX86 ? (ItagDBPROPINFO)new tagDBPROPINFO_x86() : new tagDBPROPINFO();

I would not recommend the embedded resource trick. It is not compatible with trimming and AOT.

[DaZombieKiller]

I had originally attempted the first approach, though due to the library needing to target netstandard2.1 I was unable to take advantage of the -windows, -Unix, etc TargetFramework suffixes (netstandard2.1-windows doesn't error, but the -windows portion is ignored. I looked into the SDK and it seems this is only supported for net5.0 and newer).

The second approach would unfortunately be a huge amount of code and complexity for this case, especially since these types are supposed to be publicly exposed.

The trimming and AOT concerns are good points, I had only intended to use this trick in JIT scenarios but being unable to trim is still not ideal.