Brendan Enrick

Daily Software Development

Expression Blend Issue with Abstract Base Classes

Earlier, I wrote a post about using inheritance with Silverlight UserControls. The post shows really quickly how one can have their UserControl inherit from another class. One tip I’ll mention is that the base class can be abstract, but not if you plan on using Expression Blend. Generally if you have a class which shouldn’t ever be instantiate, you should make it abstract.

The issue is one that I discovered, much to my annoyance, the hard way. As it turns out Expression Blend is currently unable to give a preview of a UserControl that is inheriting from an abstract base class. When you open one of these in Blend you’ll get the Red Box of Death and in it is a message stating, “Exception: Cannot create an instance of “MyClass”.

Not exactly very helpful, but it does at least point you to the fact that there is something wrong with your base class. If you run into this make sure you know that you cannot use a base class. I believe that Blend requires a default constructor, and an abstract class has no constructors.

Solution 1

If you have control of the abstract class, you probably just want to make it a concrete class and hope no one is dumb enough to use it as a concrete class. This is actually a good place for a comment so you have a reminder of why the class is not abstract. Otherwise you might make it abstract again. The comment will also tip someone off that they can make it abstract if Blend ever supports this.

Solution 2

If you don’t have control of the abstract class, perhaps because it is in a class library you’re referencing, you will want to place a concrete class between your class and the abstract. This new class will be the one you specify in your XAML and is thus used by Expression Blend. This one adds an extra layer which really adds nothing and could cause confusion, so I would lean towards the other solution.

Silverlight UserControl Inheritance

One way in which we object-oriented developers try to achieve code reuse is by using inheritance. This allows us to have shared functionality in one place. Awesome we all know how to do this and it’s easy right? Try it in Silverlight for your UserControls. It is a little bit more challenging.

The problem we have is that we’re working with partial classes and these classes are trying to make things difficult for us. One of them is the noticeably declared one in the code behind file. The other one is created from the XAML file. The XAML file declares the base class it is inheriting from. In this instance it is the UserControl class.

Here are the steps required to use a different base class for your UserControls in Silverlight.

1. Create a class inheriting from UserControl and add your desired extras to the class.

2. Create a normal UserControl class and change the base class in the XAML file. You will need to declare an xml namespace for the namespace your base class is in, and use that namespace when declaring the base class.

<UI:MyBaseClass x:Class="MyProject.UI.UserControls.ConcreteImplementation"
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">

3. Change the inheritance in the code behind (.cs or .vb) file so that it is using the new base class. [Optional – Because of the way partials work you don’t need to declare this one as inheriting from the base class, but it does make things more obvious for someone using the code.]

Enjoy using your base class in Silverlight.

Working with Interfaces - Practical Uses

Expanding on an article I wrote a couple of years ago where I explained interfaces in C#, I’d like to explain why people should use interfaces. I received an email from a reader of my ASP Alliance article. He understands how interfaces work, but he’s trying to see why so many people are raving wildly about their greatness. His questioning of them is great, because it really is not obvious why interfaces are useful. Anyone who says otherwise is just trying to brag.

A couple of years ago, you wrote an article for ASP Alliance called "Understanding Interfaces." Once again, I saw how the code works, once again, I failed to see how it will benefit me.

Here's where everything breaks down for me: You create an interface with just method, property and event signatures. Then you inherit them in a class, recreate these same signatures and write the code to implement these methods and properties.

So I’ll start by mentioning that nearly all patterns, practices, principles, etc. in software development are based on code reuse. One of the most important reasons for code reuse is change. Developers are always responding to and creating changes. We must mitigate the risks of change, identify where changes will occur, and we must make changes.

Right about now you might be thinking, “but interfaces don’t reuse code. They just force you to implement new code. Using inheritance would be the way to achieve code reuse.” You ate technically correct. You understand how interfaces work, but you’re not seeing why we use interfaces. Interfaces themselves do not give us code reuse at all, however, they enable us to achieve code reuse.

Remember that I said that we must identify where changes will occur. Making this identification allows us to isolate changes thus mitigating the risks of changes and allowing us to make changes. Isolating the places that change also allow us the reuse the code which does not change, so by keeping some parts separate we can reuse others. The interfaces are for the places we can’t reuse the code.

