DI and its benefits have been written about for years, but the short version is that your classes can accept interface arguments through their constructors, and these arguments represent the class’s dependencies. A simple example can be seen in the FubuMVC samples:

public class ListHandler
{
    private readonly IRepository _repository;

    public ListHandler(IRepository repository)
    {
        _repository = repository;
    }

    public ListMoviesViewModel Execute()
    {
        return new ListMoviesViewModel { Movies = _repository.Query<Movie>() };
    }
}

Here, the ListHandler class is declaring, incidentally to the compiler but primarily to the reader, that it depends on a repository to do its work. Rather than construct a new Repository() itself, it assumes a pre-constructed IRepository will be provided.

At a minimum, this is convenient in the case that the Repository constructor itself has potentially-tricky-to-instantiate arguments, each of which may have their own constructors to call, ad nauseum.

More importantly, since your class no longer has to ‘new up’ the dependencies itself, it is decoupled from the concrete implementations of those dependencies. At test time, you can pass in a mock or stub implementation to prove that your class makes use of the abstraction as expected, and at run time you can trust a tool like StructureMap to create and pass in the real implementation. When looking at a class written in this style, you can quickly see what it depends on by looking at its constructor, rather than looking through the entire class definition.

Playing Devil’s Advocate

The ListHandler class is easy to read, easy to understand, so easy to test that it might not be worth the bother, and it absolutely follows the Single Responsibility Principle. It’s simple, basically the “Hello, World!” of Dependency Injection, but simple is a good thing to shoot for whenever we put our hands on a keyboard. It’s a Good Class.

However, when I find myself writing similar single-responsibility classes with a dependency or two passed to the constructor, a little imaginary Devil pops up on my left shoulder, accompanied by his Angel twin on my right. The Devil wispers, “Why in the heck are you writing all that boilerplate!?” and the little Angel looks at the class and says, “Yeah, I hate to say this, but I think you should be listening to that guy.”

What does this class tell the reader? First, it says “I depend on a repository.” Then it says “And when I say repository, I mean repository.” Followed by “No, seriously dude, we’re talking about a repository here.” When we inject an interface like this, we pay the syntax tax by saying ‘repository’ six times in a row. 12 lines so that we could say the 1 line that we actually wanted to say.

Of course, this is not a problem with DI itself. This is a problem of the language not knowing DI would be so prevalent. What we really want, in these single-method dependency-injected classes, is effectively a global function, with some arguments specially-marked as dependencies. Consider a hypothetical C# from the future:

public ListMoviesViewModel ListHandler(inject IRepository repository)
{
    return new ListMoviesViewModel { Movies = _repository.Query<Movie>() };
}

Such a function, if it could be declared, could be called with zero arguments when we want a real IRepository injected, and could be passed an IRepository at test time. What do you think? Would this kind of language support be useful in practice?

public delegate TResult Converter<T, TResult>(T input);

With this definition, all functions that turn one thing into another thing are Converters. Nice.

We also have some generically-named Action<…> and Func<…> delegate types defined for us, and these have become ubiquitous ever since LINQ was introduced. They’re not as communicative, but still extremely useful, and for the most part the naming stays out of the way.

Delegate types allow you to give a name to a family of functions. However, you can run into trouble when you use two different names to refer to the same family of functions:

public string Stringify(int x)
{
    return x.ToString();
}


//Later...

Func<int, string> func = Stringify;
Converter<int, string> convert = Stringify;

Since all methods are compatable with any delegate type that has matching input/output types, why aren’t the following queries equivalent?

int[] integers = new[] {1, 2, 3};

integers.Select(func); // returns "1", "2", "3"
integers.Select(convert); // fails to compile!

This was a little frustrating when C# 3 came out. Before then, all the delegate types we were used to working with had explicit names like Converter and Predicate. When C# 3 introduced lambdas and LINQ, we gained Func<…> and Action<…>, and I found myself stumbling while converting older code to use the new LINQ extension methods like Select, which takes a Func<T, TResult>.

