This post is the second part of a 2 posts long series, discussing inlining in relation to DCE and exception handling.
This post is about code inlinig by the JIT compiler and Dead Code Elimination (DCE).
Code Inline: call of the method at the callsite is replaced with the invoked method body.
DCE: Modern compilers are smart enough to detect code segments, that has no effects, hence they can be removed.
This post is the first part of a 2 posts long series, discussing code inlining in relation to DCE and recursive methods.
Code Inline: call of the method at the callsite is replaced with the invoked method body.
DCE: Modern compilers are smart enough to detect code segments, that has no effects, hence they can be removed.
I will walk to through two examples showing these compiler features in action in regards to exception handling and recursive methods. At this point, I expect the reader to have a good understanding on both of the above compiler features.
In the .NET Core era, more-and-more existing .NET applications are getting updated to the new technology stack. Using netstandard libraries the upgrade is relatively simple. On the other hand, using non standard libraries may cause issues. One of the libraries that is not netstandard is Rhino Mocks. Rhino Mocks is used for mocking test dependency behavior. Unfortunately it is not .NET Core compatible, so using Rhino Mocks in tests is blocker to moving along with the .net core stack.
We can do 2 things to overcome such an issue:
Update Rhino Mocks by making it .NET Core compatible
Move away from Rhino mocks to other mocking libraries
The first point should be an obvious choice, but as it turns out, there are multiple repos for Rhino Mocks, and none of them seems to be the "true" source and none of them seems to be maintained either. That leaves with the second choice.
NDepend's 2020 release has a new Dependency Graph view. I am keen to try it out, and I just have the prefect project for the test. In this post I will use the Dependency Graph view on one of my most 'messy' projects. The project is started as a Proof Of Concept (POC), then I based 3 other Proof Of Concept apps on it.
This made all namespaces, dependencies and responsibilities mixed. The Visual Studio solution consists of three projects. An ASP.NET Core project of the chatbot implementation, an Azure Functions project for managing IoT devices and a shared library project common types.
NDepend has a VS Extension, which streamlines work a lot, but at the same time it also has standalone executable, which does not require installation. I like these apps, because I can just drop them to my \tools folder and use them as needed. Once I notice that I use an app extensively for a period of time, I can install the VS Extension.
This blog post demonstrates distributed tracing for gRPC calls using OpenTelemetry. Application Insights and Zipkin exporters and services are used for visualizing spans.
gRPC is http based protocol. The client uses HttpClient to send requests, while the ASP.NET Core service is using standard HTTP pipeline to process requests and return responses. Both HttpClient and the HTTP pipeline are instrumented with System.Daignostics.DiagnosticListener. DiagnosticListener enables to subscribe to emitted events and activities. While events indicate a point in time notification, activities can describe a time interval. Both may use additional metadata attributes to describe the event or the time span.
For the collection of these events, I am going to use OpenTelemetry's C# client, version 0.2.0-alpha.179 at the time of writing this post.
In this post, I will have a .net core console application as the client and an ASP.NET Core 3.1 service as the server.
