[API Proposal]: trim-safe RuntimeHelpers.RunClassConstructor(Type) overload

[Sergio0694]

Background and motivation

In the XAML compiler, when targeting modern .NET, we need to invoke RuntimeHelpers.RunClassConstructor to make sure that the static constructor for a given type is initialized before some other code runs. Most scenarios for this revolve around dependency properties, which in some cases need to be initialized and registered in the WinRT runtime before some other code runs (eg. before the activation factory for a given type is retrieved). To make this trim-safe, the lifted XAML compiler was updated with a bunch of [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicConstructors)] annotations on all such types, and a suppression on the method calling RuntimeHelpers.RunClassConstructor with these types.

You can see the use in the XAML compiler here.

However, talking with @agocke and @SingleAccretion today, they pointed out that this pattern is not supported, and it's not guaranteed to work. So this proposal is for a safe, annotated overload of the same method, taking a Type instance instead.

API Proposal

 namespace System.Diagnostics.CodeAnalysis
 {
     public enum DynamicallyAccessedMemberTypes
     {
+        StaticConstructor = 0x4000,
     }
 }

 namespace System.Runtime.CompilerServices
 {
     public static partial class RuntimeHelpers
     {
+        public static void RunClassConstructor([DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.StaticConstructor)] Type type);
     }
 }

API Usage

[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.StaticConstructor)]
public Type UnderlyingType => _underlyingType;

private void RunInitializerImplementation()
{
    RuntimeHelpers.RunClassConstructor(UnderlyingType.TypeHandle);
}

[dotnet-policy-service]

Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @sbomer, @joperezr, @marek-safar
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

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

[teo-tsirpanis]

This new DynamicallyAccessedMemberTypes value will essentially have only this use case. Could instead the trimmer just always preserve the class constructors of all preserved types? How wasteful would it be?

[agocke]

@sbomer and @MichalStrehovsky for review

[jkotas]

In the XAML compiler, when targeting modern .NET, we need to invoke RuntimeHelpers.RunClassConstructor to make sure that the static constructor for a given type is initialized before some other code runs.

Can you make it explicit by introducing static void Initialize() method on the types that you need to run the static constructors for?

Static constructors are meant to be internal type implementation details. It is an anti-pattern to use them as part of the public type contract.

[Sergio0694]

I think I remember asking the same a while back and was told that doing so wasn't possible, but I can't recall the exact reason right now (cc. @manodasanW do you remember?). I know at the very least there was a concern about the fact that the type might often be beforefieldinit, because it might just have a bunch of static readonly fields for dependency properties, in which case calling Initialize() wouldn't actually cause them to be initialized, right? Ie.:

public sealed class MyControl : UserControl
{
    public static readonly DependencyProperty FooProperty = DependencyProperty.Register(
        "Foo",
        typeof(int),
        typeof(MyControl),
        null);
}

[jkotas]

You can either generate explicit constructor or you can do a dummy access of one of the static fields in the Initialize method.

public sealed class MyControl : UserControl
{
    public static readonly DependencyProperty FooProperty = DependencyProperty.Register(
        "Foo",
        typeof(int),
        typeof(MyControl),
        null);

    static MyControl()
    {
    }

    public static void Initialize()
    {
    }
}

[MichalStrehovsky]

How does this work for:

public class ControlBase : UserControl
{
    public static readonly DependencyProperty FooProperty = DependencyProperty.Register(
        "Foo",
        typeof(int),
        typeof(MyControl),
        null);
}

public class ControlDerived : ControlBase { }

Does XAML recurse from ControlDerived and call RunClassConstructor on ControlBase? (Because RunClassConstructor on ControlDerived will not run the base cctor.) If so, the proposed extension would likely not help. I would not expect it to keep things recursively.

---

That said, keeping cctor on a single type should be achievable with the existing API surface, it's just a trimming/AOT mini-feature. DynamicallyAccessedMemberKinds.NonPublicConstructor already includes the static constructor (because that's how reflection APIs are structured as well).

using System.Diagnostics.CodeAnalysis;
using System.Runtime.CompilerServices;

Run(typeof(Foo));

static void Run([DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.NonPublicConstructors)] Type t)
{
    Console.WriteLine(t.GetConstructor(System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Static, []));
    RuntimeHelpers.RunClassConstructor(t.TypeHandle);
}

class Foo
{
    static int i = Init();
    private static int Init()
    {
        Console.WriteLine("Hello");
        return 42;
    }
}

This will print

Void .cctor()
Hello

in a trimmed app but there's a trimming warning. The trimming warning should be fixable (was briefly discussed in dotnet/linker#1121 (comment)).

There's a gotcha however. In native AOT, the static constructor is reflection-visible, but not runnable. So the above program would print:

Void .cctor()

As part of fixing the trimming warning, we'd need to fix this up too (either drop the "static constructor is reflection-visible but not Invoke()-able" blocking and introduce the "I can run the cctor how many times I like" footgun to native AOT as well, or do something else so that RunClassConstructor works.

[Sergio0694]

"Does XAML recurse from ControlDerived and call RunClassConstructor on ControlBase?"

XAML will track all types, including base types, though I can't say what the exact logic it uses to trigger those constructors is off the top of my head. @manodasanW do you know by any chance if it'll take care of invoking base constructors too?

"In native AOT, the static constructor is reflection-visible, but not runnable."

This... Is the part that I find the most interesting. Just to triple check I'm reading this correctly, are you saying that no RuntimeHelpers.RunClassConstructor call will ever do anything on NativeAOT? Because if so... We do have several WinUI 3 apps running on NativeAOT, like the WinUI Gallery App, and as far as I know there's no reported issues around eg. dependency properties not working. So if it is in fact the case that none of those calls are actually doing anything on NativeAOT, this kinda makes me question whether it is even true that this is actually needed in the first place. I mean something doesn't add up 🤔

[MichalStrehovsky]

This... Is the part that I find the most interesting. Just to triple check I'm reading this correctly, are you saying that no RuntimeHelpers.RunClassConstructor call will ever do anything on NativeAOT

RuntimeHelpers.RunClassConstructor is not implemented on top of reflection. It will work as long as you don't see static analysis warnings.

What doesn't work is calling t.GetConstructor(System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Static, [])).Invoke(null, []). That one never worked starting from .NET Native.

[MichalStrehovsky]

It will work as long as you don't see static analysis warnings.

(Suppressing the warning doesn't make it magically work. The suppression in XAML is invalid, including for PublishTrimmed. I rarely see a valid suppression in code outside dotnet/runtime repo. It's pretty much always a bug.)