Interfaces are “places of change”. Each implementation of the interface is a variation on how that required piece of the puzzle could have been implemented. This is contrary to how you’ll see a lot of interfaces used. It is sometimes difficult to see this as the behavior of interfaces, because people overuse interfaces.

As I see it, I could have saved a whole lot of time by not creating the interface in the first place! I mean, it's not doing any work. I still have to create the signatures in the class. Why on Earth do people praise these things and call them the answer to multiple inheritence? They don't do anything!

It is mostly true that interfaces don’t do anything. As far as being executable code is concerned an interface is basically just a worthless extra step, so why would we use them? Declaring an interface is like saying, “there is more than one way that this behavior could be implemented, but interactions with this behavior should be done this way only.” Having that common “interface” allows us to use any of these implementations interchangeably.

When to Use Interfaces

Some people would recommend that interfaces should be used everywhere. I’ve heard people say that no variable should be declared with a concrete type if it can be avoided. That may be a valid point, but if you’re just learning how interfaces can be useful that is a bad approach. If you don’t see value in interfaces, you will certainly not see the value of them when people use them everywhere. This washes them out and obfuscates their purpose.

Interfaces are used for logic which will have multiple or changing implementations. This means that we should use them in places where we will out of necessity have duplicate logic. Using the interface is what allows us to do this. Take a look at this code for composing a letter.

public string ComposeLetter(string recipientName, 
string messageBody, bool isFormal)
string messageText = string.Empty;
if (isFormal)
messageText += GetFormalGreeting(recipientName);
messageText += GetCasualGreeting(recipientName);

messageText += messageBody;

if (isFormal)
messageText += GetFormalSignature();
messageText += GetCasualSignature();

return messageText;

Notice how we have these flow control operators dictating how the code will execute. What will happen if we need to have a third option for greetings and signatures for family members? We might add another else-if or we might use a switch. Either way this code gets larger and changed every time.

However, if we identify the aspects of the code that are changing we can isolate them and mitigate the risks of changing the code by keeping separate the logic which has multiple implementations. Notice we have already used one form of encapsulation by keeping each of those pieces of logic in separate methods. The logic we haven’t encapsulated is the flow control.

We can create an interface for it. The best name I’ve got for now is IFormalityGenerator, which is not a great name, but it will do for now. I’ll create that interface with two methods: GetGreeting and GetSignature. Very simple interface. Now we can rewrite our method to look like this.

public string ComposeLetter(string recipientName, string messageBody, 
IFormalityGenerator formalityGenerator)
string messageText = string.Empty;

messageText += formalityGenerator.GetGreeting(recipientName);

messageText += GetMessageBody();

messageText += formalityGenerator.GetSignature();

return messageText;

We now just make the decision sooner and only once which implementation we are using. If this is a formal letter we will use the FormalFormalityGenerator. If it is casual we will use the CasualFormalityGenerator. Down the road when we create one for family members we can just go and create an implementation for the FamilyFormalityGenerator. We’ve made it so we create new code each time instead of going and changing the existing code in this method.

The power of an interface is in its ability to encapsulate the volatile aspects of a program and isolate that which can be reused more easily.

Users Don't Read Your Text

A few days ago Jeff Atwood wrote a great post about users. This is my post adding to his.

I also develop applications, and user interfaces is a common topic of discussion. The interface of an application is one of the most important aspects of it. What a lot of people seem not to realize and Jeff nicely highlights is that users don’t read anything. Trust me. I use a lot of applications, and I avoid reading anything that is more than six or seven letters long.

If I have to read something to use an application you’re probably going to lose me. I am not here to learn your application I am here to use your application. Jeff shows this image as what a user sees on Stack Overflow when writing a question.


I think he is a little bit off here. Why? Oh I don’t know, because he includes the preview. I might look at the preview, but only if I am concerned about how something is formatted. If I don’t think I did anything complicated I don’t bother checking the preview. I figure I should be able to use this page while only really reading this section.


When I need to reference something I will find it on the page. However, the 90% case is going to be this. I’ll make a decision if I need to look elsewhere, and I’ll be annoyed when I have to.

