ASP.NET MVC 3 installer and NuGet

In case anyone runs into the same problem: it appears that the ASP.NET MVC 3 installer depends on being able to install a particular version of NuGet.

If you have a newer version installed, that part of the installer will fail, leading the rest of the install to also fail.

The solution is to uninstall NuGet, install ASP.NET MVC 3, and then update NuGet to the version you were on.

Listing: the Disposal monad

I received some feedback on yesterday's post, pointing out that it was hard to get the whole story of Disposal<T>'s implementation. Here's the full listing:

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using System.Linq;

namespace DisposalMonad
{
    public static class Disposal
    {
        public static Disposal<T> Unit<T>(T value) where T : class, IDisposable
        {
            return new Disposal<T>(value, Enumerable.Repeat(value, 1));
        }
    }

    public class Disposal<T> : IDisposable
    {
        private readonly T _Value;
        private readonly IEnumerable<IDisposable> _Disposables;

        internal Disposal(T value, IEnumerable<IDisposable> disposables)
        {
            _Value = value;
            _Disposables = new ReadOnlyCollection<IDisposable>(disposables.ToList());
        }

        public T Value
        {
            get { return _Value; }
        }

        public IEnumerable<IDisposable> Disposables
        {
            get { return _Disposables; }
        }

        public Disposal<U> Select<U>(Func<T, U> selector)
        {
            var result = selector(this.Value);
            return new Disposal<U>(result, this.Disposables);
        }

        public Disposal<V> SelectMany<U, V>(Func<T, Disposal<U>> intermediateSelector,
                                            Func<T, U, V> resultSelector)
        {
            var intermediateDisposal = intermediateSelector(this.Value);
            var result = resultSelector(this.Value, intermediateDisposal.Value);
            var disposables = Enumerable.Concat(intermediateDisposal.Disposables, this.Disposables);
            return new Disposal<V>(result, disposables);
        }

        public void Dispose()
        {
            foreach (var disposable in this.Disposables)
            {
                disposable.Dispose();
            }
        }
    }
}

An interesting side point is that Disposal<T> can be turned into something a bit like a linear type - just remove both of the public properties and replace them with the following methods:

public void UseWith(Action<T> action)
{
    using (this)
    {
        action(_Value);
    }
}

public U UseIn<U>(Func<T, U> selector)
{
    using (this)
    {
        return selector(_Value);
    }
}

This might be overkill, though. It makes the class much harder to use and I'm not sure it adds much that will be useful to most applications.

The Disposal Monad

Update: A full listing of Disposal<T> is included in the post after this one.

As mentioned previously, a post on monads seems to be obligatory for any blog involving functional programming. I don't want to repeat the definition or justification, so I'll just point you here for my favourite introduction by the great sigfpe. That was the post that made everything click for me (but YMMV).

In this post I'd like to introduce a new monad of my own device. I haven't seen it used anywhere else, but if anyone knows of prior art I'd love to see it - maybe we can exchange ideas.

The problem

We've all used IDisposable. It's the pattern for representing unmanaged resources, and also works quite nicely for a few other things, like subscriptions to IObservables. The idea is that if you create an object that implements IDisposable, you should call the Dispose method when you're done with it, to make it clean up after itself. Many classes implement IDisposable because they have disposable dependencies that they create themselves.

But what if the object has injected dependencies, and it doesn't know if they're disposable or not? Even if it knows they're disposable, what if they've also been given to another object as dependencies? Who should dispose them?

It's worth noting that this problem is already solved, to some extent. The abstract factory pattern is often used with both a Create method and a Release method; the factory knows where its creations' dependencies have come from, which of them are disposable, and when they can be disposed. IoC containers (being generalised factories) use the same pattern, and all is well.

public class FooFactory : IFooFactory
{
    // private fields and constructor omitted

    public IFoo Create()
    {
        var bar = _BarFactory.Create();
        var foo = new Foo(bar);
        _Bars(foo) = bar;
        return foo;
    }

    public void Release(IFoo obj)
    {
        var foo = obj as Foo;
        if (foo != null)
        {
            foo.Dispose();
            var bar = _Bars(foo);
            _Bars.Remove(foo);
            _BarFactory.Release(bar);
        }
    }
}


The problem with this approach, as I see it, is that it doesn't compose well, which bodes ill for functional programming. Each factory needs to use relatively complex but repetitive logic to keep track of the dependencies of its creations and to call Release on any factories it depends on. Furthermore, it becomes impossible to use factory methods rather than factory objects - we need two methods, not one.

The solution - straightforward version

