Forem: Alexander Johnston

On Building Communities

Alexander Johnston — Fri, 10 Apr 2020 19:08:33 +0000

Here at DealerOn we have a special kind of environment of enabling each other to pursue our interests and contribute to the effort in a personal way. Part of that is shown through the numerous blog articles written here; each one done by a volunteer and the topics left completely open-ended for us to explore what we think is worth sharing. This principle extends into all our activities from internal hackathons, events, and even the way we share ideas with each other. There is a sense of community involvement which extends past the work itself and drives us.

I first encountered C# early on in 2002 when it was still not even a year old as an official language. I was new to programming but my questions were taken seriously by helpful members of the community. Those moments of helpfulness are what stuck with me throughout my time with the language and I’ve seen the development community around it grow into the great ecosystem that it is today. While this isn’t unique to the .NET, it is an important quality in building a diverse platform.

Along the way I have been lucky to be mentored by many of these talented individuals who are passionate about sharing their work for other people to use. The idea of being able to build tools for other people to use is what caught my interest and ultimately pushed me down a path to learning more. Despite this, it would still take me at least ten years to learn how to develop any original software in C#. The barriers to entry were too high early on and I never stumbled upon the right resources.

Today, I see whole libraries of videos done by professionals and curated by sites like Pluralsight; there are numerous high quality guides for getting started on the Microsoft docs and blogs themselves; and even YouTube and social media sites like Reddit are now seeing thriving communities for learning how to develop. We have also seen a surge in cooperative development tools. Today I can use Live Share to connect with someone working on a cross-platform app without even leaving the IDE. I can watch them deploy that app to the cloud with a couple clicks and see it automatically provision a server in real time.

With all of these new tools and the lower barriers to entry, I have seen the community come out in force to support learning opportunities. There are now innumerable IRC servers, Discord servers, forums, and other groups out there spending their time mentoring juniors on open-source projects. Not to mention that .NET Core now runs cross-platform, so we can collaborate with users of other operating systems. All of this means more libraries being built, better tutorials being written, with greater access to teachers for those who are new to programming.

The future looks good for the .NET community and Microsoft has clearly been invested in supporting it. Later this year .NET 5 will launch and with it we will all surely have new API surfaces to learn; there will be the usual issues with assemblies and broken references. NuGet packages will need to be updated. StackOverflow will be full of weird issues that everyone keeps running into as they try to migrate their apps. Despite the growing pains, it is up to everyone to help each other out. It’s only through the collective effort of trying, failing, researching, and sharing that we all contribute our shared success.

This has all been a long winded way to say that in a sense, building a community is about investing in individuals. It is not an easy task to build an environment where learning is the default and where failure is seen as an opportunity to improve. I believe that in many ways this philosophy exists at DealerOn and is influenced heavily by the larger .NET community. It’s important that we always ask ourselves how we can give back to the community and how we can make things easier for the next team who comes along. Thanks for listening.

Exception Handling and Telemetry with PostSharp, Application Insights, and Grafana

Alexander Johnston — Fri, 07 Jun 2019 13:01:01 +0000

PostSharp is a pattern-aware extension for C# which runs during the compilation stage.

Whether you’re just getting started with .NET or have been using it for its lifetime, there are concerns every project has to face eventually. In a previous article, I discussed how PostSharp can be used to target concerns like logging and threading. Today, I will show you how we can apply these same principles to exception handling to send real-time telemetry to Application Insights.

Remarks

Exception handling is a topic with depth far beyond the scope of this article. The code I reference here is not designed to be as fast or as efficient as possible. This is in the interest of showcasing each of the features and creating a usable demonstration which readers can then improve upon for their own purposes. You are always welcome to get in contact with me for clarification or advice on these topics; I also welcome you to point out errors, mistakes, or even make pull-requests to the repository as you see fit.

My goal is to explore .NET Core cross-platform capabilities and show you how Exception Handling can be integrated with the following tools:

· .NET Generic Host is an all-in-one package for handling configuration, dependency injection, logging, and other app startup concerns. If you want to host async services, then you can do it out of the box now with very little setup time. For us it will simplify a lot of the boilerplate needed to prototype interesting AOP use-cases.

