AOT with Reflection

[dotnetcadet]

Scenerio:
With the recent .NET 8 release I've been working to make some of my libraries AOT compliant, and I wanted to get some clarification on the use of reflection. The analyzers that come with .NET 8 are giving me a lot of warnings on methods such as typeof(T).GetProperty(string name), typeof(T).GetConstructor(Type.EmptyTypes), Activator.CreateInstance(), etc.,

In most of my use-cases the types are known at build-time, and I don't expect any users to be loading types with APIs such as Assembly.Load...()

Questions:
Is it safe to assume that if the type I am accessing is known at build time, then no exception will be thrown when accessing type information or generating instances dynamically?

And if that is the case, is disabling those warning wise?

[HighPerfDotNet]

I've been working for the last few weeks on making our codebase work with Native AOT and had to deal with reflection issues. Key problem is that data gets trimmed, to deal with some of those cases I had to do the following bit in code:

        StringBuilder oSB=new StringBuilder();
        oSB.AppendFormat("Anti-trim stuff: {0}",new ClassThatWasGettingTrimmed().GetHashCode());

Also, you can use the following in project file in order to prevent trimmer from cutting too much -

Relection seems to work as long as types were not trimmed away.

[vitek-karas]

This is why we created the analyzers and diagnostics into the compilers which produce warnings in places where the tooling can't guarantee correctness. Manually referencing code which is needed might work, but it tends to be very fragile and it's almost impossible to guarantee that the app will not fail at runtime. If at all possible, I would recommend using the warnings and related annotations to modify the code such that any reflection usage can be understood by the tools. See https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/prepare-libraries-for-trimming?pivots=dotnet-8-0#unconditionalsuppressmessage for more details.

[vitek-karas]

It's actually not true that generic parameters are always known at compile time. Code can call for example typeof(List<>).MakeGenericType(Console.ReadLine()) in which case the generic parameter is not known statically. But also, early on we decided against doing automatic propagation of types across method boundaries because if there are problems which would need to be reported to the user, the experience around it can be really bad (if you ever worked with templates in C++, you are probably familiar with the really complex errors you can get from the compiler, this would be similar and some cases even worse).

For this (and other reasons) the tooling requires you to annotate the types (either generic parameters, or System.Type parameters) with annotations which describe what reflection requirements are imposed on it. It doesn't solve all the problems (MakeGenericType still won't work, but at least you might get a better warning for it), but it solves most of those which can be resolved statically.

For example:

IEnumerable<string> GetPropertyNames<[DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.PublicProperties)] T>()
{
    return typeof(T).GetProperties().Select(p => p.Name);
}

More details are described here: https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/prepare-libraries-for-trimming?pivots=dotnet-8-0#dynamicallyaccessedmembers. The samples in that article are about System.Type parameters, but the same thing applies to generic parameters.

The warnings produced by the tools will let you know what requirements (DynamicallyAccessedMemberTypes) each of the APIs need.

And if that is the case, is disabling those warning wise?

Disabling these warnings is absolutely not recommended. In lot of cases the tooling is not clever enough to figure it out without the annotations mentioned above and the code could fail at runtime.

As mentioned here: https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/prepare-libraries-for-trimming?pivots=dotnet-8-0#unconditionalsuppressmessage, suppressing warnings should be only considered as the last resort and you need to be very careful about it. (Trust me, we got it wrong ourselves so many times, that now we're basically trying to avoid it at any cost).

[dotnetcadet]

@vitek-karas Thank you for the documentation. That was very helpful. I had a couple more questions regarding the information you provided.

1. In terms of typeof(T<>).MakeGenericType() API I completely understand. However, how does the JsonSerializer in System.Text.Json get around the following scenario when deserializing JSON. From what I understand JsonSerializer is AOT compatible so how does it determine what type to use at compile time and not utilize the following API: typeof(List<>).MakeGenericType(typeof(Child)) ?

public class Parent {
    public IEnumerable<Child> Children { get; set; }
}

public class Child {
    public string? Property1 { get; set; }
}

2. How does the DynamicallyAccessedMembersAttribute tell the compiler what types not to trim? I feel like you would have to walk each code path at compile time to determine which type is being access dynamically.

3. Also, is RTTI (Runtime Type Information) maintained in AOT compilation?

[davidfowl]

1. It doesn't. That's why only the source generator is AOT compatible.

[dotnetcadet]

Oh yea., I'm an idiot lol 🤦. I completely forgot about that

[vitek-karas]

2. The tooling works on a single method at a time. Within the method the rules are pretty simple. If you're calling a method which has DynamicallyAccessedMembers on one of its parameters, you have to:

• Pass a statically known type - so something like a typeof(Foo) - in this case the tooling will go "Ah, so Foo needs all the methods, because the annotation says so - so I'll keep all methods on Foo (and make then accessible via reflection)".
• Pass a variable which has the same or "bigger" annotation
  This means that it forces you to "bubble up" the annotations (DynamicallyAccessedMembers attributes) up the call stack. Eventually you have to reach a point where the type is statically known. The main point is that we need the developers to annotate this "callstack path", the compiler is not trying to figure it out on its own.

3. Not sure what you mean by RTTI in the context of .NET AOT - the runtime keeps enough information around so that on any object you can call object.GetType() and you will get back a type with a name and some other basic information. If you need more (like enumerating methods on the type) then the reflection call to do that has the DynamicallyAccessedMembers annotation (for example Type.GetMethods has it). That annotation will either produce a warning, or it will make sure that the types you are asking for methods on will have the methods preserved. Note though that there's a difference between "the method is in the app" and "the method can be accessed via reflection". Most methods in the app have code, but are not accessible via reflection - the annotations tell the tooling not only to keep the method, but also to keep enough information around so that it is accessible through reflection.