TypeInitializationException in EPiServer CMS SP3

I recently got the stack trace below in one of the web sites that we are building.

The site is running EPiServer CMS and it seemed that the problem is caused by a change in the module loading logic in EPiServer CMS SP3.

Quote from SP3 Uppgrading problems post in EPiServer Forum.

With SP3 there was some remodelling in how a EPiServer handles the initialization of the application.
…
These changes however made it so that it’s not possible to hook into the datafactory events in Application_Start.
Instead we first hook into Application_FirstBeginRequest and then we have a instance of the DataFactory to work with.

Debugging the problem was a little PITA, because of all these static and non static constructors that just fail to load and eventually hide the real exception. Instead a more general TypeInitializationException is returned.

As the commercial says: Do not this at home. Avoid putting logic that loads resources and does some heavy work in the constructors, either non static or worse – static ones. You will spend hours debugging such a code.

Here is the stack trace itself:

Server.GetLastError() returned System.TypeInitializationException: 
The type initializer for 'EPiServer.DataAbstraction.UnifiedPathInfo' threw an exception. ---> 
  System.TypeInitializationException: The type initializer for 'EPiServer.CacheManager' threw an exception. ---> 
  EPiServer.BaseLibrary.ClassFactoryException: ClassFactory not initialized
   at EPiServer.BaseLibrary.ClassFactory.get_Instance()
   at EPiServer.BaseLibrary.ClassFactory.IsRegistered(Type baseType)
   at EPiServer.CacheManager..cctor()
   --- End of inner exception stack trace ---
   at EPiServer.StaticCacheKey.EnsureKey()
   at EPiServer.StaticCacheKey..ctor(String keyName)
   at EPiServer.DataAbstraction.UnifiedPathInfo..cctor()
   --- End of inner exception stack trace ---
   at EPiServer.DataAbstraction.UnifiedPathInfo.Load(String path)
   at EPiServer.FileSystem.DefaultAccessControlList..ctor(String path)
   at EPiServer.Web.Hosting.DirectoryAccessControl..ctor(String virtualPath)
   at EPiServer.Web.Hosting.UnifiedDirectory.get_DirectoryAC()
   at EPiServer.Web.Hosting.UnifiedDirectory.QueryAccess()
   at EPiServer.Web.Hosting.UnifiedDirectory.QueryDistinctAccess(AccessLevel access)
   at EPiServer.Web.Hosting.VirtualPathVersioningProvider.GetDirectory(String virtualPath)
   at EPiServer.Web.Hosting.VirtualPathHandler.InitializeProviders(ProviderSettingsCollection providers)
   at EPiServer.Web.InitializationModule.InitializeVirtualPathProviders(VirtualPathElement vpElement)
   at EPiServer.Web.InitializationModule.Initialize(EPiServerSection config, Settings settings, 
ConnectionStringSettingsCollection connectionStringSettings)
   at EPiServer.Web.InitializationModule.StaticInitialization()
   at EPiServer.Web.InitializationModule.Application_BeginRequest(Object sender, EventArgs e)
   at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Fixing this was actually easy, finding the root of the problem.

I wrote a small module that makes the required initializations that did not have a chance to start yet. It looks like this:

public void Init(HttpApplication context)
{
    EPiServer.Web.InitializationModule.Initialize(EPiServer.Configuration.EPiServerSection.Instance, 
        EPiServer.Configuration.Settings.Instance);
    if (!EPiServer.BaseLibrary.ClassFactory.IsRegistered(typeof(EPiServer.Diagnostics.ITransformer)))
    {
        EPiServer.BaseLibrary.ClassFactory.RegisterClass(typeof(EPiServer.Diagnostics.ITransformer), 
            typeof(EPiServer.Diagnostics.DefaultTransformer));
    }
} 

No guarantees it will work for you though 🙂