While working on an Internet-facing website at some point you might include some code which should be executed only when in production. Probably the most common example of such code are web analytics tracking codes. The last thing you want is to make web analytics count a visit every time you hit F5 on your development machine. Find out how to deal with it other than disabling the Internet connection on your development machine.

See me not

Conditionally showing content on a development machine is not an easy task. The reason why it’s challenging has to do with two things: how to detect if you are on a development machine and how to use this information not to execute some parts of your website without too much performance penalty. Depending on your scenario and what you need to hide there are different approaches available to you. In this article we will focus on preventing web analytics from registering visits from your development machine.

Go off-line

Let’s assume that your web analytics system is not running on premise and it’s recording visits by listening to request for a particular file. Every time a request is made, the web analytics system registers the visit alongside with some other information about the visitor.

Since it all depends on Internet connectivity, probably the most obvious and the easiest solution would be to disable the Internet connection on the development machine. While it would definitely prevent developers from making fake visits to the site, it introduces a number of inconveniences.

Not being able to connect to the Internet on your dev machine means, that you have to update it manually and every time you need to find some information you have to go to another machine. Oh, and forget about copy & paste code fragments or downloading tools. Depending on your setup this might be workable but it remains pretty inconvenient.

Block it

Another approach that you might consider would be to block requests to the file either using a firewall or in browser. How viable this is depends a lot on your environment.

Windows Firewall doesn’t support blocking websites, so if you would like to do this, you would need a 3rd party firewall. Alternatively you might do this on a corporate level by disabling requests to web analytics files from developer machines. The downside is that it would apply to all sites using that web analytics system instead of just the site that developers are working on.

Alternatively you might block the file in the browser, but it might get challenging to maintain if you’re using different browsers to test your site with and it would also apply to all sites using this web analytics system.

Remove it (temporarily)

Another approach that you could think of would be to temporarily remove or to comment out the calls to web analytics files in your Master Page/Page Layouts. The downside of this approach is touching files that you might not necessarily need to modify. Not to mention not forgetting to uncomment it before deploying to other environments.

Debug mode

There is however yet another approach which introduces less maintenance and effort than other approaches I have just mentioned. It bases on a simple assumption that most developers run Web Applications on their dev machines in debug mode to be able to work with custom code easier.

Conditionally hiding content in debug mode

A while ago I introduced a framework for conditionally showing content the proper way – the ConditionallyVisibleControl control. The big advantage of using this control is that whenever it finds that the content shouldn’t be displayed, it doesn’t add it to the Controls collection what improves performance of the page. Using the ConditionallyVisibleControl control as the base we can create a new control that will hide content whenever it detects that the site is running in debug mode.

Let’s start off with creating the control:

public class SiteModeTrimmedControl : ConditionallyVisibleControl
{
}

After inheriting from the abstract ConditionallyVisibleControl class we have to implement the ShouldBeVisible property.

public bool Debug { get; set; }

public override bool ShouldBeVisible
{
    get { return Debug == HttpContext.Current.IsDebuggingEnabled; }
}

While we could create a control that displays the contents only when not in debug mode, it is much more useful to create a control that can do both. There might be scenarios when you need to display some content only when in debug mode and it’s easier to use one control rather than creating a separate control considering how little extra code it requires.

Using the SiteModeTrimmedControl control is very easy. Once you register the assembly with your Master Page/Page Layout, the only thing you have to do is to wrap the content that should be hidden in debug mode with the control as follows:

<Mavention:SiteModeTrimmedControl Debug="false" runat="server">
<ContentTemplate>
[conditionally visible content goes here]
</ContentTemplate>
</Mavention:SiteModeTrimmedControl>

If you need to display the content only when in debug mode all you need to do is to set the value of the Debug attribute to true.

And that is all: using the above approach you can conditionally hide content in debug mode and prevent your web analytics system to register fake visits.

Summary

Most Internet-facing websites include some content that should be displayed only when in production, such as web analytics. Showing such content on a development environment with Internet connectivity might negatively influence web analytics results and this is why it is highly desirable not to include such content on developer machines. The challenge is how to detect whether the site is running on a development machine to temporarily hide the content. Although there are a number of different approaches each one of them has its disadvantages. Using the debug mode detection is probably the easiest solution to implement as it doesn’t have any impact on the existing environment. The downside is that it isn’t fool proof. It depends on developers running their Web Applications in debug mode. While it might work in some environments with some developers it not necessary has to be the best option and you should always check what options you have before using this approach.

Technorati Tags: SharePoint