private override

4Jun/103

Teaching StructureMap About C# 4.0 Optional Parameters and Default Values

This week I ran into wanting to use C# 4.0 optional parameters, but wanted StructureMap (my IoC tool of choice) to respect the default value specified for those optional parameters.

The Problem

In this example, we’ll be pulling a command out of the container.  The important part is the optional constructor parameter (level), and it’s default value (Level.Info).

public class LogCommand

{

    IDestination _destination;

    Level _level;

 

    public LogCommand(

        IDestination destination, Level level = Level.Info)

    {

        _destination = destination;

        _level = level;

    }

 

    /* logging code here */

}

 

Here is your basic usage, but doesn’t work since StructureMap doesn’t know how to take advantage of the optional parameters with default values.

var container = new Container(config =>

{

    config.Scan(scanner =>

    {

        scanner.TheCallingAssembly();

        scanner.AddAllTypesOf<IDestination>();

        scanner.WithDefaultConventions();

    });

});

 

var logCommand = container.GetInstance<LogCommand>();

 

The last line results in an exception because StructureMap doesn’t know how to fill in the level parameter.

The Solution

We can solve this by adding a new convention.  One that adds information about default constructor arguments.  Here is the implementation of the convention:

public class DefaultCtorParameterConvention : IRegistrationConvention

{

    public void Process(Type type, Registry registry)

    {

        if(type.IsAbstract || type.IsEnum)

            return;

 

        var ctor = type.GetGreediestCtor();

 

        if(!ctor.HasOptionalParameters())

            return;

 

        var inst = registry.For(type).Use(type);

 

        foreach(var param in ctor.GetOptionalParameters())

            inst.Child(param.Name).Is(param.DefaultValue);

    }

}

Note: GetGreediestCtor, HasOptionalParameters, and GetOptionalParameters are extension methods.  We’ll see their implementation shortly.

The convention inherits from the IRegistrationConvention, which is how you implement new conventions in StructureMap.  It has only one method: Process.  We filter out types that are abstract, are enums, or have constructors that don’t have optional parameters.  Once we realize we have a constructor we want to deal with, we use the Child method, that sets either a property or a constructor argument (for our case, it’ll always be a constructor argument), and then we set it’s value to the parameter’s default value, as provided by the ParameterInfo object, for each optional parameter.

Minor Details

Curious about the implementation of GetGreediestCtor or the *OptionalParameters methods?  If not, skip this section.

public static bool HasOptionalParameters(

    this ConstructorInfo ctor)

{

    return ctor.GetOptionalParameters().Any();

}

 

public static IEnumerable<ParameterInfo> GetOptionalParameters(this ConstructorInfo ctor)

{

    return ctor.GetParameters().Where(

        param => param.Attributes

            .HasFlag(ParameterAttributes.Optional));

}

 

public static ConstructorInfo GetGreediestCtor(

    this Type target)

{

    return target.GetConstructors()

        .WithMax(ctor => ctor.GetParameters().Length);

}

 

public static T WithMax<T>(

    this IEnumerable<T> target, Func<T, int> selector)

{

    int max = -1;

    T currentMax = default(T);

 

    foreach(var item in target)

    {

        var current = selector(item);

        if(current <= max)

            continue;

 

        max = current;

        currentMax = item;

    }

 

    return currentMax;

}

 

 

The Usage

Here’s how to use your new convention.

var container = new Container(config =>

{

   config.Scan(scanner =>

   {

       scanner.TheCallingAssembly();

       scanner.AddAllTypesOf<IDestination>();

       scanner.WithDefaultConventions();

       scanner.Convention<DefaultCtorParameterConvention>();

   });

});

 

var logCommand = container.GetInstance<LogCommand>();

 

Now, when we pull the LogCommand out of the container, the level parameter gets defaulted to Level.Info, just like we specified in the constructor.  Sweet!

Conclusion

This implementation is somewhat limiting, but the version I have in my github repo is a little more open and configurable.  It allows you to customize the instance key/name you use when registering your type, and also allows you to do additional, non-standard registrations if you need to.