It’s extra-frustrating because every single Converter<T, TResult> method that ever lived is also a Func<T, TResult>! I know it, you know it, Grandma tweeted it. We can drive that point home by making the convert delegate work with Select by wrapping it in a trivial do-nothing lambda: integers.Select(x => convert(x)); Yeesh!

To help make sense of this behavior, we can make an analogy between delegates and interfaces.

Think of a delegate type as a special kind of interface type. The interface has only one method, called “Call”. Since it is always called “Call”, you can shorten the reader-unfriendly convert.Call(5) to simply convert(5).

Think of a method as an instance of these interfaces. All methods implement the infinite number of possible delegate ‘interfaces’ that match their input and output types. Stringify is an object that implements the imaginary IConverter<int, string> interface, and also implements the imaginary IFunc<int, string> interface. Both of these interfaces just happen to contain the imaginary method with the signature: string Call(int x).

Now, the example above makes more sense. We have two variables declared as ‘interface’ types, and assign the same object to both variables. Select is written to accept instances of one ‘interface’ type, and although convert points at a method compatable with Select, convert itself can only be seen as having some other, incompatible type.

In Who Needs an Architect?, Martin Fowler covers a few definitions which he ultimately boils down to one simple concept: architecture is the decisions that are hard to change.

Depending on the tone you use when reading that definition, it’s almost a pejorative. Joel Spolsky even warned us of Architecture Astronauts, people who effectively over-engineer and abstract things to the point that they’re no longer solving real problems.

Yes, an architecture can be bad. If the decisions that are hard to change form obstacles between you and the true goal of your project, you’ve got a bad architecture. On the other hand, some decisions that are hard to change may be a driving force for your success. It’s just important to be aware of which decisions form your architecture as you make them.

Example: The Onion Architecture

With the Onion Architecture, the hard-to-change decision is to define realtively-unstable infrastructure on the outside, depending on a core application that is ignorant of infrastructure details like persistence.

This decision is hard to change, but it is justified. As Jeffrey Palermo said during a presentation on the O.A., an assembly is only as stable as its least-stable dependency. Therefore, for an application to stand the test of time, we need to maximize the stable portion and minimize our dependency on things that are too likely to change. If your app integrates with Twitter today, it likely won’t in 5 years after Twitter goes the way of the blue Dodo bird, so you are better off defining your Twitter integration outside of the core assembly, dependent on the core assembly rather than the other way around.

Example: Parsley

A few months back I described a hobby project to illustrate covariance issues. This project lets you parse text by describing what a valid input looks like (similar to regular expressions). There were two key decisions that would be impossible to change without starting from scratch:

First, the user would describe what a valid input looks like by gluing together tiny side-effect-free functions.
Second, I would use read-only data structures to represent progress through the input.

These two decisions are made frequently when using functional languages, but not so much in C# projects. Despite being unusual, I found these decisions to be extremely helpful for this kind of problem, regardless of the language used to implement it.

The samples contain a JSON parser, which amounts to describing what valid JSON looks like. The bulk of the description is summed up in a few lines:

Json.Rule =
    Choice(True, False, Null, Number, Quotation, Dictionary, Array);

Dictionary.Rule =
    from pairs in Between(Token("{"), ZeroOrMore(Pair, Token(",")), Token("}"))
    select ToDictionary(pairs);

Pair.Rule =
    from key in Quotation
    from colon in Token(":")
    from value in Json
    select new KeyValuePair<string, object>(key, value);

Array.Rule =
    from items in Between(Token("["), ZeroOrMore(Json, Token(",")), Token("]"))
    select items.ToArray();

Because of the two architectural decisions, all the details about tracking progress, success, and failure can be completely hidden. The user can solve the task at hand by describing the task at hand, and the architectural decisions enable that ability.

Making Your Own Decisions

As you make a decision that affects your project’s structure, ask yourself, “Is this a part of our architecture? Is it going to be hard to change later if we go forward with it? If so, does it earn the right to be included anyway?” If not, try to restructure it so that it is easy to change, or consider chucking it entirely.

