or subscribe with
Join 20,200+ readers for one email each week.
Digests » 408
this week's favorite
As you move towards .NET 6, you also get new opportunities to upgrade legacy codebases to the latest and greatest. Unfortunately, updating a legacy codebase can be nerve-racking. Luckily, in this post, I wanted to share a technique I recently discovered that allows you to alter the behavior of static classes without changing the surface API of a legacy codebase. Of course, this approach has its limits, but I think it’s a valuable technique to have in your toolkit.
Decompilation is a great way to get a feel for the shape of an API that you’re referencing, but it does have some downsides, the biggest of which is that a decompilation can only be created from the IL that is in the referenced DLL.
The release of .NET 6 came with a with of minimal api’s which enable the development of small and functional single file Web API’s.
At some point, I started to feel discomfort working with personally identifiable information data in our project. Mostly, because it is a relatively new field and not always straightforward. In this article, I’m going to try to tackle the main issues and make the implicit explicit.
By default, classes are not sealed. This means that you can inherit from them. I think this is not the right default. Indeed, unless a class is designed to be inherited from, it should be sealed. You can still remove the sealed modifier later if there is a need. In addition to not be the best default, it has performance implications. Indeed, when a class is sealed the JIT can apply optimizations and slightly improve the performance of the application.