• Published
  • 1 min

Virtual path registration tip

<p>Virtual path providers must be registered in a specific order to work correctly. This blog post contains some of the findings I did while uprading a site to CMS 6.</p>

I'm currently upgrading a large site from CMS 5 R2 to CMS 6 R2. One of the issues I had after upgrading the site, was that the file explorer crashed every time I tried to open it. The exception I got was “Unable to cast object of type 'EPiServer.Web.Hosting.VirtualPathNonUnifiedProvider' to type 'EPiServer.Web.Hosting.VirtualPathUnifiedProvider'.”

I found the solution to this problem on this forum post: http://world.episerver.com/Modules/Forum/Pages/thread.aspx?id=51424 I moved all the VirtualPathNonUnifiedProvider registrations to the end, and the file explorer problem was fixed.

After a few days, I noticed that our custom UI pages were not working. The default EPiServer pages kept coming up instead. The virtual path registration looks like this:

<add showInFileManager="false"
    virtualName="CustomeNewPageMapping"
    virtualPath="~/episerver/CMS/edit/NewPage.aspx"
    bypassAccessCheck="false"
    name="CustomerNewPageMappingVPP"
    type="EPiServer.Web.Hosting.VirtualPathMappedProvider,EPiServer" />

and we have a virtual path mapping registered like this:

<virtualPathMappings>
    <add url="~/episerver/cms/edit/newpage.aspx"
mappedUrl="~/cms/edit/newpage.aspx" />
</virtualPathMappings>

I tried debugging my custom NewPage.aspx, but it did not get called. I tried moving the VirtualPathMappedProvider registration to the end, after the VirtualPathNonUnifiedProvider registrations. After doing so, EPiServer started using my custom NewPage.aspx page again. And, the file explorer is still working :-)