Also, this doesn’t work if you’ve selected a constructor using the SelectConstructor config API from StructureMap, I’m not sure how to tap into that facility to look for that constructor rather than the greediest.

Am I missing something?  Did something not make sense?  Leave me a note!

23Sep/091

Autotest… in .NET

The first time I saw autotest (presented by Anthony), the idea of Continuous Testing captured me.

I live in a .NET world most of the time, and I know of no similar solution for .NET.  It’s been awhile since that first time, and I’ve tinkered here and there trying to get something comparable, but usually come up short.  That is until I found watchr.

Watchr gave me the file change detection capabilities I needed, and the extensibility to do whatever I want when a file has been detected as changed.  This made it incredibly easy to hook up some autotest goodness in my .NET world.

You'll have to have ruby installed, and gems.  Then, the very first thing you'll have to do is

gem install watchr --source=http://gemcutter.org

Here is my watchr script:

require 'autotest.rb'

watch( '^.*UnitTest.*.cs$' ) do |match|
  run_test(match.to_s)
end

This is basically just a regex that says to watch any *.cs files that also contain the string “UnitTest”, and when it finds a change in a file matching that description, call run_test with the matched file name.

So all the magic is in autotest.rb… lets check it out:

require 'rexml/document'

def build(test_project)
  `msbuild /nologo #{test_project}`
end

def mstest(test_container, test_results_file, tests_to_run)
  tests_to_run = ([""] << tests_to_run).flatten

  File.delete(test_results_file) if File.exists?(test_results_file)
  `mstest /nologo /resultsfile:#{test_results_file} /testcontainer:#{test_container} #{tests_to_run.join(" /test:")}`
  test_results = process_mstest_results(test_results_file)
  File.delete(test_results_file) if File.exists?(test_results_file)

  return test_results
end

def process_mstest_results(results_file)
  results = {}
  File.open(results_file) do |file|
    xml = REXML::Document.new(file)

    results[:num_tests] = xml.get_elements("//UnitTestResult").length
    failures = []
    xml.elements.each("//UnitTestResult[@outcome='Failed']") do |e|
      failure = {}
      failure[:message] = e.elements["Output/ErrorInfo/Message"].get_text

      stack = e.elements["Output/ErrorInfo/StackTrace"].get_text.value
      stack_match = /^.*at (.*) in(.*):line (\d+)$/.match(stack)

      failure[:stack] = stack_match[1] if stack_match
      failure[:location] = stack_match[2] if stack_match
      failure[:line] = stack_match[3] if stack_match

      failure[:stack] = stack if !stack_match

      failures << failure
    end
    results[:failures] = failures
  end

  return results
end

def show_results(results)
  puts "#{results[:num_tests]} tests run (#{results[:failures].length} failures)"
  results[:failures].each do |failure|
      puts "---------------------------------------"
      puts "Message: #{failure[:message]}"
      puts "Location: #{failure[:location]}"
      puts "Line: #{failure[:line]}"
      puts "Stack Trace: #{failure[:stack]}"
  end
end

def run_test(file_name)
  test_container = ""
  test_results_file = "result.trx"
  test_project = ""

  system("cls")
  system("echo Detected change in:")
  system("echo   #{file_name}")
  system("echo Building and Testing")

  test_namespace = ''
  test_class = ''
  test_names = []

  File.open(file_name, "r") do |f|
    f.each do |line|
      ns_match = /^namespace (.*)$/.match(line)
      test_namespace = ns_match[1] if ns_match

      class_match = /^\s*public class (.\w*).*$/.match(line)
      test_class = class_match[1] if class_match

      test_name_match = /^\s*public void (\w*).*$/.match(line)
      test_names << test_name_match[1] if test_name_match
    end
  end

  test_names = test_names.map { |n| "#{test_namespace}.#{test_class}.#{n}" }

  build(test_project)
  results = mstest(test_container, test_results_file, test_names)
  show_results(results)
end

The key parts (I think) are the fact that I’m using MSTest to run my tests (this can easily be modified to run your framework of choice… note MSTest is not my choice ;) ).  The result parsing is also specific to the MSTest output format, but should be simple enough for any framework that can output XML. Also, I'm making some assumptions based on my project... we've got one unit test project, so I know I can run tests in a single DLL, and rebuilding only that project, I don't have to worry about choosing the correct project and output dll to build and run tests in.

