Welcome to part 5 of my tour through ASP.NET 4.0. In this instalment, we'll cover the updates to ASP.NET’s browser detection information and look at how they’ve made it easier to update that info without their help.
[Updated March 12 2010: Stephen Walther has more information on the updated browser definitions here.]
For those of us who remember the
golden years days of classic ASP, you’ll also remember browscap.ini. This was (and still is for some developers) the file where a list was kept of all the browsers in use and the capabilities that they each have. Want to know if IE1.5 (yes, 1.5) supported ActiveX? This is where that info was kept and then accessed using the BrowserCapabilities object in code.
Incredibly useful for such a small file (~60KB), it was also in perennial need of update. With each new (version of a) browser, and latterly smartphone, browscap.ini had to be updated. Microsoft’s original intention was to update the file itself, but this quickly didn’t happen, so a number of independent efforts were made. A gentleman named Juan T. Llibre used to do it (I don’t know if he still does) as did a company named CyScape, although they’ve since ceased this to push their browserhawk component instead which actually does more than the ini file can. These days a gentleman named Gary Keith maintains browscap.ini on a weekly basis and maintains a good FAQ on how to use it in your projects.
For .NET 2.0, Microsoft shelved browscap.ini in favour of *.browser files. As a browser was identified via its requests to the server, its capabilities are then pushed into a HttpBrowserCapabilities object found a Request.Browser in your code. A great demo of this can be found at http://browserdetection.codeplex.com.
Here are all the *.browser files for .NET 2.0. You’ll find them in C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers.
Far more complicated to maintain than the ini file, the idea is to keep info for each family of browsers in its own file. Default, ie, mozilla and a few others all sound familiar, but Jataayu (now owned by Comviva), Xiino (a browser for Palm OS last updated in 2006) and a few others might not be instantly recognizable.
In .NET 4.0, all the .browser files have been revised and, in some cases, deleted. Now the system knows about today’s mobile phones - iPhones, Windows PhoneOS, Android – and won’t believe that most mobile phones use WAP. All the files for our desktop browsers have been revised too with new ones added for Firefox, Chrome, and Safari.
Which is good, but how to keep things up to date? Do our .browser files require another Gary Keith?
Keeping Up To Date
There’s always another new browser coming round the corner. In the very near future, IE9, Opera 10.5, Gecko 1.9.3 and the mobile version of IE for Windows 7 Phone will all come out, but the chances are that Microsoft won’t update the *.browsers for us. To keep our applications in the loop then, we have four choices.
- Update an existing \ create a new *.browser file and update your entire system
- Create a *.browser file and add it to the App_Browsers folder of a particular website, therefore updating just that website.
- Extend the existing browser capabilities provider and bend it to your will.
- Create your own custom browser capabilities provider and use that instead going forward.
How-tos for all four approaches can be found
In conclusion, keeping up to date with browsers is a hard thing to keep on top of but there are ways and means to do so, thanks to some people’s dedication to the problem, a new set of *.browser files in .NET 4.0 and the addition of an extensibility point into the browser capabilities provider.
Until the next time, happy coding!