A new way of doing reflection with .NET 8

[giscus[bot]]

A new way of doing reflection with .NET 8

.NET 8 introduced a new way of doing reflection. Why did they introduce this, and what are some benefits - this blog post will give you some insights.

https://steven-giesel.com/blogPost/05ecdd16-8dc4-490f-b1cf-780c994346a4

[ghadzhigeorgiev]

Just a minor typo in:

GetCountField(counter) = 100);

[linkdotnet]

Hupps - yes, absolutely. Thanks for reporting. Fixed!

[puschie286]

looks promising - much cleaner than the reflection chain.
For performance, you would create a delegate once and reuse it (would be great to see it in the comparison). But it’s definitely more complex and require setup at the gain of dynamic usage (can be used with generics).

[linkdotnet]

That's true - also directly emitting IL might be fast - in all of those cases, we would see roughly the same execution time (if we keep out the creation of those delegates out of the equation).

[richardhauer]

How would one define these methods against types that are private or internal to assemblies not in our control? I would say that's the most common use-case for reflection for me.

[linkdotnet]

Currently (with .NET 8) that isn't possible and is planned for .NET 9: dotnet/runtime#90081

[maiorfi]

Maybe I'm missing the point, but "old way" makes it possible to defer the choice of what property/field to access at runtime, while the "new one" requires moving such choice at build-time. Shouldn't reflection be a way to write late-binding code?

[linkdotnet]

Depends on your use case - yes and no. The "new one" allows you to construct compile-time constructs. That for sure wouldn't cover scenarios where you want to iterate through an object to set all properties to a certain value.

[stevehansen]

and don't forget that source generators can also fill this gap, exactly how System.Text.Json uses/will use it

[JustDre]

Usually there be demons when using types whose names start with "Unsafe".

[andreiFC]

So reflection lets you access a private variable from outside the Counter class, and alter this variable, which is supposed to be readonly. This seems to me a huge design/security flaw. I mean, what good is encapsulation if anyone can access a hidden variable? What good is readonly if anyone can alter its value?

[linkdotnet]

To be fair, you could do this since the beginning of .NET. The team introduced a new way if you need ahead of time about what calls you need. And yes, that defeats to some extent the design (private, protected and friends), I am on your side.

But it should be the last resort anyway (that is why it's called UnsafeAccessorAttribute).