· Azure Application Insights is a big suite of services which focus on monitoring performance in real-time. You can send events, metrics, and all sorts off custom measurements up to Azure and then immediately query it through Log Analytics. The goal here will be to handle our exceptions by logging them up in the cloud where we can get regular snapshots of the application’s state.

· Grafana is a wonderful, open-source tool for creating dashboards which track metrics or visualize data as graphs. You can host it yourself but there is also a free and paid cloud-hosted option. The free option is ideal for prototyping and has all of the features we need for now.

Using the power of a pattern-aware compiler, this cross-cutting concern can be seamlessly hooked up to an external monitoring service without adding try {} catch {} blocks everywhere in your codebase. This lack of clutter helps to keep your code clear and understandable and reduces the number of concerns placed upon your team.

Before We Begin

Readers who wish to follow along should take the following steps to set up their environment:

Download the .NET Core SDK and Runtime. I will be using VS 2017 on .NET Core SDK 2.2.106
Download the latest stable PostSharp Extension from the VS Marketplace. Version 6.1.18 is used here.
Clone the Semantic branch of my SharpCrafting repository or follow my previous article to build your own threaded Generic Host.

Understanding Pattern-Aware Exception Handling

An exception handler typically requires you to use some form of try { } catch { } finally { } statements which require every class to know its own context well enough to either bubble up, swallow, or handle an exception which occurs from within. An incorrectly handled exception can easily cause a service interruption or similarly poor experience for an end-user. This puts a burden of documentation and knowledge on any development team to understand the overall error-handling architecture outside the scope of any specific feature.

For example, in one solution alone I have found several hundred instances of try { } blocks. This can be rough if you run distributed, remote workers because the Exception may need to cross many boundaries without losing its original caller and state. Among those hundreds of try { } blocks there will undoubtedly be one or two which fail to handle as originally intended due to the slow feature creep of business needs. If those needs ever change significantly then there is a risk that any one of the handlers will be overlooked for compatibility. This can cause swallowed exceptions or an undecipherable call stack. The possibility of incorrectly handling exceptions becomes a major obstacle against refactoring and thus a tough sell for teams and project managers.

This is where aspect-oriented designs step in to provide a solution by consolidating your logic into a common place.

Handling Exceptions is a primary feature of the PostSharp namespace and I recommend reading it before continuing. The following objects are provided to us for a basic implementation:

The OnExceptionAspect class which lives in PostSharp.Aspects. This defines an exception handler around a method which will intercept any thrown exceptions and can handle them at a higher level.
The MethodExecutionArgs class which provides arguments containing advice for your handler. You can use these arguments to get the original exception, the arguments provided by the original caller to the intercepted method, and the flow behavior for execution.

The official PostSharp samples for Exception Handling are a great source to keep open alongside any documentation. I will borrow from the samples to show you an example of this implementation in action.

The first example is the “Add Context On Exception” Attribute. When an exception is intercepted by this attribute it will append the value of parameters to the exception. Having access to the argument values when reading over the exception later in the logs can save time debugging. This is an exceptional feature to have if you’re dealing with a bug that can’t be reproduced easily. In many cases it would have saved me hours of time to just know which arguments caused an exception in the first place.

This class has a few points of interest:

First, it inherits the OnExceptionAspect class which provides an exception handler.
Next, it intercepts exceptions thrown with OnException( MethodExecutionArgs args ) and tracks their state with the MethodExecutionArgs mentioned earlier.
Last, it builds a string containing the context including arguments, declaring type, generics, and method name. These are added to the Exception’s ”Context” index on the Data property.

The second example from the official samples is the “Report And Swallow Exception” Attribute. This one interacts directly with the previous attribute by reading the ”Context” added by the handling performed in the AddContextOnException attribute. A few things to note:

The aspect declares an [AspectTypeDependency] which is a way to handle aspect dependencies on the same target. In this case it declares that it must come after the AddContextOnException attribute if applied to the same target.
It checks to see if there is an additionalContext by checking the Exception’s Data property for any information added earlier on via the StringBuilder.

