Ollie Philpott
Feb 19, 2019
(9 votes)

Common errors when developing an Episerver site

At Zone, we spend a lot of time developing and maintaining large-scale Episerver builds with a team split across the UK, Romania and India. With a large codebase and lots of developers working at the same time, there are some errors we encounter occasionally that can take time a lot of time to identify, but are quick to fix when you know the solution.

Changes to content types are not reflected in the CMS


If you are using a code-first approach to create and modify pages and blocks, and you notice that changes are not being reflected when you view the content in the CMS, you may have a problem with assembly versions.

You can confirm that you are experiencing this issue by navigating to the Content Type tab in the Admin section of the Episerver CMS. If you select a content type from the left-hand menu, you will see a yellow warning message like this:

Changes in the model for this page type were ignored because its version ( is lower than version in the database(

This can occur after restoring a backup of the CMS database from an environment where semantic versioning (eg GitVersion) is being used, to an environment not using any versioning – such as a local development environment.

Episerver stores the current version of an assembly in the database when syncing changes to the model. If the site is loaded with a version of the assembly lower than the one stored in the database, it will not update the model to avoid overwriting the most recent update with older changes.


You can fix this by running a short SQL script in the database to reset the version of the assemblies to correct version.

UPDATE [dbo].[tblContentType]
SET [ModelType] = REPLACE(ModelType, ', Version=,', ', Version=,')
WHERE ModelType like '%, Version=,%'

You should replace with the version that is incorrectly set in the database, and with the version in the assembly info.

Website pages are loading slower than usual in a development environment


When loading a website that uses Episerver Find, pages suddenly take a lot longer to load. When checking the Episerver logs, you may find errors like this:

EPiServer.Find.ServiceException: The remote server returned an error: (401) Unauthorized.

We have experienced this when developing locally - where we may be using an Episerver Find demo licence. Since the demo licence only lasts for 30 days, you will see this error when the licence expires if you are calling Find during page load. It is a bit more obvious if your website crashes and you see a Yellow Screen of Death (YSOD), but if you are handling errors in a more graceful way, it may be harder to identify the cause.


Generate a new demo licence at https://find.episerver.com/ and update the search index in your Web.config.

YSOD for all pages


Loading the site or CMS shows the .NET YSOD with an error message like the following:

ERROR EPiServer.Framework.Initialization.InitializationEngine: Initialize action failed for 'Initialize on class EPiServer.Initialization.Internal.ModelSyncInitialization, EPiServer, Version=, Culture=neutral, PublicKeyToken=8fe83dea738b45b7'

The DELETE statement conflicted with the REFERENCE constraint "FK_tblContent_tblContentType". The conflict occurred in database "myCmsDatabase", table "dbo.tblContent", column 'fkContentTypeID'.

This error, or similar sounding errors, can occur for a number of reasons. Lots of causes and solutions are discussed in the Episerver forums: https://world.episerver.com/Search?searchQuery=statement+conflicted&from=151704

The error is triggered from SQL Server when a command to delete a row of data conflicts with a constraint on one of the columns in the database table.

In this case, it seems to occur during the model sync as Episerver initialises after a page or block type has been deleted from code. I have not been able to identify the exact conditions that lead to this error in Episerver but I have seen it happen several times after deleting a page type and deploying the code to another environment.  

If you check the tblContent table in the Episerver database, you may find you have orphaned rows that are flagged as Deleted but are not present in the Recycle Bin of the CMS.


  1. Empty the Recycle Bin in the CMS
  2. Run a SQL query to check if there are still any rows remaining in the database that are set as Deleted:
    SELECT * 
    FROM [tblContent]
    WHERE Deleted = 1
  3. If there are rows returned by the query after emptying the recycle bin, delete the rows from the table:
    FROM [tblContent]
    WHERE Deleted = 1​

The site should now load as normal.

Front-end assets redirect to the login page


We have experienced this error when a developer is setting up a new machine or a new project. The issue happens when loading the website – front assets such as CSS or JavaScript fail to load and if you attempt to load the assets directly you are taken to the Episerver login page.

Logging into the CMS will allow the assets to be loaded, but this issue is caused by misconfigured Windows security permissions for assets folders for IUSR or IIS_IUSRS.


Right-click on the root folder of the website, select Properties and the Security tab.

Ensure that IUSR and IIS_IUSRS have at least read access to the root folder and subfolders (IIS_IUSRS requires write access to the blobs folder).

The assets should load correctly once these permissions are configured.

Feb 19, 2019


Sofia 'Sonya'
Sofia 'Sonya' Mar 9, 2020 09:27 PM

Thank you!

Updating ModelType to fix version problem was very helpful.

I feel that updating just one content type can be an option:  

UPDATE [dbo].[tblContentType]
SET [ModelType] = REPLACE(ModelType, ', Version=,', ', Version=,')
From tblContentType t
t.[Name] = 'MyBlockName'

I wonder what is the purpose of this version check by Episerver in general. 

Praful Jangid
Praful Jangid Oct 14, 2020 07:22 AM

Thanks for sharing this post. I had that issue of database version. Your post saved my time.

Manoj Kumawat
Manoj Kumawat Jun 9, 2021 11:54 AM

5 stars. It solved an old issue that I didn't not take care of since long time thinking of this might be happening for some weird reasons and would solve automatically.

The versioning was causing sync issues with the content types.


Please login to comment.
Latest blogs
Content Graph - Letting GraphQL do all the hard work for you

Background As we have seen before, setting up Content Graph on the CMS side is pretty easy. However, when it comes to the “head” part of the setup,...

| May 26, 2023 | Syndicated blog

Improved headless functionality in Customized Commerce

Did you know that with the release of Content Delivery Commerce API 3.7 we have massively improved the out of the box headless capabilities of...

Marcus Hoffmann | May 25, 2023

Boost Your Productivity with the AI Assistant Addon for Optimizely Content Cloud

In today's fast-paced digital world, efficiency and convenience are paramount. That's why we're excited to introduce the Optimizely AI-Assistant...

Luc Gosso (MVP) | May 25, 2023 | Syndicated blog

Swapcode.Optimizely.AuditLog updated to v1.4.1

If you are using my audit log add-on Swapcode.Optimizely.AuditLog then I suggest that you update it in your solution. I've been waiting now for few...

Antti Alasvuo | May 20, 2023