No, I'm not there. But I just watched the keynote live :). I must say, Microsoft continues to blow the developer in me away...
Archives: 4/2007
Update on the Silverlight, Firefox, Inline Xaml, and Xhtml Doctype Issue
Comments: (0)
I had to update my little article on the issue with Silverlight on Firefox using inline Xaml with an Xhtml doctype. Luis Miguel Abreu responded to an inquiry I made about it on the msdn forums and, frankly, his solution was better. So I updated the article and added his approach to the download. But, I'm still looking for alternatives if anyone has a good one...
You know, just typing out this issue is tedious. This problem is really easy to have, even though four conditions have to be met. But since most developers who deal with Silverlight probably run Firefox at least sometimes, and because an Xhtml doctype is the default for VS 2005, and because inline Xaml would be something that would probably be done often. It's a mouthful, but I'm guessing more and more people will have this problem. We need to have as much out on the web to help them out.
Silverlight, Firefox, Inline Xaml, and an Xhtml Doctype
Comments: (0)
So as I've played around with Silverlight the last few days, I've found a problem. It is supposedly an issue with Firefox, where Firefox doesn't parse some elements correctly when the doctype is set to Xhtml. Essentially, if you have Xaml inlined for Silverlight in a page, if the page has an Xhtml doctype, and you're using Firefox, Silverlight will not work for you. This is a problem...
I was quite irked today when I came across this. I did a little searching and found a little discussion on this in the MSDN Forums. The proposal was to remove the Xhtml doctype. That proposal doesn't sit well with me. I don't like the idea of changing a doctype just because a browser has a bug. So, I came up with my own proposal for dealing with this situation. It is more work than just removing the doctype, but I think it is a better solution regardless. Any suggestions or critiques are welcomed.
Silverlight is a new offering (it is still a CTP as of this writing of this) from Microsoft. You can find its home here. Silverlight is a cross-browser and cross-platform browser plugin for richer media/graphics on the web. Put more simply, think Flash. Many call it Microsoft's "Flash killer". We'll have to wait and see if that turns out to be true. Back in the early days of my tech life I was a Flash monkey, back in the Flash 5 and Flash MX era. I enjoyed it quite a bit. Then I started using Visual Studio. I was totally hooked, and have been since. At my job we started looking into porting our main application from a windows-based program to a Flash-based web application. I am sure I would have loved it in my pre-Visual Studio days, but going from the nice application design IDE of Visual Studio to the not very nice application design interface of Flash was painful. The Flash interface was excellent for making graphics, little games, and interactive tidbits, but trying to write a real application on that platform with Actionscript was not pleasant. I ended up moving on and to this day I am still very glad I didn't have to spend too much time doing app development in Flash.
My hope is that Silverlight will be able to fill that gap. I've already had some experience with Xaml working on Thrius, and I am quite impressed with Xaml. Maybe we'll soon see the full capabilities of Silverlight as more documentation comes out and we get closer to release. I'm still an ASP.NET junkie and Silverlight will not replace ASP.NET development for me, but it might just give me some capabilities that I didn't have before.
I'm sure Flash is better for app dev now than it used to be. I'm pretty sure Adobe is working on that. But if Silverlight turns out to be good, then I don't need to think hard about getting back into Flash. As of today I've spent about 8 hours messing around with it, so I can't know yet how good this is going to be.
Now all urls for viewing posts, viewing them by category, and viewing them in the archives, is complete. All courtesy of the VirtualPathProvider...woot!
Missing Css Files, Exceptions, and the VirtualPathProvider
Comments: (2)
Seriously, I am going to talk about stuff other than the Virtual Path Provider sometime...:)
So I noticed an oddity yesterday that I just had to track down. I had the path wrong on a css file reference of mine and this was causing an exception to be thrown. Odd, you say? Well, I thought so too. So here is how it actually happened.
When I added some VPP support (locally, not on the web yet) for my blog, I noticed that an unhandled exception was being thrown when I visited certain pages. I had never seen it before; it didn't directly affect user experience at all. I just happened to notice it because I log errors in Global.asax's Application_Error. So I looked at it and I noticed I had the path wrong on a rather inconsequential css file. So I thought to myself, "Why would an invalid css file path be throwing an error." So I followed the stack trace down on the error, and with Reflector, found the answer.
Surprisingly, it was related to the fact that I was now using a VPP. Down in the bowels of ASP.NET there is this StaticFileHandler class. It has a method called "ProcessRequestInternal". This method was called for the request for my css file. If you have a VPP registered, it takes a different path than otherwise. It checks to see if the VPP registered as the first VPP for the hosting environment is the MapPathBasedVirtualPathProvider, and if it isn't, it calls a method called RespondUsingVirtualFile.
Now this VPP thing works like the chain of responsibility pattern. Let's say you register a VPP called "FooVPP". The HostingEnvironment takes it current VPP, the MapPathBasedVirtualPathProvider, assigns it to the "Previous" property of FooVPP and sets FooVPP as its current VPP. If you register another VPP called "BarVPP", that one becomes the current, its previous is set to FooVPP, and its previous is still MapPathBasedVirtualPathProvider. So any request gets handled by BarVPP, and if it can't handle it, it hands it to FooVPP, who handles it if it can. If it can't, in then handles it to the MapPathBasedVirtualPathProvider and it tries to handle it. If it can't, nothing can, and you get a 404.
So, back to StaticFileHandler. It checks HostingEnvironment.UsingMapPathBasedVirtualPathProvider method, which will return false, because it checks to see if the top level VPP is the MapPathBasedVirtualPathProvider. In this case it is not, so it returns false. Because of that it called RespondUsingVirtualFile (in StaticFileHandler).
In RespondUsingVirtualFile it first creates a variable for holding an instance of VirtualFile, and it is of course null. Next it checks the whole chain of VPP's to see if the file exists. Because the path was wrong on the css file, the check comes back false. And therein lies the problem. The VirtualFile instance is only set if a file is found (which of course makes sense). If it doesn't find the file, then it throws a "File does not exist" exception, and then you have the end of this process.
So here's the takeaway lessons on this:
1. Don't have inconsequential css files.
2. Spell your paths right.
3. Be sure to pay attention to exceptions thrown in Application_Error. Don't throw any more exceptions than you need to.
Microsoft has some free training in Dallas May 3. See here for information. I'm signed up. Let me know if you're going so we can chat.
In my last post I discussed the virtual path provider in ASP.NET 2.0 the difference between using url rewriting and using the VPP (Virtual Path Provider model) to handle urls for content that doesn't physically exist in the normal folder structure. I've been thinking more about this and my thoughts are crystalizing, so I thought I would flesh them out in a post.
The more I think about it, I think comparing the two things is like comparing apples and oranges. Url rewriting is for taking a url you get and saying "no, I really want you to go here" under the hood. It's about redirection, though it isn't exactly redirection. The VPP system is about creating an extensible ASP.NET page lookup mechanism that keeps you from having to rely on the file system. If my definitions are basically correct, then using url rewriting for handling virtual pages in ASP.NET 2.0 is like using a wrench for a hammer to knock a nail into some wood (which is what I do when I can't find my hammer); it is using a tool for doing something that works but isn't the most ideal for a job. I don't think there was any other way of doing this in 1.1 because the VPP tool was not available, but now that it is (and given what the two techniques actually do), the VPP is the tool we should be using.
Now url rewriting obviously works for this, and is used for this thing on apache as well. And if someone has a system to do this built around url rewriting, it may not be worth rewriting just because ASP.NET 2.0 gives you a shiny new tool. But going forward, this makes sense. If you want to point a request in a different direction, use url rewriting. If you want to show content that doesn't depend on the physical file system structure, use the VPP.
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...
The ASP.NET Virtual Path Provider - An Example Implementation
Comments: (2)
I started reading Programming Microsoft ASP.NET 2.0 Applications: Advanced Topics
Read More on "The ASP.NET Virtual Path Provider - An Example Implementation" >>