VirtualPathProvider adventures: how to wire it up
Disclaimer: all of my findings are on the Beta 1 release
In my previous post, I told about the VirtualPathProvider that is part of the ASP.NET 2.0 architecture. Scott Guthrie told about it in his presentation at the European ASP.NET roadshow. There is a sample online on his site (it's the one from VSLive Orlando). In the sample, a website is created that contains only C# files in the Code directory and an Access database. The only table in the MDB file looks like this:
Note that the database actually contains all of the code for the ASPX pages and the code-behinds that would normally be on the file system. In the Code directory, there is a DBFileProvider.cs class. This class derives from System.Web.Hosting.VirtualPathProvider and whenever the ASP.NET engine needs to read a “file”, it actually calls into this class.
That is all very cool; you could use this kind of functionality very nicely in CMS's (every developer still works on his own CMS that will be better and more user friendly? Of course you are!). Here is the strange part: there is no web.config. So how does the ASP.NET runtime know which class to load? In the sample from Scott, the trick is done in a static method called AppInitialize(). If the Code directory in your project contains a class that has a method with this signature:
public static void AppInitialize()
the engine will call this method when the application is starting up. If you have more than one class with this method, VS.NET 2005 will give a build error. The in this method you can register the provider:
WebConfigXInclude.ConfigPathProvider fileProvider = new WebConfigXInclude.ConfigPathProvider();
HostingEnvironment.RegisterVirtualPathProvider(fileProvider);
After finding out how the registration of the provider works, I concluded that this was done in this way to allow the web.config file to be loaded through the VirtualPathProvider as well. You can't configure the provider for reading the configuration in the configuration. That figures. However, this turns out not to be the case. I will write about my unfruitful attempts to run from a virtual web.config in my next post.
What I really don't understand: why did the very smart guys developing the ASP.NET engine decide to use a “special method name”? They could have used a special interface. What exactly will happen when you have a current .NET 1.1 application that contains several classes with an AppInitialize() method in them? Or only one that expects an HttpContext available?