What we would like to do instead is include, alongside our factory's output, a bundle of IDisposables that should be disposed when we're finished with it. We'll use Disposal<T>, which has three public members:

public class Disposal<T> : IDisposable
{
    // private fields and constructor omitted

    public T Value { get; }
    public IEnumerable<IDisposable> Disposables { get; }

    public void Dispose()
    {
        foreach (var disposable in this.Disposables)
        {
            disposable.Dispose();
        }
    }
}

The factory now looks like this:

public class FooFactory : IFooFactory
{
    // private fields and constructor omitted

    public Disposal<IFoo> Create()
    {
        var barDisposal = _BarFactory.Create();
        var foo = new Foo(barDisposal.Value);
        var disposables = new IDisposable[] { foo }.Concat(barDisposal.Disposables);
        return new Disposal<IFoo>(foo, disposables);
    }
}

We put foo on the front of the list of disposables so that our object graph gets disposed in the opposite order to how it was created.

The consumer will look something like this:

public void ConsumeFoo()
{
    using (var fooDisposal = _FooFactory.Create())
    {
        // use fooDisposal.Value
    }
}

The consumer side's looking pretty good. Our object graph has been wrapped in an IDisposable that encapsulates all of the things we should dispose when we're done with it. But what about the factories? The code to concatenate our disposables is almost as complex as the old version was, and what are we to do about mixing disposable with non-disposable dependencies? Do all factories have to return Disposal<T>, just in case?

The Disposal monad

It turns out that we can do a lot better. Astute readers will already have noticed that the Create method looks very monadic. Let's use LINQ to take advantage of this (using techniques described by Wes Dyer here):

public Disposal<V> SelectMany<U, V>(Func<T, Disposal<U>> intermediateSelector,
                                    Func<T, U, V> resultSelector)
{
    var intermediate = intermediateSelector(this.Value);
    var result = resultSelector(this.Value, intermediate.Value);
    return new Disposal<V>(result, intermediate.Disposables.Concat(this.Disposables));
}

This lets us chain functions of type Func<T, Disposal<U>> - which are just our factory methods - in LINQ queries. FooFactory is already looking simpler:

 public class FooFactory : IFooFactory
{
    // private fields and constructor omitted

    public Disposal<IFoo> Create()
    {
        return from bar in _BarFactory.Create()
               from foo in Disposal.Unit(new Foo(bar))
               select foo;
    }
}

Disposal.Unit is just a static method that lets us wrap a single IDisposable in a Disposal<T>.

We might have factories that represent a transformation on an IFoo; into a FooAdapter, say. FooAdapter isn't disposable, and it doesn't know it's getting a disposable Foo, but we still need our dependencies to be disposed. We need a way to lift a function from IFoo to FooAdapter into one from Disposal<IFoo> to Disposal<FooAdapter>. No problem:

public Disposal<U> Select<U>(Func<T, U> selector)
{
    return new Disposal<U>(selector(this.Value), this.Disposables);
}

C# LINQ queries can only contain one select clause at the end, so we'll use a let clause to call Select. Throwing away the factory for a quick combined example:

return from bar in _BarFactory.Create()
       from foo in Disposal.Unit(new Foo(bar))
       let fooAdapter = new FooAdapter(foo)
       select fooAdapter;

We can now compose multiple single-method factories, some of which return IDisposables, together.

Conclusion

This isn't a perfect solution. There's a definite learning curve on hijacking LINQ for monads other than IEnumerable<T> and its friends IQueryable<T> and IObservable<T>, and I've even met a professed .NET programmer who asked me "Why have you spelled 'link' with a Q?". However, I think the gain in composability and the fact that it drastically reduces the amount of code in factories gives the disposal monad an edge over the alternatives.

Introduction

Hi! Everyone who's anyone and has ideas seems to have a blog, so I thought I should have one too.

I'm a .NET programmer and avid gamer in Perth, Western Australia. I've been hobby programming in various versions of BASIC since I was seven, so getting into .NET was an obvious choice.

I have a lot of ideas about programming, many unrealistic but none not thoroughly considered (I very rarely get a full night's sleep), and feel like I need a place to put them down and expose them to the critical eyes of the world.

In particular, I've been thinking about functional programming in C# and VB lately, so I'll probably make a few posts about that. I think I'll alternate between the languages for each post, because I love VB but understand that most of the .NET blogging community prefers C#. At some point I might make a list of things that I like about each language, and describe a wishlist language that combines the best of both.

I also enjoy playing, designing and programming games and have a few hobby projects going, so I might talk a bit about those sometime too.

Coming up next: the obligatory monad post.