Virtual Path Providers in ASP.NET 2.0
I ran across something very interesting a couple days ago in ASP.NET 2.0 called the VirtualPathProvider. Essentially, it's some ASP.NET infrastructure that abstracts ASP.NET from using the file system directly, and it allows you to "hook in" to it all and serve pages from something other than the file system.
Because the documentation is a little sparse, and because it looked pretty cool, I dug into it, created a sample, and wrote up a short essay about it. The sample can be downloaded from that page.
I think it has some very interesting possibilities. In particular I'm thinking of using it for the blog to do what most blogging platforms do with url rewriting. Currently the pages are viewed on the site through a generic viewer page with a variable in the query string (which is less cool). This would allow me to do something like /2007/3/15/ThisIsMyBlogPostTitle.aspx.
What I would really like to know is what are the advantages and disadvantages of implementing this with either approach. I see how they're both done, and the the virtual path provider way seems like a cleaner approach. Am I missing something? I know for many, like Community Server, that this would not have been an option when the platform was originally written since this is new in 2.0. But I haven't really heard much of a peep on this thing. Is no one else thinking about it? Are you community server folks thinking about it? Anyway, I would love to hear anyone's thoughts. It seems like a cool technology...
Comments
Anderson Imes 2007-04-03 11:42:13
The VPP has been a big tool I've used in the last couple of months. It's definitely exciting and has a lot of uses. It's hard to know when to use URL rewriting vs. the VPP. I think you can basically break it down like this:
Sometimes you have to use these things in tandem, as well. It really just depends on your need.
Hope this helps.
Eric 2007-04-04 09:23:52
Thanks for the comment. After thinking more about it now, that's not quite the distinction I would draw. I went ahead and wrote up a new post about the distinction between the two. Essentially, I'm coming to the point where I think that now that 2.0 is out, they're just technologies that have two completely different functions. Because of the lack of the VPP in 1.x, url rewriting was necessary. Now that VPP arrived, maybe we should make url rewriting just about path rewriting, and not about virtualizing content. Anyway, I write a little more in my more recent post. Thanks for the comment! I'm still thinking through this whole thing in my head...
Anderson Imes 2007-04-04 02:46:38
I think that's pretty much what I was saying. Redirect to a different place: rewriting. Execute content located somewhere besides the filesystem: VPP.
Your writeup is very accurate. Good job.
Xander 2007-04-10 09:50:48
One other thing to think about when using a VPP....If the information for loading data in a page is located in the querystring, VPP solutions get *very* expensive in a hurry, because the page for each unique URL that the VPP loads is cached. So, if you had a blog with twenty posts, and over the course of some period of time, people looked at all twenty posts, you would have twenty seperate pages cached by the VPP, where as with a URL-rewriting scheme, you wouldn't have to cache at all if you didn't want to, and if you did, you could use a far more effiecient scheme.
Eric 2007-04-11 10:24:04
I'm not sure how you could not customize your caching plan using a VPP. VPP's do not automatically do page caching, which means you can do page caching if you want, or just data caching, or a combination of both. What can you do in this respect with url rewriting that you can't do with the VPP?
Victor Mx 2007-04-25 12:16:03
Hi everyone,
I'm currently chossing between VPP and URL rewriting, but can you help me to choice?.
I try both of them and this are my experience:
With URL rewriting, i try it and i have the problem with postbacks, when the user make a postback, the page loaded was the real not the virtual :(
i.e. the virtual was: MyApp/hotel/Mexico/FiveStarHotel.aspx
the same real with query string is MyApp/hotel/info.aspx?hotel=FiveStarHotel.aspx
I use the tip of replace the Form action direction, but i get a new problem, the relative paths can be resolved because the folder count in my virtual (3) in my real (2) :( :(
With VPP in the same escenario, i can't handle the events of the page because the page it's loaded like file not an aspx page
Any suggestion?
Help me pls
P.D. Sorry my english are not so good
Eric 2007-04-25 12:50:43
Nothing obvious at the moment. I'd probably need to see the code to really get what the problem is. You can email it to me if you want. I'll take a quick look at it.
Xander 2007-04-30 05:27:01
VPP's do not automatically do page caching, which means you can do page caching if you want, or just data caching, or a combination of both. What can you do in this respect with url rewriting that you can't do with the VPP?
They *do* in fact get cached. Not in the traditional output cache sense, (standard runtime bits all still run, data can be output cached or grabbed fresh or what have you) but the virtual file itself is cached....The equivelent of what would have been the standard ASPX page.
Eric 2007-05-01 10:06:54
Okay, well that is a difference. Of course I suppose the aspx page you rewrite to would also be cached in the same sense :). Regardless, this is a pretty small difference, unless I'm missing something. But, perhaps a difference nonetheless.
Luke 2008-08-24 05:03:31
I know I am a bit late on this one but hopefully this still gets through.....
Firstly, great post, provides a bit more of an insight than the MSDN docs which helped me alot. I am using VPP for a few things, mostly for control libraries that you can distribute via dll's and I've run into some problems with VPP master pages not finding their associated css/image files when you deploy the project to a remote server. Everything works fine in my localhost but I just get 404 errors as soon as I upload....just wondering if you ever tried anything along these lines
Cheers