Applying Our Understanding With Azure

While these samples may seem basic, this is all you need to immediately integrate your applications with third party tools. I find that Application Insights is perfectly suited for a task like this since it is designed to have a low barrier to entry with a simple API. Let’s go over the next steps to see what our goals are and how we can implement them.

An Azure account will be needed for this, but luckily it comes with a free trial and is quick to setup. If this is your first time then I recommend this video which shows you how to complete the entire process in just a few seconds.
Create a new Application Insights resource through Azure. Grab the “Instrumentation Key” from the Overview page.
Copy down your “Application ID” from the “API Access” menu of your Application Insights resource.
Create an API key and copy it down as well. This can be done in the same “API Access” menu. Provide it all three options [Read Telemetry, Write Annotations, and Authenticate SDK].

Example of the Azure API key for Application ID.

Example of the Azure API key for Instrumentation and Subscription.

Example of creating an API key in Azure.

We’ll use these pieces of information later to integrate our real-time metrics with Grafana. For now, store those keys in a safe place and let’s revisit our code.

Integrating PostSharp With Azure

The goal here will be to write custom events to Azure describing an exception every time one is handled. We can restrict this to just two classes, one for Azure and one for the Exception Handler, by utilizing the OnExceptionAspect which we learned about earlier from the PostSharp samples. First, let’s write an Aspect to do the following:

Catch an exception.
Read the arguments.
Read the target name.
Read the Exception type and its message.
Mark a custom event with these properties on Azure and log them locally.

Let’s break down this class to see where Azure was included specifically:

We can see here that the Azure integration allows us to pass a dictionary of properties (similar to a JSON structure) into the custom event and all we have to do is give it a context. In this case the context is an “Exception”. That’s all there is to it! The only other configuration we need to connect to Azure is to add two files to our project. Monitor.cs and ApplicationInsights.config

In the above code we just need to replace “Your Key Here” with the Instrumentation Key we pulled from Azure earlier. Then we add this ApplicationInsights.config file to the folder containing our .csproj.

In the Monitor class, we set developer mode to true which will allow the telemetry to be uploaded in near real-time so that we can test it quickly.

Again, replace “Your Key Here” with the “Instrumentation Key” provided by Azure. Please note : readers should store their keys in User Secrets or somewhere more secure. This code is used for examples only so please do not commit your keys to your repository directly!

At this point the aspect is ready to send data to Application Insights. Decorate any method with [ServiceExceptionDetour] if you’re using the code provided here and then throw an exception from that decorated method. For example:

Here you can see that I am using the lovely ExceptionGremlin from the HouseOfCat Library. The author provides a number of useful tools in there like basic exception fuzzing. Every time I throw from within this method, CauseException, it will be routed through the Exception Handler and have its data passed to Azure. You will also notice that it is decorated as an [EntryPoint] which means that it is safely entered from many threads in an actor model despite being private. It is important to understand the lifetime and scope of aspects when used in this way. For our purposes though we can disregard any performance issues because Exceptions are already expensive and we’re not trying to be graceful here.

Log Analytics

If you navigate to Log Analytics on your Application Insights resource then you’ll be able to query the customEvents table to see if everything worked. You should have customDimensions on each record which contains the data you attached to the event from the Exception when it was handled.

This image shows how to reach Log Analytics from an Azure resource.

An example data structure for an Application Insights custom event.

If you are new to Log Analytics then I recommend checking out the official Kusto Query Language (KQL) From Scratch tutorial on Pluralsight. Here is an example query for our current set of custom events:

Grafana

Finally, we can integrate our Log Analytics store with Grafana to produce beautiful, real-time dashboards for our exceptions. If you’re new to Grafana then you can sign up for a free instance which is hosted as a container up in the company’s cloud. You can also host an instance on your own machine if you’d like to make it a dedicated resource.

Once you have signed up then you will need to set up your dashboard to work with Azure.