I use Stack Overflow and I think the interface is great Jeff. You support standard keyboard shortcuts, so I can learn what they do and how to format them by only observing the editor and occasionally the preview section. When I need a list I know to use the buttons at the top. Anything that is a standard convention I will follow. You give me a toolbar of choices and keyboard shortcuts and I’m set.

I think it is most important to follow common practice if you want things right. I am not sure why people have such trouble with Stack Overflow’s editor.

Working with the Default Layout of Silverlight RadCharts

The default layout for a RadChart works for most situations. It has a ChartArea, a ChartLegend, and a ChartTitle. These are easy to work with, and if you want you can break from the norm and create your own custom Silverlight Rad Chart layout. If you’re sticking with the default you almost certainly have some settings and properties to which you will want to make adjustments. In order to do that you might define these in the XAML.

<UserControl x:Class="MyApplication.UI.Charts.SuperSweetChart"
    Width="400" Height="300">
    <Grid x:Name="LayoutRoot" Background="White">
        <telerikChart:RadChart x:Name="Chart1" 
                        <chart:ChartArea LegendName="CustomLegend" NoDataString="">
                                <chart:DataSeries x:Name="DataSeries1" >
                                            ItemToolTipFormat = "#XCAT" 
                                            DefaultLabelFormat = "#%{p0}" />
                                    <chart:DataPoint YValue="35" />
                                    <chart:DataPoint YValue="15" />
                                    <chart:DataPoint YValue="55" />
                        <chart:ChartLegend x:Name="CustomLegend" 
                                           UseAutoGeneratedItems="True" />
                            <TextBlock Text="Traffic Sources"/>

Notice the three parts are the ChartArea, the ChartLegend, and the ChartTitle. Use the properties of these to make your adjustments. If you don’t want to change these in the XAML then don’t include them. If you’re going to work from the code behind it doesn’t hurt to have these here, but it can be useful.

You can access these in the code behind by either declaring their x:Name property or by referencing them from the RadChart’s x:Name like this. Chart1.DefaultView.ChartArea.

Plus keeping things in here keeps designers happy, and we design-challenged people really appreciate happy designers willing to assist us.

Implementing IEnumerable and IEnumerator

Working with a foreach loop is the primary reason to implement the IEnumerable and IEnumerator interfaces. You’ll want one of each of these to work with the loop.

I am going to do an example DateRange class which will implement IEnumerable<DateTime> and will allow us to iterate through a non-existent collection of DateTime objects.

Note: I am aware of the fact that I could achieve the same result with a for loop. I find the foreach loop more readable.

First we need to create a basic DateRange class. A range can be defined as a StartDate and an EndDate, so I’ll start there.

public class DateRange
    public DateRange(DateTime startDate, DateTime endDate)
        StartDate = startDate;
        EndDate = endDate;
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }

So this DateRange could be useful on its own, but we want to be able to iterate this collection using a foreach. So to start we need to implement the IEnumerable<DateTime> interface.

public class DateRange : IEnumerable<DateTime>
    public DateRange(DateTime startDate, DateTime endDate)
        StartDate = startDate;
        EndDate = endDate;
    public DateTime StartDate { get; set; }
    public DateTime EndDate { get; set; }
    public IEnumerator<DateTime> GetEnumerator()
        return new DateRangeEnumerator(this);
    IEnumerator IEnumerable.GetEnumerator()
        return GetEnumerator();


Notice here that we now need to get the IEnumerator<DateTime> object in the GetEnumerator() method. I jumped the gun a bit and I’ve called a class that doesn’t exist yet. I’ll make another class and implement the required methods for the IEnumerator interface.

public class DateRangeEnumerator : IEnumerator<DateTime>
    private int _index = -1;
    private readonly DateRange _dateRange;
    public DateRangeEnumerator(DateRange dateRange)
        _dateRange = dateRange;
    public void Dispose()
    public bool MoveNext()
        if (_index > (_dateRange.EndDate - _dateRange.StartDate).Days)
            return false;
        return true;
    public void Reset()
        _index = -1;
    public DateTime Current
        get { return _dateRange.StartDate.AddDays(_index); }
    object IEnumerator.Current
        get { return Current; }


