Add built-in Episerver properties to the log4net output


This blog post is about how you can log and output built-in Episerver properties (or any other arbitrary data that might be relevant to the context of our logs) with log4net. The goal is to keep as much as the default implementation and functionality of log4net and Episerver as possible.


If you’re new to Episerver then log4net is the component that’s shipped with Episerver which is responsible for logging. In the world of code you would write something like the following.

This would in turn output a row in our logfile with additional data that’s relevant in the context of our error message.

There’s more about Episerver and log4net over at Episerver World.

One of the key features of log4net is that it can have one or many appenders that’s decoupled from our code. These appenders can output log data to various formats, systems, etc. Very simple illustration below.


The default log4net appender in a vanilla Episerver-installation is the rolling file appender. The default rolling file appender is configured to output log data to a file named EPiServerErrors.log that ends up in the App_Data-folder of the website root.

log4net appenders typically use the pattern layout which defines how and what is to be output to the log destination. The default fields that are logged with Episerver are as follows: date, thread, level and the error message itself.

This is all fine but there could be cases where we would need to log additional data that are not included by default.

Adding custom properties to the log4net context

Just to be clear: it’s not custom Episerver properties we’re talking about. Instead it’s custom properties in the context of log4net, i.e. name value pairs of something that we wish to add to the logfile.

To log custom properties with log4net we have to add a property to the log4net ThreadContext properties map. The following code snippet would add the ID of a content item to the ThreadContext properties map and made available for log4net.

This will add the Content ID value of a Content Reference to the properties map using the key of ContentID. Should something happen later down the line with the executing thread that property value will be available for log4net.

Using an IInitializableModule to add built-in Episerver properties to the ThreadContext

To be honest there might be a more clever way to accomplish this. But for the sake of this blog post I’ll show how we with an IInitializableModule can hook up to Episerver events and add the current Content ID and Content Type ID to the log4net thread context.


With our custom properties added to the log4net ThreadContext we’re able to access them using the pattern layout and its printf-style formatting. We can output our custom log4net properties using the pattern %property{NameOfOurProperty}.

A sample episerverlog.config would look something like this with the Content Type ID and Content ID properties.

It’s not always the error will occur in the context of loading content. In that case the Content ID and Content Type ID will be null.

Simulating an error in the sample Alloy Episerver project the log file will look a something like this with the log level set to info (don’t set it to info in a production environment).


The example with Content ID and Content Type ID can of course be substituted for any other arbitrary data that might be relevant for us to hunt down and slay the foul bugs of the error world.

Thanks for reading!


Developer, Episerver MVP, CEO
Recommended Posts
Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search