In this tutorial, you will learn how to Implement the
Common.Logging framework with Episerver CMS. If you work on many Episerver projects at the same time, a good goal to aim for is to minimise the amount of duplicate code that you need to write. If you're working on multiple Episerver projects, you might be tempted to create a shared code library (usually through a local NuGet feed on your build server) and import that library on each project. This idea is good, however, when you come to try and log errors you will likely hit a snag. Image website A uses Episerver 7, which uses Log4NET version 1 and Website B uses Episerver 11 using Log4NET version 2. If you have encountered this issue, it can be a pain. In today's post, I'm going to give you my best tips on how you can tackle this problem, so let's get started.
Managing Logging Dependencies
There are a few different options to consider when thinking about when creating a shared library and implementing a logging library:
Use a third-party logging library, like NLog, that isn't being used by Episerver
Write something custom
Everyone will have their own preferences as to which approach to take. Out of these options, using an alternative library, like NLog is probably the quickest and easiest choice. If you're using a service like Episerver DXC you may want to create your own logging services you can get instant access to your logs. On my last project, I decided to try the Common.Logging approach. Within this article, I'm going to cover how I implemented it and my thoughts on it.
Implementing Common.Logging With Episerver
Common.Logging provider was written to try and address exactly these types of logging issues. When you work on multiple projects, it is very common that different frameworks will use different logging providers or different versions. The
Common.Logging library was developed to provide a simple abstraction s consumers can decide the type of logging implementation they want to choose. For reference, the Common.Logging NuGet package can be found here.
Common.Logging provider, install it. When you need to log something you then use the common.logging log interface (very similar to the Log4Net one) to log your errors. When you use that code within your Episerver website, you define some
common.logger specific configuration in your
web.config. This config will define the type of logging adaptor to use specific to that site.
When you use the
common.logger, you don't define the logging framework or the version it uses in your shared library. Instead, you define the provider in each website that consumes it. What this means is that in each website that consumes your shared library, you will have a 5-minute set-up task to define the logger. This approach decouples the log provider from your shared codebase. Removing the DLL assembly mismatch errors. Using
Common.Logging means you create a shared code library that will be easy to maintain and won't screw up your binding redirect references within your
Implementing Common.Logging With Episerver
Now you know the theory, lets look at code. The first bit of code that you will need to write will define a custom log appender. The job of this class is to map the
common.logging interface to the Episerver logger:
You will also need to create an adaptor. The adaptor is the thing that you point to your
common.logging settings within your
web.config. The code to do this, looks like this:
The last step is to add the
common.logging configuration within the
web.config. This configuration, looks like this:
That's it! Granted you need to copy these two files and add the config into each project where want to consume your shared code library, however, the following approach means you can log stuff within your Episerver logs AND you won't have any Nuget referencing hell 💥💥💥
Common.Logging provide a means to decouple a logging framework from your code. This can be handy if you want to have a shared code library that works between different websites. Granted the downside of this approach is that you need to add some custom code within the
web.config of each consumer. From experience, this is a good trade-off to get around the dependencies issues that can result.
Simply using a third-party logging provider that is not used by Episerver (like NLog) would also get you around this problem. As Episerver doesn't use NLog, you'd never get the same assembly version conflicts as you will when all consumers of your websites use different versions of Episerver. This approach is obviously not as robust. Using a separate Log provider would mean that all the errors generated within the shared code would appear in a separate log file. I think my preference in most situations would be to use
common.logging. Happy Coding 🤘