These are the handful of methods we implement for the IEnumerator<DateTime> interface. These are all about moving to the next object and getting the current object. Resetting and Disposal of the object are less important, so make sure you read MoveNext and Current.

Keep in mind here that I could have used a collection for this, but I didn’t because I don’t need one. The calculation to get the items was easy enough.

var dateRange = new DateRange(DateTime.Today.AddDays(-6), DateTime.Today);
foreach (DateTime date in dateRange)



Visual Studio 2010 Beta 2 is Here

As of today Visual Studio Beta 2 is available to the general public. There is a VS 2010 Beta 2 iso available for download. It has some really nifty features. I’ve been playing around with it.

First off I will say that it actually looks very cool.


I think they did well. The new start page here is also a lot cleaner. I’ll be looking to see how to customize it a little.

Creating new projects is a lot better. Far less intimidating in this new default view. If they can keep the clutter down on this I will be very happy.


So I created an “Empty ASP.NET Web Application”. I noticed one crazy thing about it. I don’t think there are enough references here? Maybe we need more. C’mon guys. Seriously. Who wants to start with all of these in there? I chose the “Empty” one so I wouldn’t have all of this clutter.


But wait! They did remove the clutter. Guthrie had mentioned they were doing this. I am just now seeing the web.config and it is AWESOME!


There is barely anything in the web.config. Yipee! Hooray!

“Navigate To” is a nice feature. I already use ReSharper, so the wow factor is gone. I am glad to have it integrated though.


We were able to move the editor window around in previous versions of Visual Studio, but this feels a lot nicer, and anyway it’s still useful. Grab an editor window and decide where to put it. Much more freedom for splitting the screen this way.



You can do stuff like this. And have three editors open at once (you better have a lot of screen real estate before you try this).


Or if you actually use the designer in Visual Studio you can split it along with the code behind file. Getting you the Design, Source, and Code Behind.


This looks like a pretty nice thing they’ve build here. I figured with the big changes they were making that this version of VS would be lacking in too many upgrades. It seems they’ve managed to pull off some nice stuff here.

I am sure I’ll discover more new stuff at some point. Luckily the same feel is here, so just need to learn all of the little changes and additions.

When Should You Comment Your Code

Comment your code when it is hard to understand or determine your intent, because your code is crap. Yep, that is pretty much the best time to comment your code. When I was in college I was told to make sure that I commented my code. I always wondered why. Now I know. Comments really tended to clutter things and make it less clear what I was trying to achieve. I’ve written plenty of comments, but I know that when I use a comment that it means my code sucks.

Comments take time to write, they take up valuable space, they add clutter, and they’re often out of date. So why do we write them? We write them because there is something confusing about some code. Or something that we need to tell future readers about the code.

I very much enjoy being reassured of the way I do things by the books I read. I’ve been reading Code Complete, and it makes me glad they I blatantly disagreed with the people who told me to comment my code. Why? Because the author of the book tells me the exact opposite. I’ve often used the phrase, “code should be self-documenting.” I am not sure from whom or from where I first heard that, but it also affirmed my belief about comments.

The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.

Aside from the misuse of the English language, that is an excellent paragraph. I’ve never liked writing comments, and I doubt I ever will. It is interesting how some programmers swear by them. I think they are the same programmers who use single-letter variables, magic numbers, and hundred line methods.

I highly recommend reading through the best comments in source code question on StackOverflow.

Remember kids, anytime you feel the need to write a comment, fix your code instead. You’ll thank yourself down the road. You might be the future developer maintaining the code.

A few steps to follow. (These are the easy ones. Harder ones take more than a bullet point to explain and justify.)

  • Rename variables to more expressive names.
  • Extract methods so people know what you’re doing.
  • Extract classes to handle each responsibility.

Null Reference Exception on Instance Methods

Recently I was reading through a bunch of interesting blog posts. I was looking for information about the use of callvirt in C#. Callvirt can be used to call both virtual and non-virtual methods, and in fact is how all methods are called in C#. I don’t know how much of a performance decrease there is based on this, but I doubt it is much of one. I stumbled across this interesting post covering why C# uses callvirt from Eric Gunnerson’s blog.