The controls-and-event-handlers model combined with the language also made it exceptionally easy to create a tangled pile of misplaced responsibilities, but I think you’ve got to experience that kind of pain before you can see that alternatives even exist. Once you’ve felt the pain, you can better-evaluate which guidance is actually going to be helpful.

WebForms Was Designed for Desktop Developers

Right around that time, .NET was released. ASP.NET WebForms shared little with classic ASP. The primary goal was to let desktop VB developers make a smooth transition to both .NET and web development at the same time. With that goal in mind, WebForms provided a similar controls-and-event-handlers model. Making a web app felt like making a desktop app.

In order to support that approach, WebForms had to make the stateless world of HTTP feel stateful. View State, the Page Life Cycle, and event handlers allowed the developer to go through the familiar motions of dropping controls onto a designer and wiring up methods to control events, all while ignoring everything that was actually happening.

Abstractions leak, though, and this was a huge abstraction. It helped me get over the initial hurdle to get a web app up and running, but I found the code I wrote was suspiciously like the desktop VB6 mess I’d wanted to grow beyond. I was frequently surprised by the effects of the Page Life Cycle, and every time that happened I had to learn a little bit more about how the abstraction worked under the hood:

“Oh! There’s a Big Honking <form> Tag for the whole page, and it contains an Enormous Encoded <input> Tag containing the current state of all the controls, so whenever I need to hit a button click handler I’m really submitting a normal HTML form and then…”

Ugh. Eventually, you just have to know what HTML and HTTP are, even when using WebForms, so the abstraction was no longer helping.

Many Page Life Cycles Later…

While working for a previous employer, ASP.NET MVC came out. We wanted to try out the new approach, and the timing coincided with a new project that was starting up. However, there wasn’t much guidance available yet on how to do it well. We were challenged at first by the lack of View State, and in order to keep our old “stateful stateless web” habit going we ended up storing a lot of things into the user’s session object. We also kept treating controller actions like they were event handlers, leading to some awkward-looking URLs. Distracted by these initial pains, our controllers started absorbing responsibilities like a sponge. Actually, our controller started absorbing responsibilities – there was only controller in the whole app!

I was writing a lot of controller actions like this:

public ActionResult Edit()
{
    var conferenceName = Request["ConferenceName"] as string;
    var repository = new ConferenceRepository();
    var conference = repository.GetByName(conferenceName);

    if (conference == null)
        return View("ConferenceNotFound");

    ViewData["ConferenceId"] = conference.Id,
    ViewData["ConferenceName"] = conference.Name

    return View();
}

public ActionResult Save()
{
    var conferenceName = Request["ConferenceName"] as string
    if (string.IsNullOrEmpty(conferenceName))
    {
        ViewBag.ErrorMessage = "Conference Name is required";
        return View("Edit");
    }

    var repository = new ConferenceRepository();
    var conference = repository.GetById(new Guid(Request["ConferenceId"] as string));
    conference.ChangeName(Request["ConferenceName"] as string);
    _repository.Save(conference);

    return RedirectToRoute("Default", new { action = "Index"});
}

What I saw was the same thing I saw in WebForms development. The Controller was the new Code Behind, and I was underwhelmed. WebForms’s Page Life Cycle and View State hurt, but the real daily pains came from working with classes that were growing out of control, and I was seeing the same thing with my MVC code. It seemed like the abstractions were lighter-weight, and it felt right to work with HTML more directly, but I was definitely missing some guidance.

Turning the Corner

Several coworkers got to take an MVC Boot Camp course here at Headspring, and I got to learn by osmosis from them upon their return. At last, I had a good picture in my head of what it looks like when you’ve succeeded with these tools. Our controllers started to get much more lean:

[HttpGet]
public ActionResult Edit(Conference conference)
{
    return AutoMapView<ConferenceEditModel>(View(conference));
}

[HttpPost]
public ActionResult Edit(ConferenceEditModel form)
{
    if (!ViewData.ModelState.IsValid)
        return View(form);

    var conference = _repository.GetById(form.Id);
    conference.ChangeName(form.Name);

    return this.RedirectToAction<DefaultController>(c => c.Index());
}