To get the thing up and running, just run

watchr <path to watchr script>

Please, use/adapt/give feedback/whatever at will.

Go forth and autotest, .NET comrades!

25Feb/091

Making the ‘using’ statement, more usable

I've felt the pain of having the using statement not being able to return a value before, and just chalked it up to a limitation of the language.

I never considered trying to find a better way, and usually ended up with something like:

void DoSomething()
{
    XmlDocument xml = new XmlDocument();
    using(var reader = new StreamReader(@"c:\somexmlfile.xml"))
    {
        xml.Load(reader);
    }

    // do something useful with xml
}

or

void DoSomething2()
{
    XmlDocument xml = new XmlDocument();
    using( var reader = new StreamReader( @"c:\somexmlfile.xml" ) )
    {
        xml.Load( reader );
        // do something useful with xml
    }
}

Neither of which particularly suited me. Because

  • First example: Declaring the variable outside the scope of the block feels weird
  • Second example: Performing whatever operation inside the using block, means the file (or other resource) doesn't get released until the operation has completed.

After Shawn mentioned something about this at his Indy Alt.Net Clojure talk, I started thinking about it a little bit, and then I had a real need for it (again), and decided to come up with something better.  Turns out what I wanted was blatantly simple.

TResult UsingReturn(TDisposable toUse, Func func)
    where TDisposable : IDisposable
{
    using (toUse)
    {
        return func(toUse);
    }
}

Now the above example turns into:

void DoSomething3()
{
    var xml = UsingReturn( new StreamReader( @"c:\cdf.xml" ), reader =>
                {
                    var doc = new XmlDocument();
                    doc.Load( reader );
                    return doc;
                });
}

I'm not sure where this thing should live (e.g. some static utility class, extension method on IDisposable), or even what it should be called.  Any ideas?

11Dec/089

static reflection – Method Guards

Another bit of magic with static reflection. Refer to my last post for a little more explanation of static reflection, and a sweet implementation (IMO) of INotifyPropertyChanged using static reflection.

In the past several years, on several projects, I've seen many lines of code at the beginning of public interface methods that look like:

    public class WebServer
    {
        public void BootstrapServer(int port, string rootDirectory, string serverName)
        {
            if( rootDirectory == null )
            {
                throw new ArgumentNullException( "rootDirectory" );
            }
            if( serverName == null )
            {
                throw new ArgumentNullException( "serverName" );
            }

            // Bootstrap the server
        }
    }

I realize the need, since we don't have real DbC in .NET (yet), but I REALLY dislike this and feel it to be a pretty bad smell.  It feels unDRY, obscures essence, and I just plain don't like it. ;)

So, here is an implementation that makes it tolerable, if not enjoyable (because of the coolness of using static reflection), because I think it actually adds to the essence and overall readability of a given method.

This is what the above code can now look like:

    public class WebServer
    {
        public void BootstrapServer( int port, string rootDirectory, string serverName )
        {
            Guard.IsNotNull( () => rootDirectory );
            Guard.IsNotNull( () => serverName );

            // Bootstrap the server
        }
    }

And here is the implementation:

    public static class Guard
    {
        public static void IsNotNull<T>(Expression<Func<T>> expr)
        {
            // expression value != default of T
            if (!expr.Compile()().Equals(default(T)))
                return;

            var param = (MemberExpression) expr.Body;
            throw new ArgumentNullException(param.Member.Name);
        }
    }

Lovin it!  Hope you do too.

8Dec/087

static reflection – INotifyPropertyChanged

I'm not going to delve into the definition of static reflection here, but you'll see how it's implemented, and how I found it can help me with implementing INotifyPropertyChanged.

Now, I've never been a fan of INotifyPropertyChanged myself, mostly because it feels wet (read: not DRY).  I'm working on a WPF app at the moment, and have come to realize, if I embrace INotifyPropertyChanged, I get to take full advantage of the excellent WPF databinding story.

