or subscribe with
Join 20,200+ readers for one email each week.
Digests » 342
this week's favorite
.NET 5.0 was released recently and has come with many new features and performance improvements. System.Text.Json is no exception. We have improved performance, reliability, and made it easier to adopt for people who are familiar with Newtonsoft.Json. In this post, I’m going to talk about the progress that has been made with System.Text.Json, and what’s going to come next.
How many times have you been in the debugger tracking down a bug, stepping through code, looking at what local variable values changed, when you hit a wall — the value isn’t what you expected, and you can’t step into the method that produced it because it’s from a library or .NET framework itself? Or you set a conditional breakpoint waiting to examine how some value got set, then noticing a call stack that’s mostly greyed out, not letting you see what happened earlier in the call stack? Wouldn’t it be great if you could easily step into, set breakpoints, and use all the debugger’s features on NuGet dependencies or the framework itself?
Virtual stub dispatching (VSD) is the technique of using stubs for virtual method invocations instead of the traditional virtual method table. In the past, interface dispatch required that interfaces had process-unique identifiers, and that every loaded interface was added to a global interface virtual table map. This requirement meant that all interfaces and all classes that implemented interfaces had to be restored at runtime in NGEN scenarios, causing significant startup working set increases. The motivation for stub dispatching was to eliminate much of the related working set, as well as distribute the remaining work throughout the lifetime of the process.
What the heck is a code analyzer? Well if you are a Visual Studio user you probably have seen the lightbulbs and wrenches from time to time. Put it simply in my own terms, code analyzers keep an eye on your code and find errors, suggest different ways of doing things, help you know what you aren’t using, etc. Usually coupled with a code fix, an analyzer alerts you to an opportunity and a code fix can be applied to remedy that opportunity.
Using OpenTelemetry SDK gives you more flexibility, offering integration with multiple monitoring backends. You can explore and understand the APIs and concepts of it. Using in the production will take some time till the packages are in a stable state. OpenTelemetry’s .NET packages are in beta state and the APIs will be subject to change.