Install the Azure Monitor plugin on your instance of Grafana.
Open your dashboard and navigate to Configuration > Data Sources. Add a data source for Azure Monitor.
Fill out the two fields “API Key” and “Application ID” for Application Insights. We retrieved these keys earlier when we set up our Azure resource.
Click “Save & Test” to check if the connection is working.

From here you can begin utilizing KQL queries to make new visualizations. Here are some examples of what can be constructed alongside the queries and settings I used to build them.

An example of Grafana visuals showing a stable system.

An example of Grafana visuals displaying an unstable system.

An example image showing what a critical alert might look like.

Bar Chart :

Gauge & Annotation :

Where Can I Go From Here?

At this point you can watch your data flow into the Grafana dashboard in real-time! This pipeline can now be used to track any sort of metric you want. PostSharp has a comprehensive suite of tools for you to inject behaviors before and after execution on methods, properties / fields, and events. Anywhere you want to gather metrics without re-writing your old classes is a place to consider using an Aspect to provide that advice.

Instead of writing out to Log Analytics, consider writing your events to EventStore which allows you to build an immutable timeline to be used as a source of truth later to reason about your events. The overhead on EventStore is exceptionally low to the point where it may be easier to scale this form of Exception Handling by writing to EventStore and then reading it into Azure from a separate service.

While there are many unconventional options, the goal here is simply to automate the boring stuff. Rather than chase down exceptions you can instead intercept them and handle them a deterministic way with advice provided by Attributes. How you handle them is up to your situation and needs.

Credit

Totem was used in this repository. It provides a way to host your assemblies on an event-sourcing timeline and integrates with most common development scenarios. This package is still in preview right now but I recommend you add it to your favorites and keep an eye on it.

HouseOfCat Library was used for exception generation here. I recommend checking out their Rabbit MQ library if you utilize message queues regularly.

Final Remarks

The entire source code for this project is available on GitHub if you’d like to clone it and play around with the solution. Feel free to modify or redistribute it as needed. You can always find a copy of it on the Semantic branch.

Hopefully this article conveyed the power of Aspect Oriented Programming in the .NET Core architecture. This is a learning process for all of us and I invite you to share or collaborate any time. Thank you for taking the time to read.

AlexanderJohnston / SharpCrafting

Exploring PostSharp AOP with .NET Core Generic Host

SharpCrafting

Exploring PostSharp AOP with .NET Core Generic Host. See my article on Medium for a detailed explanation.

Requirements

PostSharp Essentials or Ultimate.
Visual Studio 2017
.NET Core SDK 2.1 and C# 7.3

Goals

Demonstrate cross-platform .NET Core services which are threaded for a multi-core computer and wrapped with logging.
Create an example of utilizing PostSharp with the Generic Host in a console app.
Explore the benefits of Aspect Oriented Programming by masking the boundaries solved through use of PostSharp.

View on GitHub

Automating .NET Core Services with PostSharp and Aspect-Oriented Code

Alexander Johnston — Fri, 08 Feb 2019 14:01:00 +0000

If you’re writing software targeting .NET then there’s a good chance you’re using Object-Oriented principles to do your work. In the process you may run into design patterns which you find yourself often repeating. Some of these patterns start as an abstract need such as “I want to log what my code is doing”. In practice this is easy to solve but as your solutions grow in scope you may find yourself spending a significant amount of time just deciding where and how to log your program’s state. Eventually you may want to change the logging pattern but that will require a significant amount of changes to the source.

While many people have solved this in an Object-Oriented way, these cross-cutting concerns will eventually add up to significant time sinks for any development team. They also present an architectural challenge later down the line when you need to make a significant change. You will have to walk back through all of that boilerplate code at some point when you want to add new log sinks, monitors, or internal log exception handlers. This problem comes up again on many common concerns such as security, caching, threading, rate limiting, and even alerting a GUI that some viewable object has been updated.