Here is what a normal use of INotifyPropertyChanged looks like:

    public class Person : INotifyPropertyChanged
    {
        private string _firstName;
        private string _lastName;

        public event PropertyChangedEventHandler PropertyChanged;

        public string FirstName
        {
            get { return _firstName; }
            set
            {
                if (_firstName != value)
                {
                    _firstName = value;
                    FirePropertyChanged("FirstName");
                }
            }
        }

        public string LastName
        {
            get { return _lastName; }
            set
            {
                if (_lastName != value)
                {
                    _lastName = value;
                    FirePropertyChanged("LastName");
                }
            }
        }

        private void FirePropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }
    }

Here is what the static reflection use of INotifyPropertyChanged looks like:

    public class PersonStaticReflection : NotifyPropertyChanged
    {
        private string _firstName;
        private string _lastName;

        public string FirstName
        {
            get { return _firstName; }
            set { SetProperty(()=> FirstName, ()=> _firstName, value); }
        }

        public string LastName
        {
            get { return _lastName; }
            set
            {
                SetProperty( () => LastName, () => _lastName, value, () =>
                   {
                       // do something useful here
                   });
            }
        }
    }

Doesn't that just feel DRYer?  It does to me!

There are several important pieces to note:

  • Inheriting from NotifyPropertyChanged, this is the class that holds the SetProperty method, and hides the static reflection magic.
  • We're calling SetProperty with three arguments in the FirstName property
    • first: a LINQ Expression pointing to the property we're changing
    • second: a LINQ Expression pointing to the field to backing the property
    • third: the new, incoming value
  • We're calling SetProperty with a fourth argument in the LastName property
    • fourth: an action that will get executed only if the values were different
  • The SetProperty method, is going to look at the current value of the field, and the incoming value.  If the two are different, it will assign the new value to the field, and then fire the NotifyPropertyChanged event, with the name of the property given via the first argument.  I ended up pulling this into its own class so I could use it as the layer supertype in my View Model layer. Here is the implementation:

    public class NotifyPropertyChanged : INotifyPropertyChanged
    {
        public event PropertyChangedEventHandler PropertyChanged;

        protected void SetProperty < T>( Expression < Func> propExpr, Expression> fieldExpr, T value )
        {
            SetProperty(propExpr, fieldExpr, value, ()=> { });
        }

        protected void SetProperty < T>( Expression < Func> propExpr, Expression < Func < T>> fieldExpr, T value, Action doIfChanged )
        {
            var prop = (PropertyInfo)((MemberExpression)propExpr.Body).Member;
            var field = (FieldInfo)((MemberExpression)fieldExpr.Body).Member;

            var currVal = prop.GetValue( this, null );

            if( currVal == null && value == null )
                return;
            if( currVal == null || !currVal.Equals( value ) )
            {
                field.SetValue( this, value );
                doIfChanged();

                if( PropertyChanged != null )
                    PropertyChanged( this, new PropertyChangedEventArgs( prop.Name ) );
            }
        }
    }

Questions/comments/likes/dislikes? Let me know.

17Sep/081

a generic one-to-one mapping class

Another "tip/trick" style post, but thought it may prove useful to someone (or so I can find it again later!)...

Sometimes I find myself needing to map instances/values of one type to another.  For example, on my current project we have an enumeration in our communications layer, and a VERY similar one in the domain layer.  The reason for this is so we don't have to be referencing the communications layer version all over in the domain code.  So, there is naturally a one to one mapping between these enumerations.

Consider the following enumerations:

enum Polygons
{
    Triangle,
    Rectangle,
    Pentagon,
    Other
}

enum NumSides
{
    Three,
    Four,
    Five,
    More
}

This is the code I usually write to solve this problem:

