DEV Community

loading...

The .NET Stacks #49: ๐ŸŒŸ Is reflection really that bad?

Dave Brock
I'm a software engineer, writer, and speaker who focuses on Azure, C#, and .NET.
Originally published at daveabrock.com on ใƒป7 min read

NOTE: This is the web version of my weekly newsletter, which was released on May 15, 2021. To get the issues right away, subscribe at dotnetstacks.com.

Happy Monday! I hope you have a good week. Here's what we have this week:

  • Is reflection still valuable?
  • IdentityServer templates shipping with .NET 6
  • Last week in the .NET world

Is reflection still valuable?

Last Monday, Marc Gravell asked: is the era of reflection-heavy C# libraries at an end? As C# source generators get more popular, developers might be wondering if it might someday replace the idea of reflection (for the unfamiliar, reflection is a way of discovering types at runtime).

Today, unless we're library authors, a lot of reflection is provided to us without us having to care:

This provides a pretty reasonable experience for the consumer; their code just works, and - sure, the library does a lot of work behind the scenes, but the library authors usually invest a decent amount of time into trying to minimize that so you arenโ€™t paying the reflection costs every time.

As the industry has evolved, we've seen how reflection impacts modern applications. For example, we see increased demands on parallel code (async/await), AOT platforms, runtime error discovery, and more. If you're thinking of the cloud, runtime performance matters (especially if you're paying for serverless and execution times).

Marc states:

Imagine you could take your reflection-based analysis code, and inject it way earlier - in the build pipe, so when your library consumer is building their code ... you get given the compilerโ€™s view of the code ... and at that point you had the chance to add your own code ... and have our additional code included in the build ... This solves most of the problems weโ€™ve discussed.

This doesn't mean reflection doesn't have its use cases, and it's so pervasive in the .NET ecosystem it isn't going anywhere anytime soon. Source generators are great for resolving performance headaches with certain reflection use cases like with GetTypes(). Should we go all-in on source generators, though? Is it worth moving code into a user's app and build processes over developers enjoying the separation?

Here's another consideration: is reflection just getting a bad rap? It can be slow for sure, but the .NET team has noted that performance is improving, and there's a prototype they're working on making 10x faster.

It'll be interesting to see how far the .NET platform pushes on source generators over improving reflection performance. I'm guessing we'll see a little in Column A and a little in Column B. Everything is a tradeoff. Still, it's promising to see source generators shake up decades of thinking reflection is the only way to inspect types dynamically.

IdentityServer templates shipping with .NET 6

Last December, IdentityServer introduced a licensing model (and we talked about it back in issue #20). You'll need to buy a license if your organization makes more than 1M USD/year (I know I have a global audience but believe me, you don't want me converting currency).

This week, Barry Dorrans announced that .NET 6 will continue to ship these templates (using the new RPL-licensed version). I personally applaud Microsoft's decision to continue to support IdentityServer, which is getting pushback from the blog's comments and a super-spicy GitHub issue. A lot of the pushback comes from folks accusing IdentityServer of a "bait and switch"โ€”as if profiting off free open-source software for a decade wasn't enoughโ€”and that Microsoft should build it themselves.

As Microsoft has said a bunch of times, and bears repeating:

As stated we are not authentication experts, we have no expertise in writing or maintaining an authentication server. We have a team at Microsoft dedicated to that, and they produce AAD. The .NET team will not be writing production ready authentication servers, both because of the cost in that and because in doing so it's likely we'll cannibalize users from existing open source projects, something the community was very vocal in wanting us not to do when the initial discussions around IdentityServer inclusion was started.


๐ŸŒŽ Last week in the .NET world

We have a lot of great community posts this week.

๐Ÿ”ฅ The Top 4

๐Ÿ“… Community and events

๐Ÿ•ธ Web development

๐Ÿฅ… The .NET platform

โ›… The cloud

๐Ÿ“” Languages

๐Ÿ”ง Tools

๐Ÿ“ฑ Xamarin

๐Ÿ— Design, testing, and best practices

๐ŸŽค Podcasts

๐ŸŽฅ Videos

Discussion (0)