Aspect-Oriented designs are focused on targeting those concerns by dealing with the problem in one place and then applying that solution everywhere in your code where it is needed. What I am trying to show here is a way to purposefully hide away those concerns after investing the time to fully model them out. By spending some extra time considering our approach to logging or threading then we can write Aspects which are more like qualities that can be assigned to areas of code. Once you write a [Log] attribute, then you can decide a class or a method will be logged simply by tagging it with the attribute. Later on the compiler does the rest of the work by going back over and adding the missing code where those Aspects are declared.

As a quick note before I get into the main example, Microsoft released .NET Core 3 Preview 1 last month and with it comes support for native Windows desktop namespaces. While this article deals with .NET Core 2.1, you can recompile it at any time under netcoreapp3.0 as a project target and it will support a wider surface of types, including UWP libraries, without any extra configuration.

Remarks

This article is an attempt to cover certain difficult topics which vary in design from one business to the next. The code I will reference is written to be as short as possible, not fast or efficient. This is in the interest of showcasing each of the features and creating a usable demonstration.

The goal here is to explore the cross-platform capabilities of the .NET Generic Host when combined with the power of a pattern-aware compiler. By wrapping the platform and runtime concerns around the generic host it becomes possible to seamlessly link almost any part of the .NET library for any platform. This doesn’t mean you can run a UWP library on Linux, but you won’t have to rewrite any code if you want to run that library when it detects Windows 10 as the OS.

PostSharp is a pattern-aware compiler extension for Visual Studio and will be featured heavily throughout the article. If you don’t have a license and want to follow along with the code then there is still a solution. The free Essentials version of this framework covers up to ten classes which is enough to implement the full program in this article. You will also need to download the extension for Visual Studio 2017.

Hosting Services

I spent the past couple months getting a handle on the new .NET Core Generic Host which is familiar to anyone who has worked in ASP.NET Core web applications. The host can also be used in console applications as well to handle built-in app configuration, dependency injection, and logging. Let’s take a moment to see how the service hosting fits into this design.

The goal is to create a small application which can:

Host common services and load native classes based on OSVersion.
Automatically wrap logging around the entire solution.
Automatically thread the services for a multi-core computer.
Validate architecture so that bugs throw exceptions in a deterministic way.

Now because I have spent a lot of time working on ETL solutions I tend to map out the flow of my program and look at what my goals are from a high level. Below I’ve drawn out just some basic shapes to illustrate what the structure is and try to see where the boundaries are going to be. These boundaries are important because they represent areas where concerns cross over and cut into the concerns of individual objects. When using AOP in a project I always find it helps to clearly define where those boundaries are because the goal is to hide how they work. You’ll have to excuse my MS Paint aesthetic here:

Immutable (Frozen) Runtime and Platform areas which host Services wrapped in an Actor Threading Model.

Program: A console app with Main() in this example.

Runtime: This will be the top level for all of the PostSharp wrappers and the constructor for the rest of the program. This should launch the service host.

Platform: This contains any methods needed to load native classes and provide a thread-safe reference to the Host in case any inter-service communication needs to be implemented.

Frozen: Both of the previous layers will be frozen which provides some of the same guarantees as an immutable object. This will be covered later on.

Hosting: The .NET Generic Host builder.

Services: The services will be wrapped with an Actor model ensuring that they can run on a multi-core computer.

Log Output

Throughout this exercise you will see several examples of log output which describes the state of the program in a specific template. I’ve marked some of them here as an example of what the values represent.

Console log output generated automatically by PostSharp

Program

First, let’s start with a new .NET Core 2.1 console app.

Next we need to add PostSharp to the project. If you have the extension for Visual Studio then you can right click on the project and add PostSharp to it through the menu. You can also use the Package Manager Console to run Install-Package PostSharp

You will also need to add the following NuGet packages:

PostSharp.Patterns.Common The bulk of the code contracts and aspects.
PostSharp.Patterns.Diagnostics Tracing, logging, and diagnostics.
PostSharp.Patterns.Diagnostics.Serilog Automatically inject Serilog.
PostSharp.Patterns.Threading Threading models, dispatching, and deadlock detection.
Serilog Logging framework.
Serilog.Sinks.Console and Serilog.Enrichers.Thread for the sink.

