Category Archives: 12761

Is Your ASP.NET Development Server Not Working?

Since Visual Studio 2005, Visual Studio comes with a development web server: the ASP.NET Development Server.

I’ve been using this web server for simple test projects since than with Visual Studio 2005 and Visual Studio 2008 in Windows XP Professional on my work laptop and Windows XP Professional, Windows Vista 64bit Ultimate and Windows 7 64bit Ultimate at my home desktop without any problems (apart the known custom identity problem, that is).

When I received my new work laptop, I installed Windows Vista 64bit Enterprise and Visual Studio 2008 and, for my surprise, the ASP.NET Development Server wasn’t working.

I started looking for differences between the laptop environment and the desktop environment and the most notorious differences were:





Windows Vista 64bit Enterprise

Windows Vista 64bit Ultimate

Joined to a Domain






After asserting that no domain policies were being applied to my laptop and domain user and nothing was being logged by the ant-virus, my suspicions turned to the fact that the laptop was running an Enterprise SKU and the desktop was running an Ultimate SKU. After having problems with other applications I was sure that problem was the Enterprise SKU, but never found a solution to the problem. Because I wasn’t doing any web development at the time, I left it alone.

After upgrading to Windows 7, the problem persisted but, because I wasn’t doing any web development at the time, once again, I left it alone.

Now that I installed Visual Studio 2010 I had to solve this. After searching around forums and blogs that either didn’t offer an answer or offered very complicated workarounds that, sometimes, involved messing with the registry, I came to the conclusion that the solution is, in fact, very simple.

When Windows Vista is installed, hosts file, according to this contains this definition:       localhost
::1             localhost

This was not what I had on my laptop hosts file. What I had was this:

#       localhost
#::1             localhost

I might have changed it myself, but from the amount of people that I found complaining about this problem on Windows Vista, this was probably the way it was.

The installation of Windows 7 leaves the hosts file like this:

#       localhost
#::1             localhost

And although the ASP.NET Development Server works fine on Windows 7 64bit Ultimate, on Windows 7 64bit Enterprise it needs to be change to this:       localhost
::1             localhost

And I suspect it’s the same with Windows Vista 64bit Enterprise.

A TraceListener For Tests

In my code, I make extensive use of debug assertions (see System.Diagnostics.Debug.Assert). These assertions are very helpful while debugging because you don’t need to step into every line of code to see if all pre-conditions are met. As soon as a pre-condition fails, an assertion failed window will pop up and will allow us to either abort, ignore or go to the assertion instruction (retry).

Imagine you have this code:

private void IKnowForSureThatANullStringWillNeverBePassed(string text)
    System.Diagnostics.Debug.Assert(string != null, “text is null.”);

    // …

Because this method is private, I have full control of what is passed to the text parameter, therefore I’m asserting that it will never be null. Because it might not be obvious that text will never be null, the assertion also acts as documentation.

I usually run my unit tests and integration test on debug compilations and these assertions would be helpful by making the test fail on an assertion fail instead of running through the method and failing with an NullReferenceException. That’s why I (and more people out there) wrote this simple TraceListener:

public class TraceListener : global::System.Diagnostics.TraceListener
    public static readonly TraceListener Default = new TraceListener();

    protected TraceListener()
        this.Name = “Testing Trace Listener”;    

    protected TraceListener(string name)
        : base(name)

    public override void Write(string message)

    public override void WriteLine(string message)

    public override void Fail(string message, string detailMessage)
        var builder = new global::System.Text.StringBuilder();


        if (detailMessage != null)
            builder.Append(” “);

        throw new global::Microsoft.VisualStudio.TestTools.UnitTesting.AssertFailedException(builder.ToString());


This trace listener won’t write anything to anywhere. It will just throw an AssertFailedException if the Fail method is called, which is what happens when an assertion fails.

Because an assertion window is not desired when running the tests (specially if they are automated tests ran as part of a build process) it’s better to disable the assert UI on the configuration file of the test project.

<?xml version=1.0encoding=utf-8?>
        <assert assertuienabled=false/>
                <add name=TestTraceListenertype=PauloMorgado.TestTools.VisualStudio.UnitTesting.Diagnostics.TraceListener, PauloMorgado.TestTools.VisualStudio/>
You can find this and other tools on the PauloMorgado.TestTools on CodePlex.