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 Razor views

To add logging to your Razor views, simply add the following using statement to your razor view:

@using Zengenti

Once you have completed the above step, follow the instructions for Config file locations - Published website to enable the logs to appear in the Contensis Log Viewer.

Logging levels


Primary audience: developers and support.

DEBUG logs are used for development and testing.

Examples of debugging logs would include:

  • The beginning of a function/sub/method, possibly logging the parameters (if a function)
  • Logging before and after calling methods on other objects
  • The end of a function/sub/method, possibly logging additional information about the final state, like the value returned (if a function)


Primary audience: developers and support

Info is used for logging major state changes within a component which are part of normal operations. e.g. “Loaded 200 news articles”


Primary audience: developers and support

Warn is used for events which indicate irregular circumstances, but for which won’t bring down the page and has no impact on system availability.

For example, when processing a list of key/value pairs a duplicate key is encountered. The error handling might be to use the first value obtained and ignore the duplicate. This will still allow the page to function, and we’d log it as a WARN with the appropriate information.


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 breaks something.


Primary audience: monitoring systems and users

This should be reserved for special cases where the error needs to be picked out immediately. This would be used for something which destroys the App Pool for example - has a real global effect and breaks a lot of stuff - So this shouldn’t be used in razor views 99% of the time.

Adding components to your logs

You can add components to your log message to categorise in which section of the system the error occurred, e.g. “Razor” or “Events Listing”

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 ‘relevantData’ is null, the call to obtain ‘relevantData.ID’ would throw a NullReferenceException, and the ‘PartialB’ would not be rendered. The debug log in this case has adversely affected the flow of the application.

Defensive logging

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

Logging potentially null values

When formatting log data, it is advisable to wrap each placeholder with ‘[ ]’, as this helps in identifying null or empty values in formatted logs: