VirtualPathProviders - A Note on Project Types
I was working with VirtualPathProviders today for an upcoming talk at Tech Ed. VPPs are a technique whereby you can vitalize basically the entire content of your site off of the file system, for instance by reading your actual aspx files out of a database (as SharePoint does) or from some compiled source (one of the options in ASP.NET 2.0) or perhaps from a single zip file (well, it's a sample on the MSDN site, I didn't say it was a good idea).
Back to my story, I had written a VPP, but I couldn't seem to get my sample Provider to work. Every time I hit the URL I was testing, I kept getting a 404. In fact, I couldn't even get a breakpoint to be hit in the initialization code for the VPP:
public static void AppInitialize()
{
HostingEnvironment.RegisterVirtualPathProvider(new MyVirtualPathProvider());
}
Initially, I was coding for a 'foo' file extension, but I learnt quickly that there are some additional steps involved if you want to offer non-standard file types (follow the link for a nice sample KB for implementing a VPP), and I was trying to keep it simple. Still no luck. I did discover that there are 2 ways you can register your VPP - the first is via the static AppInitialize method (as above) in the class itself. The second is to add some code to the global.asax (or code behind equivalent), as follows:
protected void Application_Start(object sender, EventArgs e)
{
HostingEnvironment.RegisterVirtualPathProvider(new MyVirtualPathProvider());
}
This worked fine, but I don't like not knowing why something won't work, so I contacted David Ebbo, who realized I was working in a web application project, rather that a web site project. I tested to confirm, but he informed me that the AppInitialise approach only works in the latter project type (in the App_Code folder, or course). In a web application project, you have to use the global.asax file. However, this approach appeals to me more anyway because it centralizes the registration of VPPs, which is at least more akin to something like using the web.config file (something you can't do with VPP because what if you wanted a VPP for your config file - how would you register it?).
Incidentally, here some other uses of VirtualPathProviders
1) A CMS solution (Scott Guthrie has a sample on this somewhere, I think)
2) Getting around some ASP.NET 2.0 Themes problems
3) sharing a master page across web applications
(thanks to K. Scott Allen for those last two)
[Update: David informs me further that the web.config, together with a couple of other things (e.g. App_Code and App_Data) cannot be virtualized, so it's really aimed at actual content files (aspx, ascx, master files, images, css, etc.) - Thanks David]