Now that we have our packages, let’s drop down one layer away from Program for now. I suggest a sealed runtime layer with static properties and an isolated, non-static entry-point. This allows the runtime to be instantiated as an object with its own threading model which can then launch onto a platform compatible with the caller’s context. The static properties are isolated away from the entry point and can then be used to attach async monitors or metrics later on.

Now that we have a basic structure, we can talk about threading models. PostSharp provides three major features in PostSharp.Patterns.Threading.

Threading Models : A threading model is a design pattern that gives guarantees that your code executes safely on a multi-core computer.
Thread Dispatching : Custom attributes DispatchedAttribute and BackgroundAttribute cause the execution of a method to be dispatched to the UI thread or to a background thread, respectively.
Deadlock Detection : Detects deadlocks at run time and throws an exception instead of allowing your application to freeze.

Threading models are named solutions to recurring problems and can be considered a design pattern which we will inject at compile time. Defects are discovered by validating the code both during build and while running. If the application is improperly threaded then it will fail in a deterministic way inside of these models. Without this assurance, race conditions or deadlocks tend to show up randomly and can corrupt data without any warning.

The primary threading model we will be looking at is the Actor model. Actors are services which run with their own state and a mailbox to receive messages in synchronous order. Their execution is more complex than this image describes, but they can be thought of as independent objects which run asynchronously against a queue of messages.

Actors do not map one-to-one with threads but it is helpful for illustrating execution.

The second threading model being used is the Freezable threading model. An immutable object can be safely accessed from multiple threads but the restrictions of immutability often makes configuration difficult. By using Freezable objects we can define at what point in time the object becomes immutable while still benefiting from mutability during creation.

Now let’s wrap the Runtime class with a frozen model.

To freeze an object we need to decorate it with an aspect called [Freezable]. To enforce most threading models, PostSharp relies on the [Aggregatable] attribute; this specifies that a class has its Parent/Child relationship explicitly defined. Any properties which are not children should be marked as a [Reference]. Any methods which return the same value for each input and make no observable state changes can be marked as [Pure] to inform PostSharp that they are safe in a threaded context. I opted to include [NotNull] to indicate which properties are available from the entry point.

Now that the Runtime class has been updated we can move on to the Platform. While developing for a cross-platform application on .NET Core, it’s helpful to have a layer where concerns of the platform can be safely handled. Let’s take a look at some functions you might see here:

GenericHost Creating the .NET generic host.
GetNativeClass Services may need to load platform-specific implementations and this will provide the correct type.
Crash If we are going to inject threading models safely then services also need a way to crash if state becomes fatal.

You will see the following patterns on the Platform code:

[Required] Throws if null is passed in so that the responsibility belongs to the caller.
INativeClass Serves as an interface to load and terminate native classes after importing them.
.Crash() Allows native platform classes to call for immediate debugging or termination if a fatal state is reached. It is marked with [ContractAnnotation (“=> halt”)] which specifies that for any given input the output will be a halted state. This allows the IDE to emit warnings appropriately.
GenericHost Will be decorated with [Reference] instead of [Child] which doesn’t guarantee thread safety anymore at the boundary but also doesn’t force the host to implement a compatible model.

Now we have a Runtime with a thread safe entry point and a Platform which can load native classes. At this point we can go ahead and use the .NET Generic Host, specifically HostBuiler to configure services and host them.

Several packages are helpful for using the HostBuilder:

The .Start() method is decorated with a [SingleEntryMethod] attribute which automatically intercepts the method and returns null if it has been called more than once. This permits us to leave a reference to the Generic Host inside of the Platform without worrying about this method being called later on. Because this class is being intercepted, we can decorate it with the [ExplicitlySynchronized] aspect which informs PostSharp not to verify the safety of this class.

[SingleEntryMethod] is a custom aspect written with PostSharp. To create one of these we only need to decorate a class with [PSerializable] and then inherit from any of the PostSharp aspects. In this case we want to intercept calls at the boundary of the decorated method which is a feature provided by MethodInterceptionAspect.

As you can see in the Generic Host, one service was registered called TimingService. Let’s set that class up now. This will use the [Actor] threading model with a few new attributes:

