In Case Your Compiler Decides to Take the Day Off…

02.19.2011 06:24 by kbeckman | Comments

The following is noteworthy because this is the type of unit test a conscious developer would write if their C# compiler occasionally takes the day off…


public interface IMyInterface
    void MethodThatDoesntMatter();

public class MyClass : IMyInterface 
    public void MethodThatDoesntMatter() { return; }


using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Test.WastingYourTime
    public class MyClassTest 
        public void ImplementsIocInterface()
            Type interfaceType = typeof(IMyInterface);
            Type concreteType  = typeof(MyClass);



The problem is… Unlike the developer who wrote this unit test, the C# compiler doesn’t take days off. The .NET compiler also doesn’t waste valuable development time with senseless Internet browsing or BBQ recipe research. Just because you can test that a class implements a certain interface doesn’t mean you should waste your time doing so.

Losing Your Street Cred…

12.16.2010 21:03 by kbeckman | Comments

I just introduced a new category for C4SC posts – Losing Your Street Cred. The other day after seeing a particularly alarming exception cross my inbox, I felt the need to share. This particular item is the inverse of the widely-known cliché, “Saving the Best for Last”. We’re actually starting with the best here as I don’t imagine I’ll run into anything as disturbing anytime soon. Moving forward, I will be using Losing Your Street Cred to call out things that don’t do a lot of good for your street cred as a professional software developer.


And now for the charter member of the Losing Your Street Cred category…


The following exception is courtesy of a recent check-in by one of our 3rd party development partners. I thought I’d share because I had never seen this exception in 8+ years of .NET development. NEVER. I’m sure most of you haven’t either. If this was an isolated incident, I might have thought it was just a simple mistake, an exclusion in the developer’s SQL Compare script or a hiccup in one of the new Entity Framework features that creates your DB schema for you. Unfortunately none of those were the case and we’ve been plagued by chronic rookie-like mistakes exactly like this one for the last few months. This one in particular was the worst so far…


Server Error in '/' Application.

Can't perform Create, Update, or Delete operations on 'Table(SomeTable)' because it has no primary key.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details:
System.InvalidOperationException: Can't perform Create, Update, or Delete operations on 'Table(SomeTable)' because it has no primary key. 


Yep, that was a table without a primary key… It’s really not necessary to say much else here except that you’ll have little to no street cred left after a mistake like this. It’s amazing the type of issues you can prevent by actually testing a fix in an integration environment (or at a minimum, on your local machine) before considering something fixed. And please, if you ever make a mistake like this, just fix it instead of trying to explain it away. Your peers just might have a shorter memory that way…