Skip to main content
ZenHub houses documentation to support you if you’re using Contensis Classic. Contensis Classic includes our WYSIWYG and templating features. If you’re working with a newer version of Contensis, is your go-to place to find anything Contensis-related when building with content types.
There is a newer version of Contensis. Click to find out more and download the latest version.

Add logging to your bespoke projects

Adding logging to your bespoke projects


To use logging in your bespoke project, you’ll need to add references to the following assembly:



Add the following directives wherever you wish to use logging:

using Zengenti.Diagnostics;using Zengenti.Diagnostics.Logging;

Logging levels


Primary audience: developers and support.

Debug is used for development and testing.

Debugging logs would include:

  • method entry – possibly including input parameters
  • state transition, logging before and after calling methods on other components
  • method exit – possibly including some additional information regarding final state

There should always be at least one call to another component or at least one flow control statement between two DEBUG logs. i.e. ‘if’, ‘for’, while’ etc.

NOTE: the example above is pretty verbose – you wouldn’t normally employ this amount of debug logging on one method.


Primary audience: developers and support

Used for logging state changes within a component which are part of normal operations, such as:

  • Start of initialisation
  • When a component becomes operational
  • Starts shutdown or disposal
  • Just before expected termination
  • Completion of steps within a user story
  • Progression of other processes; for example, publishing.


Primary audience: developers and support

Warn is used for events which indicate irregular circumstances, but for which we have a clearly-defined recovery strategy and will have no impact on system availability.

For example, when processing a list of key/value pairs a duplicate key is encountered. An agreed recovery strategy could be to use the first value obtained and ignore the duplicate. This action would be logged as a WARN with the appropriate information. Aborting the process would be logged as an ERROR.


Primary audience: monitoring systems and users

This level serves as the general error facility. It should be used whenever an unexpected error is encountered which prevents further processing. The logging component may attempt to recover.


Primary audience: monitoring systems and users

Should be reserved for special cases where the error needs to be picked out immediately – for example: errors with no agreed recovery strategy, or catastrophic environment errors. Other than that, it’s the same as ERROR.

Logging code can affect the application

Care should be taken when logging as a mis-handled logging call can have detrimental effects on application behaviour.

If ‘result’ is null, the call to obtain ‘result.State’ would throw a NullReferenceException, and the application would not be told to ‘DoOtherStuff()’. The debug log in this case has adversely affected the flow of the application.

If logging specific data on an object, it is best to do this defensively:

Logging potentially null values

Avoid dependencies

Don’t call other services to obtain data for your log.

Use data that is already in scope

Wrap 'primitive obsession' for data in scope

'Primitive obsession' is an anti-pattern where related data is passed around as unrelated primitive values, rather than being grouped in some object which would give the collection some context and meaning.

If you're passing locally scoped data as additional information for the log, it is better to wrap the data in an anonymous object and give each data item a meaningful name, as in the example below.