[Actor] Generates code which prevents fields of an actor from being accessed from an invalid context. Requires [Aggregatable] parent/child decoration as well as the following two aspects.
[Reentrant] This attribute declares that an async method can be safely re-entered on each await statement. For the actor model, this means other methods can be invoked while waiting. This must be applied to all async actor methods.
[ExplicitlySynchronized] Opts out of the threading model by declaring that the object is handling its own safety.
[EntryPoint] This specifies that the method can be invoked from threads which do not currently have access to the object. This means an event handler, background task, or callback can safely enter the threading model. Only needs to be applied to private methods.

The TimingService class also inherits from IHostedService which integrates with the .NET Generic Host which is covered by this MSDN article. Each of these services will have StartAsync() called in the order they were registered during configuration earlier in the GenericHost class. The queue reverses this order when StopAsync() is called, starting with the last service registered and working its way back through the queue.

In the interest of keeping this example small we’re going to cheat here and just use a few Timer objects to run on threads and report back. This should illustrate that our class is appropriately using the threading model. These aren’t technically native namespaces either, but calling out to platform-specific code will work exactly the same way without any configuration.

With that in mind we need to implement the NativeTimers class which is imported from the Platform into TimingService after StartAsync() is called.

NativeTimers will need to be placed under a namespace compatible with the platform this code is running on. In my case I am running on Windows 10 17134 which will return “Win32NT” as the Platform. A list of potential platforms is provided by Microsoft.

MacOSX
Unix
Win32NT

At this point we have created the following areas of code:

Runtime Entered from Program, configures logging and then sets up the platform.
Platform Contains methods for loading native types and starts the generic host.
Generic Host .NET Core Generic Host which configures and creates services.
TimingService An example service being threaded with the Actor model.
NativeTimers An example being loaded natively by the Timing Service.

Now we just need to inject the logging wrapper and freeze our layers, starting with the .Entry() function in Runtime.

You will see the following patterns here:

LoggingServices.DefaultBackend This is the PostSharp logging back end. By setting our logger here we can then inject it later on.
Post.Cast<T, IFreezable>( object ).Freeze() This is the call to freeze an object and mark it as immutable.

The VerboseLogger() implementation and BlueConsole theme:

Last we just need to call the Runtime from the program and inject logging into the assembly.

Create a new GlobalAspects.cs class without any using or namespace declarations. Include these lines:

This will wrap all Public, Private, Internal, and Protected members with the [Log] attribute from the assembly level.

Now just call the runtime from Program and watch it run.

If everything is set up correctly then we should be able to watch the entire flow of execution print out to the console.

We expect to see something like this:

Generic Host starts up and creates the services.

Services access AppConfig which creates the Platform.

Services start asynchronously and ask for native types from the Platform.

Native Timers class is constructed and three timers are set.

Application starts.

Timers callback to the private 1[EntryPoint]1 on 1WriteTime()1.

If you’ve been following along up to this point then you now can launch native classes onto services hosted cross-platform with the logging and threading handled.

Where can we go from here?

Calling any libraries or namespaces from the services will automatically pipe the log statements if those libraries also implement Serilog, whether or not they have a custom log handler. This can be made compatible with other loggers as well.
State machines will automatically be maintained by PostSharp so that asynchronous code is threaded safely. You can see these decorated in the logs above. The services are able to call into asynchronous code from other frameworks as well; this means a UWP .NET Framework 4.7.1 class library can be called from .NET Standard 2.0 library referenced by a service running under .NET Core 3.0. This so far has worked without any needed configuration for me other than to compile the console application under <TargetFramework>netcoreapp3.0</TargetFramework>.
Asynchronous log monitors can be attached to Serilog with the ability to call back into Runtime or Platform as needed. These can be used to monitor flow, handle dropped log events, and handle deterministic internal logger exceptions.
An Event-Sourcing timeline, Inter-Process Communication Channel, or API can all be attached to the service actor model. Each actor can write events back to a central source asynchronously while guaranteeing the messages are threaded properly.