I started to see how the Onion Architecture, dependency injection, model binders, AutoMapper, and the like help you to keep your controllers small. MVC wasn’t a silver bullet; its primary benefit compared to WebForms was that you could make it get out of the way so you could actually start laying down a solid architecture.

ASP.NET MVC has been around for a few years now. Community contributions like MvcContrib helped to motivate change in subsequent releases, and now ASP.NET MVC is legitimately open-sourced. Better-yet, guidance on how to do this well has had years to mature.

MVC is a sharper tool than WebForms. It acknowledges the reality of web technologies like HTML and HTTP, while providing some reasonably-sized abstractions on top of that, such as routing and model binding. Having a better tool in your toolbelt isn’t enough, though. You have to see what it looks like when used correctly.

Source control tools slice and dice text all day. It’s easy to compare, easy to merge, and easy to compress. Even in a busy project, large portions of your code don’t really change all that often. Git, for instance, can pretend to store every commit as a point-in-time copy of your whole source tree by sharing large unchanged blobs of text with other commits.

Text is easy. Binary is tough.

Do you pass the “New Hire Day 1″ test?

We often store binaries in our source control tools, and with good reason. We want to make it easy to spin up a new development environment. When you hire a new developer, they should be able to pull down your project from source control and just go. Dependencies such as libraries, build tools, and the like should be versioned with the project.

The alternative experience can be painful. You show up for your first day at a new job, pull down the project, and try to run it… THUD. It won’t even build. You try to install the right third-party libraries and tools after diagnosing each build error, and hopefully you’re using the same version as everyone else. Maybe the Dependency Gods smile upon you, and you’ll be up and running before the end of the day.

It’s easy to avoid these problems by including your dependencies, both libraries and tools, in source control, but can we do better?

Binary is Tough

You can store binaries in source control, but binaries are tough. Even small changes in functionality can result in dramatically different file contents, so it’s impractical to diff/merge them. Changes in a binary file over time have to be stored without the sneaky compression tricks used for text files.

NuGet makes it easy to install libraries into your projects, but this means dumping a whole lot of DLLs into source control. Your repo might start to grow impractically large.

Package Restore

Fortunately, though, we can have the best of both worlds. We can provide our team with a reliable and easy way to set up new development environments, and benefit from NuGet’s version/dependency smarts, without having to actually store NuGet package binaries in source control.

First, install NuGet if you haven’t already.

Next, go to Solution Explorer, right click on the Solution itself, and select “Enable Nuget Package Restore”. This adds some files to a special .nuget folder, and adjusts the projects of your solution to use that folder at build time.

Lastly, note that NuGet has been placing downloaded packages under a packages/ folder near your *.sln. You can wipe this out. When using git, I also add this folder to my .gitignore so that its contents no longer get saved to the repository.

Read that last step again. We deliberately deleted away all the versioned packages that NuGet has been maintaining for us!

When enabling Package Restore in your solution, you changed the way that your solution builds. When you try to build again, NuGet will notice that your projects reference specific packages that are no longer found under packages/. Fortunately, your solution still contains packages.config files which list dependencies along with their version numbers. Armed with these config files, NuGet will pull down the missing files into packages/ for you right before your project gets compiled. Upon the next build, it will just use the files already in packages/.

Black Box Debugging

Using that NuGet package from last week, I installed Parsley into another project that consumes it. While trying to debug that project, I got to a point where I wanted to just step the debugger into one of Parsley’s methods. Even with the PDB file included in the NuGet package, Visual Studio just plain didn’t have enough information to let me step through Parsley’s code.

Too much information about the original source gets lost when a PDB is produced. We need to make the source code available to the consumer when they install our packages, and we need to so in a way that Visual Studio can take advantage of at debugging time.

Publishing a Symbol Package

