Does your right click context menu look as messy as mine?

Anything in there that you’re not actually using?

Actually I think I spend several minutes every day just looking for stuff in my context menus. If you combine all the time I spend searching for the “Go to definition” or “Refactor > Rename” you could probably count hours in the period of a year. Yes, I know I should learn the keyboard shortcuts, but I would need to throw out a password to make room for another shortcut in my brain.

Did you know that you can clean up your context menus quite easily. Go to Tools/Customize…

Check the Context Menu checkbox and your context menus will appear as dropdowns where you can delete all the stuff that you don’t need. If you switch tab to Commands in the Customize window you can drag new Commands to your context menus. I, for instance like to have “Build” command on top of my right click, while editing code.

Now, go and make your life easier and get rid of all that crap you have in your context menus!

A new version of NUnit is released and there is a new way to handle expected exceptions. Until recently NUnit did this by putting an attribute on your test method, very much how MsTest still works.

[TestMethod]
[ExpectedException(typeof(NullReferenceException))]
public void NullReferenceExceptionTestInMsTest()
{
    /* Setup */
    string[] names = null;
    int numberOfNames = 0;

    /* Test */
    numberOfNames = names.Length;
}

You read by the method header that this test is throwing an exception. The test runner will catch the specified exception and try to determine if it was the expected exception thrown. The bad thing about this is that you put your assertion outside your test and that hurts readability. The NUnit team has conjured up the following solution.

[Test(Description = "Testing the new ExpectedException functionality in NUnit 2.5")]
public void NullReferenceExceptionTest()
{
    /* Setup */
    string[] names = null;
    int numberOfNames = 0;

    /* Assert */
    Assert.Throws<NullReferenceException>(

        /* Test */
        () => numberOfNames = names.Length);

    /* Assert that numberOfNames is still zero */
    Assert.That(numberOfNames == 0);
}

The assert is nicely put inside the test and you can actually assert that there were now side effects from the thrown exception. This is a major improvement. What bothers me is that it looks like my first assertion comes before the test. We all know that the test has to run first, because it is an argument that has to be evaluated, but this does not really look good either.

[Test(Description = "Testing the new ExpectedException functionality in NUnit 2.5")]
public void NullReferenceExceptionTest()
{
    /* Setup */
    string[] names = null;
    int numberOfNames = 0;

    /* Test */
    TestDelegate throwingCode = () => numberOfNames = names.Length;

    /* Assert */
    Assert.Throws<NullReferenceException>(throwingCode);

    /* Assert that numberOfNames is still zero */
    Assert.That(numberOfNames == 0);
}

Pretty neat, huh! Keep it up, NUnit team! You know that we all love you.

This thing jumped at me from behind.

The difference between member methods and extension methods is that an extension method is not a member of the class. It is a static method, called with a syntax that makes it look like a member of a class when it is not.

This means that calling an extension method when the member is null, will not cause NullReferenceException, and that is why you need to check arguments for null on all your extension methods.

Proven by following unit tests

// Written with MsTest as unit test framework
namespace LiteMedia
{
    using System;
    using System.Linq;
    using Microsoft.VisualStudio.TestTools.UnitTesting;

    [TestClass]
    public class VerifyClaim
    {
        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void FirstOrDefaultThrowsArgumentNullException()
        {
            /* Setup */
            string[] names = null;

            /* Test */
            names.FirstOrDefault();
        }

        [TestMethod]
        [ExpectedException(typeof(NullReferenceException))]
        public void UsingClassMembersOnNullReferenceWillThrowNullReferenceException()
        {
            /* Setup */
            string[] names = null;

            /* Test */
            string fail = names.ToString();
        }
    }
}

I would like to apologize that I totally forgot about people using the Web Developer Express Edition of Visual Studio. I’ve updated the download page with a version of the source that is supported on this platform.

Since MsTest is not available on this platform I’ve migrated that source to NUnit 2.5. The code is exactly the same except for some reference changes and attribute name changes.

Also note that you need to install the ASP.NET MVC 1.0 project templates, before your Visual Studio will accept the web project.

Thank you!

This post will describe how error handling works within Kino. If you haven’t already you can download the source from here, play around and tell me what you think.

As a consultant, my job is often to produce as many functions as possible, in as little time as possible with as high quality as possible. We all know that this a a big lie and that you have to spend time on quality to save time. But we’re also selling a service which is really about what the customer wants, and that we’ll give them even if it is an impossible task. The result will vary on how well the developers can handle stress.

Non-functional requirements

The most important requirements are often forgotten about in these stressful hunts for more functions. Following a logging strategy or measure that the performance of this application is good, is actually something that often is put aside. The same goes with error handling.

I have more than once tried to talk the clients into ordering an error page. “There won’t be any errors on our page” is what they’re thinking and they won’t spend money on something that will not return value.

As long as we haven’t figured out how to write bug free systems, you will need error handling. You’ll need to present the error to the users in a meaningful and respectful way. You will need to monitor errors so that you get them at the same time as the users, and you will need to follow up on errors that happen, so they won’t happen again.

Have you ever stared into a log file and noticed that most of the messages are junk and completely useless? There is no clear strategy and debug messages are logged as error all over the place.

Error logging modules and handlers

ELMAH is a plugin (if you’d like to call it that) to ASP.NET and it will help you monitor those errors in a consistent fashion. Anywhere on your website where a yellow screen of death occurs you will get an entry into ELMAH. You can choose to follow ELMAH by an RSS feed or just get the errors e-mailed to you. This is very useful as when the user calls in and reports the error, you already have it on your screen. Instead of getting the error explained to you (it was yellow, red with a lot of text) you can read it for yourself.

I would say that the most usefulness would be in development as you add this tool to your application the first thing you do, and then you show it to your client on the acceptance test environment. Not because they will find it useful to monitor their own errors, but they will be aware that this is important. They will get to see what errors are thrown in the application, question them and make sure that there are proper error handling in place.

How to set it up

Add the following to your web.config in each corresponding section.

<?xml version="1.0"?>
<configuration>
	<configSections>
		<sectionGroup name="elmah">
		  <section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah"/>
		  <section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah" />
		  <section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler, Elmah" />
		  <section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler, Elmah"/>
		</sectionGroup>
	</configSections>

	<elmah>
		<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data" />
	</elmah>
	<system.web>
		<httpHandlers>
			<add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />
		</httpHandlers>
		<httpModules>
			<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah" />
		</httpModules>
	</system.web>
</configuration>

Make sure that you have elmah.dll in your bin-folder and point your browser to http://[host]/elmah.axd

Download and read more here

http://code.google.com/p/elmah/

http://dotnetslackers.com/articles/aspnet/ErrorLoggingModulesAndHandlers.aspx