Monday, September 27, 2010

Detecting Google Chrome in ASP.NET code behind



We recently got a requirement to detect the browser type and browser version in our cross browser compatible application. Now, immediately we had two choices. Either we can do this from the Javascript or through code behind. We opted for the later due to the ease of implementation.

There are 2 ways (of which I am familiar) by which we can achieve this:


Using System.Web.HttpBrowserCapabilities Class which includes a Browser property through which
we can get Browser, MajorVersion and MinorVersion.
(MSDN Article)
 
(Or)
 
Using Request.UserAgent Property through which we can get the raw user agent string of the client browser.
(MSDN Article)
 
We went for the former approach and quickly found out that since Google Chrome and Apple Safari are both based on the WebKit layout engine, Browser.browser returns “AppleMAC-Safari” for both browsers!

When we try to get the user agent string, it however makes more sense, see below:


For Safari:


"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.17"

For Chrome:


"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.30 Safari/525.13"


So in order to distinguish between Safari and Chrome, we added one more step to the process i.e. We check the UserAgent String to see if it contains Chrome keyword.
if (Request.UserAgent.ToLower().Contains("chrome"))
{
strBrowserType = "Chrome";
}

That seemed to solve the issue of browser recognition!

Thursday, September 23, 2010

Issue with MOSS 2007 Central Administration



Out of the blue, the Central Administration (CA) in the development server started acting up today (Unknown Error on accessing the CA). Although, except for a new custom web part that I hosted today, there were not any changes to either IIS or web.config.

So I went about the usual steps taken for working around any issues with MOSS listed here:

i. Switched Custom Errors off and enabled Call Stack (more info here)

ii. Received the following error on accessing CA again:


The DataSourceID of 'QuickLaunchMenu' must be the ID of a control of type IHierarchicalDataSource. A control with ID 'QuickLaunchSiteMap' could not be found.



Finally, after a lot of tinkering around, I found the following in the section of the web.config:

This made no sense as I had not done any recent changes to navigation options especially around the CA.

iii. So I focused my attention on the recently deployed custom web part, and went about retracting and uninstalling the web part. Still no luck!

iv. So I went back to the web.config and compared it with an older copy of the same, still I could find no new changes!

<providers>

<add name="AdministrationQuickLaunchProvider" 
description="QuickLaunch navigation provider for the central administration site" 
type="Microsoft.Office.Server.Web.AdministrationQuickLaunchProvider, 
Microsoft.Office.Server.UI, Version=12.0.0.0, Culture=neutral, 
PublicKeyToken=71e9bce111e9429c" />
</providers>


So after pondering over it a lot thought of changing the trust level from Custom to Full. This seems to do the trick! The CA is back up!


But still a lot of questions left unanswered. What caused the issue in the first place? And what got changed which was not addressed by the custom trust? Leave your opinions or recommendations in the comments below!