Fortunately there is a free service, SymbolSource.org, which is easy to integrate with both NuGet (for the publisher) and Visual Studio (for the consumer). Although getting a SymbolSource account is an option, you won’t actually need one. You’ll be able to publish a special variant of your NuGet package to NuGet.org, and then NuGet.org shakes hands with SymbolSource.org on your behalf. All it takes is a slight tweak to your .nuspec file, and an extra command-line argument when converting that .nuspec into a .nupkg!

The previous version of my .nuspec‘s files tag just copied DLLs and PDBs into the package’s special “lib” folder:

<files>
    <file src="$package_dir\*.dll" target="lib\net40" />
    <file src="$package_dir\*.pdb" target="lib\net40" />
</files>

The new version also copies all of the source code to the package’s special “src” folder. We don’t need to copy auxiliary files like .csproj or .sln. We just need to copy the code files that the debugger will need to display, namely all the *.cs files:

<files>
    <file src="$package_dir\*.dll" target="lib\net40" />
    <file src="$package_dir\*.pdb" target="lib\net40" />
    <file src="$source_dir\**\*.cs" target="src" />
</files>

I used this single .nuspec to produce two .nupkg files, by including the -Symbols command line argument:

$ nuget pack Parsley.nuspec -Symbols

This produced Parsley.0.0.2.nupkg like normal, but it also produced Parsley.0.0.2.symbols.nupkg. NuGet.exe is smart enough to know that the first package only needed the DLLs (used at installation time), and that the symbol package needs to contain the PDBs and C# files (used at debugging time). When I pushed the main package to NuGet.org, NuGet.exe noticed the symbol package was also present, and submitted that one too:

