The importance of versioning your site in Episerver

Reminder: Why you should use semantic versioning on your site dlls too.

Published 1st March 2019

Episerver is using a pretty neat functionality to sync the page/block models during initialisation.

In short, it will scan site dlls, compare with the database, IF the version is right the system will allow an database update. Here comes the importance of up versioning your dll. I’ve experienced models not beeing synced or being removed (multi-environment) before beeing used.

The sync is not removing ContentType nor Properties on Models if it has been used, but if it hasn’t, or no content exist, it will be removed. If not removed, it will be marked as “missing in code” in admin ui.

Ever had an error like this in back end UI?

SqlException (0x80131904): The INSERT statement conflicted with the FOREIGN KEY constraint “FK_tblContent_tblContentType”. The conflict occurred in database, table “dbo.tblContentType”, column ‘pkID’

This is due to conflicting types in database. Due to missing semantic versioning of your project dlls. It also frekvent when developers use the same db.

A way around meanwhile that is safe, is to delete all content in tblContentTypeToContentType (scary but it will restore the new data in next init)

How to semantic version your project?

Be sure to use *star* in AssemblyVersion in your project AssemblyInfo.cs like this:

It will then give a  higher version nunber every time you build. It also works on a build server.


If you rather want to control the build no, there is a Azure Devops pipeline plugin where you can manipulate the AssemblyInfo.cs before building on the build server.


Further reading



  • Problems with creation of new Block/Page types

About the author

Luc Gosso
– Independent Senior Web Developer
working with Azure and Episerver

Twitter: @LucGosso

Like it? please up vote