private Polygons MapShapes( NumSides sides )
{
    switch( sides )
    {
        case NumSides.Three:
            return Polygons.Triangle;
        case NumSides.Four:
            return Polygons.Rectangle;
        case NumSides.Five:
            return Polygons.Pentagon;
        case NumSides.More:
            return Polygons.Other;
        default:
            throw new NotSupportedException(
                string.Format( "Mapping to Polygons from NumSides value {0}
                    is not supported", sides.ToString() ) );
    }
}

private NumSides MapShapes( Polygons polygon )
{
    switch( polygon )
    {
        case Polygons.Triangle:
            return NumSides.Three;
        case Polygons.Rectangle:
            return NumSides.Four;
        case Polygons.Pentagon:
            return NumSides.Five;
        case Polygons.Other:
            return NumSides.More;
        default:
            throw new NotSupportedException(
                string.Format( "Mapping to NumSides from Polygons value {0}
                    is not supported", polygon.ToString() ) );
    }
}

It turns out we had 3 said enumerations.  So picture the above, copied 3 times.  This thing was just begging for abstraction!

I came up with a Generic (proper) Map class that you can add mappings to and retrieve the corresponding mapped value of the other type... both directions.  Here is the implementation:

public class Map
{
    private Dictionary _oneToTwo;
    private Dictionary _twoToOne;

    public Map()
    {
        _oneToTwo = new Dictionary();
        _twoToOne = new Dictionary();
    }

    public Map Add( Type1 value1, Type2 value2 )
    {
        _oneToTwo.Add( value1, value2 );
        _twoToOne.Add( value2, value1 );
        return this;
    }

    public Type1 this[Type2 value]
    {
        get
        {
            if( !_twoToOne.ContainsKey( value ) )
            {
                throw new NotSupportedException(
                    string.Format( "Mapping from type {0} to type {1} with
                                    value {2} is not defined",
                        typeof( Type2 ).Name,
                        typeof( Type1 ).Name,
                        value.ToString() ) );
            }
            return _twoToOne[value];
        }
    }

    public Type2 this[Type1 value]
    {
        get
        {
            if( !_oneToTwo.ContainsKey( value ) )
            {
                throw new NotSupportedException(
                    string.Format( "Mapping from type {0} to type {1} with
                                    value {2} is not defined",
                        typeof( Type1 ).Name,
                        typeof( Type2 ).Name,
                        value.ToString() ) );
            }
            return _oneToTwo[value];
        }
    }
}

And, here it is in action:

Map<NumSides, Polygons> shapeMap = new Map<NumSides, Polygons>()
                                    .Add( NumSides.Three, Polygons.Triangle )
                                    .Add( NumSides.Four, Polygons.Rectangle )
                                    .Add( NumSides.Five, Polygons.Pentagon )
                                    .Add( NumSides.More, Polygons.Other );

// shape1 value is Polygons.Rectangle
Polygons shape1 = shapeMap[NumSides.Four]; 

// shape2 value is NumSides.Three
NumSides shape2 = shapeMap[Polygons.Triangle];

This not only works with enumerations, but any type.  I see an extension to this possibly allowing for a default mapping, and possibly constraining Type1 and Type2 to be IComparable or something like that as well, so you can have more control over your matching than whatever the default matching behavior that the Dictionary uses is.

That's it... enjoy!

Tagged as: , 1 Comment
4Sep/084

looking for a better switch/case statement?

I find myself sometimes wishing I had a better switch/case construct in C#.

My requirements of "better" are:

  • Case statements are automatically scoped
  • I can switch on more than simple types
  • I can have custom logic for my matching criteria

But why not just use if/else if/else...?

Good question, I'm glad you asked! However, I don't have an excellent answer other than personal preference. if/else if/else is okay sometimes, but other times I have a deterministic set of conditions, and a switch type construct feels more symmetrical to me. I loves me some symmetric feeling code, it just feels cleaner somehow.

So I'll present a somewhat contrived example just so you can see what the usage looks like, then we'll see the code.

Usage


public void DoSomething()
{
	object foo = new object();
	object bar = new object();
	object baz = new object();

	Switch<object>.On(baz)
		.Case(x => x.Equals(foo), () =>
		{
			Console.WriteLine("came into foo case");
		})
		.Case(x => x.Equals(bar), () =>
		{
			Console.WriteLine("came into bar case");
		})
		.Default( () =>
		{
			Console.WriteLine("came into default case");
		})
		.Go();
}

The output from the above, is as you'd expect, the default case, since baz wasn't equal to foo or bar.

Implementation


public class Switch<T>
{
	private T _target;
	private List<KeyValuePair<Predicate<T>, Action>> _cases;
	private Action _default;

	public static Switch<T> On(T target)
	{
		return new Switch<T>(target);
	}

	public Switch(T target)
	{
		_target = target;
		_cases = new List<KeyValuePair<Predicate<T>, Action>>();
	}

	public Switch<T> Case(Predicate<T> @case, Action action)
	{
		_cases.Add(new KeyValuePair<Predicate<T>, Action>(@case, action));
		return this;
	}

	public Switch<T> Default(Action action)
	{
		_default = action;
		return this;
	}

	public void Go()
	{
		foreach(var @case in _cases)
			if (@case.Key(_target))
			{
				@case.Value();
				return;
			}
		if (_default != null)
			_default();
	}
}

The only part I don't really like is having to kick it off with the Go() at the end. Any ideas for a better way to kick it off, or at least a better name for it (instead of Go).

Feedback? Ideas?

Update

Paul had a great idea a couple great ideas (see comments) on how to get rid of the Go() at the end, and to force Default to only appear at the end. Here is the new implementation. Usage is the same, just remove the Go().


public class Switch<T>
{
	private T _target;
	private bool _alreadyMatched;

	public static Switch<T> On(T target)
	{
		return new Switch<T>(target);
	}

	public Switch(T target)
	{
		_target = target;
		_alreadyMatched = false;
	}

	public Switch<T> Case(Predicate<T> @case, Action action)
	{
		if (!_alreadyMatched && @case(_target))
		{
			_alreadyMatched = true;
			action();
		}
		return this;
	}

	public void Default(Action action)
	{
		if (!_alreadyMatched)
		{
			_alreadyMatched = true;
			action();
		}
		return this;
	}
}
Tagged as: , 4 Comments
26Aug/080

tfs – error exporting queries to excel

Starting my new project in a new role, as project lead, I need to be managing things in TFS.  The UI for batching these things up is nonexistent, but there is Excel integration so you can do it all in Excel, hit save, and it all goes back to the TFS server... pretty slick I must say (I was actually in the midst of writing such a tool when I realized this functionality already existed OOB).

However, the first time I tried to use this functionality... BLAM, I get smacked with this:

TF80042: The document cannot be opened because you do not have Microsoft Excel 2003 or later, or one of its components installed. For more information, see the Team Foundation Installation Guide.

Isn't that teh suck?

Anyways, there is a sweet write-up on how to fix it here: http://blogs.microsoft.co.il/blogs/srlteam/archive/2007/07/17/Error-when-trying-to-export-queries-to-Excel.aspx.

Thanks Elad!

Tagged as: , , No Comments
22Aug/081

Going Medieval on Your App with Castle MonoRail – Indy ALT.NET

So last night I gave a talk at Indy ALT.NET on Castle MonoRail.  It was really just a sort of intro to MonoRail type of deal, but the cool part was that we held a Dojo after I got done jabbering.

We ended up building a Poll Generator for our dojo activity.  We almost got done in the 45 minutes or so that we dojo'd.  It was a pretty fun activity, and I'd like to do it again sometime soon.

Also, this was really my first public speaking engagement to our technical community, and let me say it was a blast.  Everyone had great things to say, and many great questions were asked too.

I set up a google code repository so you can grab my slidedeck and grab the source for our dojo activity and my demo app.

Maybe next time I'll post before the talk, so I can let people know about it.

Thanks guys for all the great feedback, and thanks to my wife for understanding why I wasn't spending any of my evenings with her this week!

22Aug/080

singly implemented interface… addendum

Wowza!  So I've begun reading LosTechies (tons of great content, highly recommended!), and came across a passage today from Jimmy Bogard, who says what I feel, but what I couldn't get out of my head:

On a sidenote, it always bothered me when people say that an interface with one implementation is a design smell.  No, an interface is used to expose a contract.  Interfaces communicate design intent, far better than a class might.

Exactly!

Tagged as: , No Comments