$ nuget push Parsley.0.0.2.nupkg
Pushing Parsley 0.0.2 to the NuGet gallery (https://www.nuget.org)…
Your package was pushed.
Pushing Parsley 0.0.2 to the symbol server (http://nuget.gw.symbolsource/Public/NuGet)…
Your package was pushed.

I then followed the instructions for configuring Visual Studio to work with SymbolSource.org. Remember, you don’t have to follow the suggestion to create a SymbolSource account.

I updated the package in the consumer project, which installed the DLLs. The next time I tried to step into a Parsley method, I got a quick dialog that said it was downloading the relevant files from SymbolSource, and then I was able to step through the read-only C# files found within the symbol package!

In Recognizing Covariance Issues in Your Code, I introduced my hobby project, Parsley. This project has gotten fairly stable in recent weeks, and I decided to publish it so that I could use NuGet to install it in other projects.

In the simple NuGet package, we created a *.nuspec file containing a files tag. That files tag listed the files we wanted to copy into the target project upon installation. We described the target path starting with “content”:

<files>
    <file src="Enumeration.cs" target="content\Headspring\Enumeration.cs" />
    <file src="LICENSE.txt" target="content\Headspring\LICENSE.txt" />
</files>

Parsley’s build script generates a *.nuspec file with a slightly different naming convention for the target paths:

<files>
    <file src="$package_dir\*.dll" target="lib\net40" />
    <file src="$package_dir\*.pdb" target="lib\net40" />
</files>

Starting these paths with “lib” instead of “content” indicates to NuGet that they are libraries and should be added to the target project’s list of referenced assemblies. The “net40″ folder is also a part of the naming convention, indicating that the assembly was built for .NET 4.0. If we’re targeting several different runtimes, we could include them all in one package using folder names like “net11″, “net20″, etc…

Above, I’m also copying the *.pdb files into the package. Next week, we’ll see a better alternative to enhance the debugging experience for your library’s users: integrating with SymbolSource.org.

I recently migrated Headspring’s Enumeration class to GitHub. This is a simple class that, for the most part, replaces the need for .NET enum types. One of the simplest things a NuGet package can do is add a file to your project, so creating and publishing an updated NuGet package for Enumeration was a great way to get my feet wet.

Unlike most things, it was as easy as it should be.

First, I created an account on nuget.org and installed the extension using the link on the front page. Next, I downloaded the NuGet.exe command-line tool and made sure it was included in my PATH. On my account profile page, I’m given the chance to see my API Key. Keep this secret. At the command line, we need to issue a one-time command so that this key can be active during subsequent nuget commands:

$ nuget setApiKey 123-abc-123-abc-123

You create a *.nuspec file which describes the files you want to publish. Then you ask nuget.exe to turn that file into a *.nupkg file. A nupkg file is actually a zip file containing the files to be deployed as well as some metadata.

At this point, the project consisted of 3 files: a README, LICENSE.txt, and Enumeration.cs. While in this folder, I issued a command to create a skeleton of a nuspec file:

$ nuget spec

This creates Package.nuspec, which I renamed to Enumeration.nuspec and populated:

<?xml version="1.0"?>
<package>
    <metadata>
        <id>Enumeration</id>
        <version>1.0.4</version>
        <authors>Headspring</authors>
        <owners>Headspring</owners>
        <licenseUrl>https://github.com/HeadspringLabs/Enumeration/blob/master/content/Headspring/LICENSE.txt</licenseUrl>
        <projectUrl>https://github.com/HeadspringLabs/Enumeration</projectUrl>
        <iconUrl>https://bitbucket-assetroot.s3.amazonaws.com/c/photos/2010/May/14/spray_avatar.png</iconUrl>
        <requireLicenseAcceptance>false</requireLicenseAcceptance>
        <description>A utility class. Common uses include Java-like enumerations, dispatch table, flyweight, and drop-down list items/select options.</description>
        <tags>utility enumeration</tags>
    </metadata>
    <files>
        <file src="Enumeration.cs" target="content\Headspring\Enumeration.cs" />
        <file src="LICENSE.txt" target="content\Headspring\LICENSE.txt" />
    </files>
</package>

There isn’t much going on here. We say what version number we want to publish, a few descriptive fields, and then list the files we want to be included in the nupkg ‘zip’ file. In the file tags, src refers to the files relative to the location of the nuspec file, and target describes the path we want to copy it to within the zip. Starting these paths with “content” means that when someone installs the package into one of their own projects, the files will be copied and then added to the target project file.

To publish, we just need to issue the following commands:

$ nuget pack Enumeration.nuspec
$ nuget push Enumeration.1.0.4.nupkg
$ del Enumeration.1.0.4.nupkg

nuget pack converts a nuspec into a nupkg, and nuget push submits it to nuget.org. After that, we don’t need to keep a copy of the nupgk, so we delete it.

That’s it! Next week, we’ll cover the slightly more involved scenario of publishing a whole open-source library.

If you have a method that constructs a new instance of a class, uses it a little, and then discards it, there’s no real reason to put it on the heap. It’s not going to need to exist after we return, so we might as well put it on the stack and get the deallocation for free.

If you instead have a method that constructs a new instance of a class and returns that to the caller, we definitely have to put it on the heap, because we need to ensure it still exists after we return. There are lots of things we might do with an object that would require us to use the heap. We can return it, pass it to another thread, pass it to another function that passes it to another thread, etc.

The basic idea is that if, after your function exits, there could not possibly be any remaining references to that object, then it might as well be put on the stack and cleaned away without the need for garbage collection.

Escape analysis is a compiler optimization that can be applied to languages like these. If the compiler can prove to itself that the object can’t “escape” beyond the lifetime of the method, it will use the stack.

Although escape analysis really just refers to this compiler trick, I like to use the term to describe a specific kind of refactoring effort. Before I get to that, though, we need to talk about your arch-nemesis.

Code Doesn’t Just Rot

Over the long life of a software project, certain parts of the code will become more difficult than they deserve to be. One area might be a frequent source of bugs, and the fixes applied by many hands may make it needlessly complex, for instance.

Sometimes it seems that even when an area doesn’t go through much flux, it still rots. Newer and better ideas are introduced to the project, and one area may be left behind the times. By the time you come across it again, it feels like it’s rotting away.

Code rot taken to its extreme gives you a spooky basement, the part of the project nobody wants to touch. It’s a tangled mass of patches and awkward abstractions.

I don’t really like the code rot metaphor because it makes the problem code out to be a passive byproduct. I prefer to think of bad/awkward/old design decisions as being an active and malicious adversary hell-bent on escaping from the confines of its files with the goal of making the rest of your project rot along with it.

Code doesn’t just rot. The rot escapes and spreads. This thing is out to get you.

Escape Analysis at Refactoring Time

When I’m working in a clean area of a project, refactoring is an easy process. You rename things to make them read better, extract a method or class here or there to organize responsibilities better, and the like.

When I’m working on a spooky basement, or even a not-so-bad eerie breakfast nook, I put on the Escape Analysis Hat. Unlike the compiler optimization which asks “At runtime, how can this instance escape into the rest of the running system”, I ask “How do references to this unwanted method/property/field/class escape into the rest of the code?”

This starts with ReSharper, but tools like this can only get you started. You find usages of the unwanted thing’s identifier, and then find usages of those usages, and usages of those usages, to start to get a feel for what other areas depend on it.

That’s not enough! Remember, this method/property/field/class is actively trying to escape into the rest of your system. It wants to escape in any sneaky, devious way it can. Maybe it gets AutoMapped to some other type, whose usages you’ll need to investigate. Maybe it gets serialized to JSON which in turn gets consumed by some javascript you’ll need to investigate. Maybe it gets accessed via reflection, or appears in a binding in a XAML file, or gets passed to a web service…

A Particularly Tricky Example

I was recently refactoring an area of a project that wasn’t a serious problem yet. Left alone, the complexity would have eventually gotten out of control, so we decided to address a particular source of the growing complexity. I encountered a property in a View Model class that I wanted to simplify; I didn’t quite see the need for it at first. After seeing how references to this property escaped into the rest of the system, my first thought was “Oh, this really does get used in a lot of places, and not just in the UI layer. It needs to exist.”

After looking into the escape paths again, though, I realized it was largely unnecessary. It satisfied a UI requirement, but that could have been satisfied in a simpler way and in only the UI layer.

The escape path was pretty intricate. This property had a few real and meaningful usages. Additionally, it got AutoMapped to another type, which ultimately got serialized and later deserialized so it could be AutoMapped back to the original type. This circuitous route was not actually used for anything (anymore) and could be removed.

The next time you find yourself refactoring, and you reach a point where it’s not obvious what the next step should be, find a suspicious identifier and see where he’s escaping to.

var delayedGreetings = new List<Func<string>>();

foreach (var name in new[] { "Larry", "Moe", "Curly" })
    delayedGreetings.Add(() => "Hello, " + name + "!");
            
//Some time later...
foreach (var greeting in delayedGreetings)
    Console.WriteLine(greeting());

Where we would expect the output to be:
Hello, Larry!
Hello, Moe!
Hello, Curly!

Instead, we see:
Hello, Curly!
Hello, Curly!
Hello, Curly!

Fortunately, ReSharper points out that something fishy is going on with the reference to name that appears in the loop body: “Access to modified closure.” If you follow the ReSharper suggested fix, you get this:

foreach (var name in new[] { "Larry", "Moe", "Curly" })
{
    string name1 = name; //Added a seemingly-pointless local variable!
    delayedGreetings.Add(() => "Hello, " + name1 + "!");
}

//Some time later...
foreach (var greeting in delayedGreetings)
    Console.WriteLine(greeting());

Oddly, introducing this local variable does fix the output, but why? To find out, let’s first rewrite the original version using a transformation from a foreach loop to a while loop, since that’s the first thing the compiler does for us. It still erroneously prints “Hello, Curly!” three times:

var delayedGreetings = new List<Func<string>>();

{
    using (var e = ((IEnumerable<string>)new[] { "Larry", "Moe", "Curly" }).GetEnumerator())
    {
        string name;
        while (e.MoveNext())
        {
            name = e.Current;
            delayedGreetings.Add(() => "Hello, " + name + "!");
        }
    }
}

//Some time later...
foreach (var greeting in delayedGreetings)
    Console.WriteLine(greeting());

ReSharper still highlights the use of name within the loop body, and still says it is an “Access to modified closure.” Before we can try to fix the problem, we’re going to have to make sense of that warning.

What’s a Closure?

The word “closure” comes up a lot when talking about any language that has anonymous inline functions. In C#, that means anonymous delegates and their shorthand lambda expressions introduced with =>. You have comparable anonymous functions in Javascript, Ruby, Python, etc. Whenever you have an anonymous function whose body refers to identifiers in the surrounding scope, the function earns the right to call itself a closure.

Lambdas are really shorthand for a class with one method as well as the instantiation of that class. In our example above, the lambdas are living beyond the execution of the loop, and that means they need to live beyond the normal scope of the loop variable, name. In order to work, they’ll need to hold onto something about that variable. In fact, they hold onto the environment that was in effect at the moment the lambda was reached. By environment, I mean all of the local variables they might be referring to. It is as if we wrote the following, which also prints “Hello, Curly!” three times:

public class Environment
{
    public string name;
    //As well as one field for each of the
    //original loop's local variables, if
    //there were any...
}

public class Greeter
{
    private readonly Environment _environment;

    public Greeter(Environment environment)
    {
        _environment = environment;
    }

    public string Execute()
    {
        return "Hello, " + _environment.name + "!";
    }
}

static void Main(string[] args)
{
    var delayedGreetings = new List<Greeter>();

    {
        using (var e = ((IEnumerable<string>)new[] { "Larry", "Moe", "Curly" }).GetEnumerator())
        {
            var environment = new Environment();
            while (e.MoveNext())
            {
                environment.name = e.Current;
                delayedGreetings.Add(new Greeter(environment));
            }
        }
    }

    //Some time later...
    foreach (var greeting in delayedGreetings)
        Console.WriteLine(greeting.Execute());

    Console.ReadLine();
}

AHA! See how we have only one instance of Environment shared by all the Greeters, and each iteration of the loop messes with the name field inside that shared Environment? No wonder our final loop prints out the same thing each time: all the items in delayedGreetings refer to the same Environment, which contains only one name, which equals whatever we set it to last.

They call these lambdas “closures” because the secret object behind the scenes is grasping-at / enveloping / closing-on the local environment. As we see in the last example, even after the environment is closed on, we can still affect that environment. We say that the lambda is closing on the variables themselves rather than simply holding a reference to their values.

Even foreach leaks.

Fixing foreach

So we’ve got this fancy compiler that can take a combination of foreach and lambda expressions, rewriting them into some equivalent-yet-verbose code, which in turn is easier to compile. It’s a big abstraction that usually works so well we don’t stop to think it’s even happening. How could we fix it?

It seems the whole problem comes down to the fact that with one shared environment, each iteration messes with a shared mutable object. We get one environment per scope, though, and the while loop body introduces a new, more-local scope of its own! We could take advantage of that by declaring the loop-iteration variable name within the while instead of before it. This way, each iteration will get its own Environment with its own name. Nothing shared, nothing mutated, leaving us with the three distinct greetings we wanted. In other words, we wish that foreach gets translated into a while loop like so:

var delayedGreetings = new List<Func<string>>();

{
    using (var e = ((IEnumerable<string>)new[] { "Larry", "Moe", "Curly" }).GetEnumerator())
    {
        while (e.MoveNext())
        {
            string name = e.Current; //Variable declaration inside the while.
            delayedGreetings.Add(() => "Hello, " + name + "!");
        }
    }
}

//Some time later...
foreach (var greeting in delayedGreetings)
    Console.WriteLine(greeting());

ReSharper’s suggestions basically accomplish the same thing. By introducing a seemingly-redundant copy within the smaller scope, the environment used by the lambdas is different in each iteration.

Usually when something as fundamental as a looping keyword has a problem like this, the language designers don’t really have the option of correcting it. It’s technically a breaking change to make all foreach loops translate to the better version of the while seen in the last example. However, they are going to be fixing foreach in C#5. It’s a breaking change, but one that will fix more mistakes than it creates!