Supporting precompiled websites


Published: 6/20/2012, Author: Håkan Edling Categories: Programming, .NET, 0 Comments

In most cases deploying your website precompiled doesn't impose any problems. However, if you have a more complex structure utilizing virtual path providers you will soon run into a brick wall. So did we when trying to deploy a site yesterday.

Yesterday, when configuring a Piranha site to be deployed at City Network we ran into a classic problem. The hosting provider had decided only to support precompiled websites without just in time compilation. Of course, getting the site precompiled is only a matter of how you deploy it, but as always there's always the odd chance of something breaking.

At first glance everything seemed to work fine, apart from getting extensionless routing on IIS 7 to work. But when trying to access the manager interface it all went south throwing us exceptions that the views were missing. After a little research it turned out that Microsoft for some reasons unknown have decided to turn of RegisterVirtualPathProvider for precompiled websites.

[AspNetHostingPermission(SecurityAction.Demand, Level=AspNetHostingPermissionLevel.High)]
public static void RegisterVirtualPathProvider(VirtualPathProvider virtualPathProvider)
{
    if (_theHostingEnvironment == null)
    {
        throw new InvalidOperationException();
    }
    if (!BuildManager.IsPrecompiledApp)
    {
        RegisterVirtualPathProviderInternal(virtualPathProvider);
    }
}

With a little help from the following article and the magic of some really dirty reflection (meaning reflecting private members and methods from a core .NET class) it now works like a charm. We'll keep our eyes open for what happens in the next version of the .NET framework, hopefully Microsoft decides to resolve the issue so we can remove the reflection code and carry on doing things the proper way.


blog comments powered by Disqus