Documentation Menu


JSNLog's default configuration lets you do simple client side logging out of the box. This is probably enough for most sites.

However, to access the full set of features, such as named loggers, filtering on user agent, etc., you'll need some configuration.

Configure in code or in your web.config

JSNLog can be configured in one of two ways:

Click here to start configuring JSNLog >>>

How server side configuration of client side loggers works

As you saw, you can use server side code or configuration to configure client side loggers and appenders, etc.

To make this work, JSNLog includes the Configure HTML helper (for ASP.NET 4.x) and jl-javascript-logger-definitions tag helper (for ASP.NET Core).

These translate the server side configuration into JavaScript code that configures loggers, appenders and some general client side settings. It then injects this code into your page.

You will want to include them near the top of the page, before any other JavaScript is loaded.

Configure also generates the script tag that loads the jsnlog.min.js file (how to stop this). However, <jl-javascript-logger-definitions /> doesn't.

If you cannot call Configure or <jl-javascript-logger-definitions />

Some sites use flat HTML files, that is, they are not generated dynamically using MVC or WebForms. This means they cannot call Configure or <jl-javascript-logger-definitions />.

In that case:

Client side configuration during page load

If you write your own JavaScript configuration code, there is one last twist. In some scenarios, such as with AMD modules, you can't always be sure when jsnlog.js and your JavaScript configuration code actually load. If jsnlog.js loads after your configuration code, that configuration code will obviously not work.

The solution is to put your configuration code in a global method called __jsnlog_configure. After the jsnlog.js library has loaded, it checks whether there is a global function with that name, and if there is, executes it.

Your configuration code would look like this:

__jsnlog_configure = function (JL) {
    ... configuration code
try { __jsnlog_configure(JL); } catch(e) {};

This solves the race condition:

  • If your configuration code loads after jsnlog.js, it is normally executed.
  • If your configuration code loads before jsnlog.js, there will be an exception, which is swallowed by the try ... catch.

    Then when jsnlog.js loads, it calls __jsnlog_configure and now your configuration code will run successfully.