We had gotten a report from somebody (likely one of the .NET groups using C# (thought it wasn't yet named C# at that time)) who had written code that called a method on a null pointer, but they didn’t get an exception because the method didn’t access any fields (ie “this” was null, but nothing in the method used it). That method then called another method which did use the this point and threw an exception, and a bit of head-scratching ensued. After they figured it out, they sent us a note about it.

We thought that being able to call a method on a null instance was a bit weird. Peter Golde did some testing to see what the perf impact was of always using callvirt, and it was small enough that we decided to make the change.

Now that certainly is odd behavior. I don’t know how I feel about it though. So basically one could have been able to call instance methods on null instances of an object as long as they didn’t access any members of the object itself. First I will say that methods with fewer dependencies are great.

So C# was of course adjusted to disallow this, but if it hadn’t then this could potentially work.

using System;
namespace NullInstanceMethod
    class Program
        static void Main(string[] args)
            Enrick brendan = null;
    class Enrick
        public string Awesome()
            return "Awesome";


Yep, that method isn’t static. It’s an instance method, but you would have been able to call it.

So to see that in action why don’t we disassemble this code and make the change directly to the intermediate language.

First we need to get the IL using ildasm, so open up the VisualStudio 2008 Command Prompt and type this command.

ildasm PathToTheExecutable /

This will create a file “” in our VS Command Prompt working directory.

Now we can open this in our favorite editor and we will see a bunch of code. We are just looking at this main method though.

.method private hidebysig static void  Main(string[] args) cil managed
    // Code size       16 (0x10)
    .maxstack  1
    .locals init ([0] class NullInstanceMethod.Enrick brendan)
    IL_0000:  nop
    IL_0001:  ldnull
    IL_0002:  stloc.0
    IL_0003:  ldloc.0
    IL_0004:  callvirt   instance string NullInstanceMethod.Enrick::Awesome()
    IL_0009:  call       void [mscorlib]System.Console::WriteLine(string)
    IL_000e:  nop
    IL_000f:  ret
  } // end of method Program::Main

See IL_0004 there is our callvirt that makes the call to our instance method. If we change that to a regular call we should be good.

Now we just put the IL back into the assembly.


And we execute it and here is the result.




And there you have it. I just called an instance method on a null instance of a concrete class without getting a null reference exception? Strange? Yes. Wrong? I don’t know if it really is.

For your homework I would like you to consider what would happen if I were calling an interface’s method instead of a concrete class.

Why I Prefer Web Application Projects

Over the summer, Nimble Pros brought on some new interns. We of course brought them up to speed on how we do things here. We like the integration process of bringing new employees into the mix immediately involving them in the process the entire team is involved with. To help get them up to speed we use a combination of pair-programming, book and article reading, and formal instruction.

As I am sure anyone who uses Visual Studio for web development knows, there are two main ways to go about creating the site that you’re going to develop. There is the web application project (WAP) and the web site (ignoring MVC of course).

Back in the days of ASP.NET 1 there was only one way of doing things, web application projects. ASP.NET 2 got rid of WAPs and replaced them with web sites. Not entirely sure why, but it did not take long before Microsoft added Web Application Projects back into the mix. These were able to be installed and added into Visual Studio so they could be used again.

I of course switched to these as soon as they were readily available. The title of this post kind of gives that away. I switched for a few reasons including the dueling assemblies issue which can occur with web sites. I have written about dueling assemblies and some of the differences between these methods of developing sites before.

The main reason why I prefer having a project is that I like being in control. Now you might wonder how I can have more control with a project file. It might seem that the less controlling approach would give me more control, but it is not the case. The loose collection of files, lovingly referred to as a web site is hard to control. I can’t say what is included I can’t say what is excluded. My only control is the relative locations of files. Inclusion of a library? Oh that is a refresh file in the bin folder.

Sure I can get some control in a web site’s loose structure, but I feel that I get so much more control from the project file. I have something obvious to point MSBuild to. I have settings and targets I can manipulate in the file. I have direct control of which files are in the project. Heck I can control which version of a dll I am using which means no more dueling assemblies. Hooray!

Perhaps you disagree. I prefer the WAP to the web site. Do you have any good reason to think otherwise?