Logo
Spacer
 
Company Services Portfolio Contact  
 
Spacer
Logo
 
Logo
Bullet Overview
Bullet Expertise
Bullet Methodology
Bullet Press Room
Corporate News

Events & Tradeshows

Articles & Resources
ASP.NET
PHP
Linux
Staffing Solutions
IT News
Outsourcing News
Bullet Careers
 
 
 
 
Home / Company Pressroom - Articles & Resources / ASP.NET
 
 
 
ASP.NET

 

Creating a Custom Browser Setup with ASP.NET 2.0


ASP.NET 2.0 has a wealth of new features to offer: everything from an improved security model to new controls. However, the most interesting new feature for many developers may not ASP.NET's improved widgets for developing applications, but the improved control that custom browser setups can provide. Instead of waiting for Microsoft to add support for a particular browser, you can add this functionality yourself using a specially formatted .BROWSER file.

The old method of detecting a browser relies on BrowserCap.DLL. This DLL detects the user agent entry, provided by the client machine, by using a simple wildcard match. It then looks in the BrowserCap.INI file to locate information about that browser. Listing 1 shows a typical example of a BrowserCap.INI file entry.

Listing 1. A Typical BrowserCap.INI Browser Entry.

[IE 6.0]
browser=IE
version=6
majorver=6
minorver=0
css=2
frames=True
iframes=True
tables=True
cookies=True
backgroundsounds=True
vbscript=True
javascript=True
javaapplets=True
activexcontrols=true
cdf=True
aol=False
beta=False
win16=False

There isn't anything too mysterious about this file. Its settings define whether the browser includes support for specific features. In fact, you can extend BrowserCap.INI to include custom entries; or you can add entries for other browsers, by simply creating a new key, like the [IE 6.0] entry shown.

The problem with this technique is twofold. First, the setup relies on a wildcard search, which means that more than one browser could match the search criteria. The system always uses the first matching browser, so some clients might receive the wrong information based on an incorrect set of capabilities. Second, using this technique means that you must add a new entry for every new version of a browser. When Microsoft introduces Internet Explorer 7.0, you'll need to add an [IE 7.0] key.

Developing a New Approach in ASP.NET

Microsoft sought to make things easier when it introduced ASP.NET. Hidden deep within the Machine.CONFIG file (found in the \WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG folder) is a special section called <browserCaps>. This section contains a series of XML entries that define the configurations for various browsers based on a regular expression. This entry is relatively long, but its most interesting feature is a series of case statements. Listing 2 shows an example of these entries (very much shortened for this article).

Listing 2. A Typical Machine.CONFIG Browser Entry

<browserCaps>
   <use var="HTTP_USER_AGENT"/>
      <case match="WebTV/
      (?'version'(?'major'\d+)(?'minor'\.\d+)(?'letters'\w*))">
      browser=WebTV
      version=${version}
      majorversion=${major}
      minorversion=${minor}
      tables=true
      cookies=true
      backgroundsounds=true
      isMobileDevice="true"
      <filter match="2" with="${minor}">
         javascript=true
         ecmascriptversion=1.0
         css1=true
      </filter>

These entries are an improvement, because they provide several features that the INI file could not. Notice that the version number of a browser need not impair the functionality that your application can provide. The system assigns the information it finds in the HTTP_USER_AGENT header entry — supplied by the client — to the browser capabilities output. In addition, you can add filters to assign specific information based on version.

Using this information is also relatively easy in ASP.NET. All you need to do is obtain access to the Browser object supplied as part of the request. The following code displays the browser name and version number.

Response.Write(Request.Browser.Browser.ToString());
Response.Write(Request.Browser.Version.ToString());

The only problem with the Machine.CONFIG setup is that few people know that it exists. In addition, Microsoft doesn't make updates to these entries. If you look earlier in the file, Microsoft tells you to obtain updates for this file from cyScape, Inc. as shown here.

<!-- For updates to this browser data visit cyScape, Inc. at
http://www.cyscape.com/browsercaps -->

Unfortunately, cyScape is very slow about providing updates for new browsers, which means that it's likely that you won't find the update you need. Fortunately, a couple of other .NET developers are making the process a little easier. You can find updates for the Gecko, Safari, and Konqueror browsers on Rob Eberhardt's Web site. An update that permits detection of the Windows 2003 platform appears on Gary Keith's Web site.

Understanding the .BROWSER File

Working with Machine.CONFIG every time you want to make a browser change is difficult. You have to locate the correct section and hope that you don't make a mistake entering the new information. In addition, it's easy to overwrite the changes you make, which means you have to start all over again.

Obviously, you need a better way to add new browsers to ASP.NET, which is precisely what ASP.NET 2.0 does. A .BROWSER file defines the parameters of a particular browser using XML entries, similar to those found in the Machine.CONFIG file, but using a separate file for each browser. You add a new browser by adding a new file to the folder. You'll find the ASP.NET 2.0 .BROWSER files in the \WINDOWS\Microsoft.NET\Framework\v2.0.40607\CONFIG\Browsers folder of your system.

Unlike the Machine.CONFIG entries, those in a .BROWSER file use real XML to present information. The files also have a consistent and easier to understand appearance. Even better: you get all of this additional functionality and ease-of-use without any changes to the code you create. Accessing client information is still as easy as using the Request.Browser object.

Listing 3 shows part of a typical .BROWSER file.

<browsers>
  <browser id="IE" parentID="Mozilla">
    <identification>
      <userAgent match="^Mozilla[^(]*\([C|c]ompatible;\s*MSIE
          (?'version'(?'major'\d+)(?'minor'\.\d+)
          (?'letters'\w*))(?'extra'[^)]*)" />
      <userAgent nonMatch="Opera" />
      <userAgent nonMatch="Go\.Web" />
      <userAgent nonMatch="Windows CE" />
      <userAgent nonMatch="EudoraWeb" />
    </identification>

    <capture>
    </capture>

    <capabilities>
      <capability name="browser"        value="IE" />
      <capability name="extra"          value="${extra}" />
      <capability name="isColor"        value="true" />
      <capability name="letters"        value="${letters}" />
      <capability name="majorversion"   value="${major}" />
      <capability name="minorversion"   value="${minor}" />
      <capability name="screenBitDepth" value="8" />
      <capability name="type"           value="IE${major}" />
      <capability name="version"        value="${version}" />
    </capabilities>
  </browser>

ASP.NET 2.0 adds another wrinkle to the whole issue of working with browsers. Instead of forcing the server to read an INI or CONFIG file every time it requires browser information, ASP.NET 2.0 provides a means to create a class factory from the information. After you add a new browser to the setup, you run the AspNet_RegBrowsers tool. This tool creates the required changes that allow the server to access the new browser information. You don't have to shut down any of your applications, because the information isn't cached as part of the application. In addition, because of the way the .NET Framework does store the information, you receive a significant performance boost.

The .BROWSER files let you specify a few new items. The most important is a control adapter. This element defines a specific behavior for controls based on the browser's capabilities. In short, these entries modify the behavior of the control globally, so you don't need to perform the change in your code. Here's an example of a control adapter for Internet Explorer.

<controlAdapters>
   <adapter controlType="System.Web.UI.WebControls.FileUpload"
adapterType="System.Web.UI.WebControls.Adapters.HtmlFileUploadAdapter"/>
</controlAdapters>

In this case, the control adapter modifies the behavior of the FileUpload control, but you can attach a behavior to any control. You won't find this entry in the Mozilla.BROWSER file because the Mozilla browser doesn't provide the required support.

 1 -  2 -  Next 


 
 
 
 
 
© 2005 Invengence
e-mail: info@invengence.com