Martin Kulov's Blog

I want to bring your attention to a Virtual Path Provider module we’ve built in Propeople. By default EPiServer stores all user uploaded images in a shared folder. Since our very first EPiServer project years ago, it was clear to me that we need to store these images in database. So we have built this Virtual Path Provider that uses ASP.NET infrastructure and have been able to plug it into EPiServer. It is always nice to know that the CMS system you have implemented your solution with, has a nice and pluggable architecture to fit your needs.

We have been using this Virtual Path Provider for years now, and since we find it very valuable we decided to open it to the world.

It is important to acknowledge that our implementation is based on EPiCode DatabaseFileSystem module . Unfortunately this module is only supporting EPiServer 4 which is rather old version already.

We collaborated with EPiServer Norway in order to clean up our code and make it work even better. Because of our previous requirements, we did not implement 100% all of the features that such a module such have. EPiServer helped us to find out weak spots and made code improvements.

Some of the features that we improved are:

• deep copy and delete of files and folders
• removing files from caches in load balanced environment
• running under scheduler context
• fixed threading issues
• dumping contents of database file system
• copy between existing VPP and database VPP

Why do we keep images in database instead of file system? Which approach you should take? Read my next blog post with more information about pros and cons.

You will be able to find the latest release of Database Virtual Path Provider at EPiServer Extras. Feel free to use it and give feedback!

UPDATE: Vladimir Terziyski from Propeople’s EPiServer team has published a nice wrap up on how to use VirtualPathUnifiedProvider in EPiServer. You can read it here.

Labels: EPiServer, Propeople

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 :)

Labels: EPiServer, Tools and Tips