Adventures in .NET

Mocking Static Methods for Unit Testing

2011-03-15T19:13:00.001-04:00

As you probably know, unit tests are supposed to be fast, lightweight tests of your code logic. They are not supposed to do any disk I/O, network communication, or long-running CPU calculations. If you have cleanly decoupled code that doesn’t call any static methods and everything is programmed to the interface, you can mock the intensive operations very easily.

Although if you’ve tried unit testing a class that calls static methods that perform such intensive operations, you quickly realize that you must separate them out from your code so that they can be mocked. But if the methods are in a library you can’t modify, you usually end up very frustrated. There are a few easy ways to mock static methods, and you can choose which option works best for your needs.

Background

In our example, we have a class that has a single static method. Let’s pretend that this does some intensive activity that you don’t want to do while running your unit test suite. This class is in a library that you can’t modify and make non-static – we’re just looking at the code here as an example.

namespace SomeLibraryYouCantModify
{
    public static class SomeStaticClass
    {
        public static bool SomeStaticMethod(string input)
        {
            // Let's pretend this method hits a database or service.
            return !string.IsNullOrEmpty(input);
        }
    }
}

So we have one method that takes a string and returns bool. Keep this in mind.

Now, here’s an example of the static method being used. Note that we can not (by default) mock the static call – it’s a tight coupling that can not be easily broken.

namespace SomeLibraryYouCanModify
{
    public class SomeUntestableClass
    {
        public int SomeMethod(string input)
        {
            var value = SomeStaticClass.SomeStaticMethod(input);

            return value ? 1 : 0;
        }
    }
}

Below you will find a variety of options to make this class unit testable without the static call.

Option 1 – Wrapper Class

The first option which is extremely easy to do and very Inversion-of-Control-friendly is to make a wrapper class that has the exact same signature as the static methods you’re needing to call, but the only difference is that they are non-static. Each of these methods calls the static version and returns the value (if not void). Then, you can extract an interface to use for wiring up with IoC and mocking (such as with Moq).

In this example, we take the same signature as our static class above, but create a non-static wrapper class.

namespace SomeLibraryYouCanModify
{
    public class StaticWrapper : IStaticWrapper
    {
        public bool SomeStaticMethod(string input)
        {
            return SomeStaticClass.SomeStaticMethod(input);
        }
    }
}

With our static wrapper in place, we now extract an interface:

namespace SomeLibraryYouCanModify
{
    public interface IStaticWrapper
    {
        bool SomeStaticMethod(string input);
    }
}

Perfect. Now we have a non-static wrapper class to our static methods that can be mocked. Here’s how to use it in the caller class:

namespace SomeLibraryYouCanModify
{
    public class WrapperMethod
    {
        IStaticWrapper _wrapper;

        public WrapperMethod(IStaticWrapper wrapper)
        {
            _wrapper = wrapper;
        }

        public int SomeMethod(string input)
        {
            var value = _wrapper.SomeStaticMethod(input);

            return value ? 1 : 0;
        }
    }
}

This class uses constructor injection, but you can do any Inversion-of-Control style you prefer (property injection, etc.). The main point is that we now have a hook where we can insert a mocked wrapper that does not call the static method. Here’s how our test class might look:

    [TestClass]
    public class WrapperMethodTests
    {
        private class TestWrapper : IStaticWrapper
        {
            public bool SomeStaticMethod(string input)
            {
                return !string.IsNullOrEmpty(input);
            }
        }

        [TestMethod]
        public void SomeMethod_GivenNull_ShouldReturnZero()
        {
            var wrapper = new TestWrapper();

            var wm = new WrapperMethod(wrapper);

            var output = wm.SomeMethod(null);

            Assert.AreEqual(0, output);
        }
    }

Notice how the TestWrapper is a private class just used for unit testing, and it does not do any time or I/O intensive operations. This allows our unit tests to execute quickly, providing quick turn-around when things break.

You could also use a mocking framework like Moq to create a mocked IStaticWrapper in the test example above.

Option 2 – Delegates

If the amount of static operations you’re trying to mock is small, say one or two method calls, you may want to go the delegate route. In this approach, you take optional delegates into the constructor so that by default the class calls the static method, but in your unit tests you can specify a custom delegate (such as a lambda method) that is called instead.

Here’s our caller class using the delegate method:

namespace SomeLibraryYouCanModify
{
    public class DelegateMethod
    {
        Func<string, bool> _delegate;

        public DelegateMethod()
        {
            _delegate = SomeStaticClass.SomeStaticMethod;
        }

        public DelegateMethod(Func<string, bool> method)
        {
            _delegate = method;
        }

        public int SomeMethod(string input)
        {
            var value = _delegate(input);

            return value ? 1 : 0;
        }
    }
}

If you aren’t familiar with generic delegates, Func<T, TResult> used above is a delegate for a method that takes a parameter of type T and returns a result of type TResult. So now our class, by default, sets the private delegate field to the static method, but in our unit tests we can specify a custom method instead. Here’s a unit test using this approach that passes a lambda into the constructor:

    [TestClass]
    public class DelegateMethodTests
    {
        [TestMethod]
        public void SomeMethod_GivenNull_ShouldReturnZero()
        {
            var dm = new DelegateMethod(i => !string.IsNullOrEmpty(i));

            var output = dm.SomeMethod(null);

            Assert.AreEqual(0, output);
        }
    }

We get the same result as the wrapper method – the test executes quickly, does not call the static method, and we can verify that the logic inside SomeMethod is correct.

Option 3 – Moles

Moles is an isolation framework from Microsoft that allows you to mock static method calls without rewriting any implementation code. You can even mock calls to .NET framework methods and properties, like DateTime.Now. The benefits are easy to write unit tests and less refactoring time, although at the expense of maintaining tightly-coupled code. Another drawback of Moles I’ve experienced is that it does not work well in a team environment with Team Foundation Server, because it creates proxy DLLs that are hosted in your unit test project, and multiple users checking out and checking in these DLLs becomes a pain very quickly, especially since the default checkout action is an exclusive lock. However, if you’re a sole developer working on a project, it is a worthwhile choice.

You can download Moles (with or without Pex) from Microsoft Research’s Moles Project site. Make sure that you download the correct version for your CPU (x86 vs x64).

After installing, you can right click the reference to the library you’d like to mole in your unit test project, and select Add Moles Assembly.

Now that a Moles assembly has been added to the project, you can now create a unit test and mock that call. You must make sure to import the “.Moles” version of the namespace as seen in the example below. All types in the assembly that can be mocked begin with the letter “M”, and for static methods, the method becomes a property (named with the method name followed by all of the parameter types) that is of a delegate type. Then you can “set” that property to a new delegate, such as a lambda in the example below:

using SomeLibraryYouCantModify.Moles;

namespace LibraryTestProject
{
    [TestClass]
    public class MoledTests
    {
        [TestMethod]
        [HostType("Moles")]
        public void SomeMethod_GivenNull_ShouldReturnZero()
        {
            var c = new SomeUntestableClass();

            MSomeStaticClass.SomeStaticMethodString = i => !string.IsNullOrEmpty(i);

            var output = c.SomeMethod(null);

            Assert.AreEqual(0, output);
        }
    }
}

I’ve bolded the interesting lines. First, you have to import the “.Moles” namespace, as I mentioned earlier. Second, you must add the HostType(“Moles”) to any methods that are to be run in the Moles host. If a test method is not run in the Moles host, it will not be able to use the Moled type, and will let you know with an exception. Finally, the “SomeStaticClass” has a moled “MSomeStaticClass” that provides the mockable methods. The “SomeStaticMethod” method becomes “SomeStaticMethodString”, with the String being added to the name to represent the type of the first and only parameter to the method. This allows for method overloading, as different parameter types will cause different property names on the moled type. Then, the property is set to the given lambda, which is identical to the Delegates example above.

Conclusion

Out of the three methods, I end up preferring the Wrapper method the most, because it is easy to use with IoC containers and Moq. However, it is probably the most amount of work, because you have to create 2 new types, one for the wrapper class and the other for the interface. Also, it means that you have an entire type that has zero coverage, because you can not write unit tests for this wrapper class as it would call the static method.

The delegate method is great for one or two method isolation, as it’s easy to do, doesn’t need to involve the IoC container, and can be easily mocked with constructor overloads. However, it’s the least intuitive code to read, and is clunky to use for more than two method calls.

The Moles method is certainly clever and very impressive on first use. It works great for small projects with one developer, and can allow you to achieve greater code coverage very quickly. However, it is slower to start the unit test run due to the Moles host, it doesn’t help you decouple your code, and it is a pain for multiple developers working on the same project due to source control conflicts.

Obviously, the ideal situation is to have a non-static method to call. If you can get the developer of the library to do it for you, they can create a non-static version of the type/methods that are called by the static version, so that their existing static API is maintained and you get the benefit of being able to wire up the dependency with dependency injection. Clearly, though, this isn’t always possible.

Hope this helps!

ObservableStack

2010-12-27T09:45:00.001-05:00

I had been looking around in the .NET framework for a Stack<T> equivalent of ObservableCollection<T> to use in a WPF application. Couldn’t find one, so I implemented one based on those two classes. Hope this helps!

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Collections.Specialized;
using System.ComponentModel;
using System.Collections;

namespace AdventuresDotNet
{
    public class ObservableStack<T> : IEnumerable<T>, ICollection, INotifyCollectionChanged, INotifyPropertyChanged
    {
        T[] _array;
        const int _defaultCapacity = 4;
        static T[] _emptyArray;
        int _size;
        object _syncRoot;
        int _version;

        static ObservableStack()
        {
            _emptyArray = new T[0];
        }

        public ObservableStack()
        {
            _array = _emptyArray;
            _size = 0;
            _version = 0;
            _syncRoot = new object();
        }

        public ObservableStack(IEnumerable<T> collection)
        {
            if (collection == null)
                throw new ArgumentNullException("collection");

            var is2 = collection as ICollection<T>;

            if (is2 != null)
            {
                int count = is2.Count;
                _array = new T[count];
                is2.CopyTo(_array, 0);
                _size = count;
            }
            else
            {
                _size = 0;
                _array = new T[4];
                using (var enumerator = collection.GetEnumerator())
                {
                    while (enumerator.MoveNext())
                    {
                        this.Push(enumerator.Current);
                    }
                }
            }
        }

        public ObservableStack(int capacity)
        {
            if (capacity < 0)
                throw new ArgumentException("Invalid capacity.");

            _array = new T[capacity];
            _size = 0;
            _version = 0;
        }

        public void Push(T item)
        {
            if (_size == _array.Length)
            {
                T[] dest = new T[(_array.Length == 0) ? 4 : (2 * _array.Length)];
                Array.Copy(_array, 0, dest, 0, _size);
                _array = dest;
            }

            _array[_size++] = item;
            _version++;

            OnCollectionAdded(item);
            OnPropertyChanged("Count");
        }

        public T Pop()
        {
            if (_size == 0)
                throw new InvalidOperationException("Empty stack, can not pop.");

            _version++;
            T local = _array[--_size];
            _array[_size] = default(T);

            OnCollectionRemoved(local, _size);
            OnPropertyChanged("Count");

            return local;
        }

        public T Peek()
        {
            if (_size == 0)
                throw new InvalidOperationException("Empty stack, can not peek.");

            return _array[_size - 1];
        }

        public event NotifyCollectionChangedEventHandler CollectionChanged;

        public event PropertyChangedEventHandler PropertyChanged;

        void OnCollectionReset()
        {
            var c = CollectionChanged;

            if (c != null)
                c(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Reset));
        }

        void OnCollectionAdded(object item)
        {
            var c = CollectionChanged;

            if (c != null)
                c(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Add, item));
        }

        void OnCollectionRemoved(object item, int index)
        {
            var c = CollectionChanged;

            if (c != null)
                c(this, new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Remove, item, index));
        }

        void OnPropertyChanged(string propertyName)
        {
            var p = PropertyChanged;

            if (p != null)
                p(this, new PropertyChangedEventArgs(propertyName));
        }



        public IEnumerator<T> GetEnumerator()
        {
            return new Enumerator(this);
        }

        System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator()
        {
            return new Enumerator(this);
        }
        
        public void Clear()
        {
            Array.Clear(_array, 0, _size);
            _size = 0;
            _version++;

            OnCollectionReset();
            OnPropertyChanged("Count");
        }

        public bool Contains(T item)
        {
            int index = _size;

            var comparer = EqualityComparer<T>.Default;

            while (index-- > 0)
            {
                if (item == null)
                {
                    if (_array[index] == null)
                        return true;
                }
                else if (_array[index] != null && comparer.Equals(_array[index], item))
                {
                    return true;
                }
            }

            return false;
        }

        public void CopyTo(T[] array, int arrayIndex)
        {
            if (array == null)
                throw new ArgumentNullException("array");

            if (arrayIndex < 0 || arrayIndex > array.Length)
                throw new ArgumentOutOfRangeException("arrayIndex");

            if ((array.Length - arrayIndex) < _size)
                throw new ArgumentException();

            Array.Copy(_array, 0, array, arrayIndex, _size);
            Array.Reverse(array, arrayIndex, _size);
        }

        public int Count
        {
            get { return _size; }
        }
        
        public bool IsSynchronized
        {
            get { return false; }
        }

        public object SyncRoot
        {
            get { return _syncRoot; }
        }

        void ICollection.CopyTo(Array array, int index)
        {
            Array.Copy(this._array, 0, array, index, this._size);
            Array.Reverse(array, index, this._size);
        }

        public struct Enumerator : IEnumerator<T>, IDisposable, IEnumerator
        {
            ObservableStack<T> _stack;
            int _index;
            int _version;
            T currentElement;

            internal Enumerator(ObservableStack<T> stack)
            {
                _stack = stack;
                _version = _stack._version;
                _index = -2;
                currentElement = default(T);
            }

            public T Current
            {
                get
                {
                    if (_index < 0)
                        throw new InvalidOperationException();

                    return currentElement;
                }
            }

            public void Dispose()
            {
                _index = -1;
            }

            object IEnumerator.Current
            {
                get
                {
                    if (_index < 0)
                        throw new InvalidOperationException();

                    return currentElement;
                }
            }

            public bool MoveNext()
            {
                bool flag;

                if (_version != _stack._version)
                    throw new InvalidOperationException("Version mismatch.");

                if (_index == -2)
                {
                    _index = _stack._size - 1;
                    flag = _index >= 0;

                    if (flag)
                        currentElement = _stack._array[_index];

                    return flag;
                }

                if (_index == -1)
                    return false;

                flag = --_index >= 0;

                if (flag)
                {
                    currentElement = _stack._array[_index];
                    return flag;
                }

                currentElement = default(T);
                return flag;
            }

            public void Reset()
            {
                if (_version != _stack._version)
                    throw new InvalidOperationException("Version mismatch.");

                _index = -2;
                currentElement = default(T);
            }
        }
    }
}

HttpContext.Current and Threads with QueueUserWorkItem

2010-10-04T14:51:00.003-04:00

If you’ve got an ASP.NET (including MVC) application that uses ThreadPool.QueueUserWorkItem with a reset event or anything of the like, you can not access HttpContext.Current (or rather, it is null) on those threads. This makes exception logging difficult, especially if you want to log the URL that is currently being requested.

After a little digging, I discovered that the current HttpContext is actually in thread-local storage, which explains why child threads don’t have access to it. Luckily, you can pass a reference to it in your child thread. Include a reference to HttpContext in the “state” object of your callback method, and then you can store it to HttpContext.Current on that thread. If you notice, HttpContext.Current is not a read-only property – it has a setter as well. Set HttpContext.Current = myStateObj.HttpContextReference where myStateObj is your state object.

I feel like this post is a bit self-explanatory, but here’s an obligatory example if you don’t follow:

private AutoResetEvent s_reset = new AutoResetEvent(false);

protected void Page_Load(object sender, EventArgs e)
{
    var state = new WorkerState() { HttpContextReference = HttpContext.Current };
    ThreadPool.QueueUserWorkItem(new WaitCallback(Worker), state);

    try
    {
        s_reset.WaitOne();
    }
    finally
    {
        s_reset.Close();
    }
}

void Worker(object state)
{
    var mystate = state as WorkerState;

    if (mystate != null && mystate.HttpContextReference != null)
    {
        HttpContext.Current = mystate.HttpContextReference;
    }

    HttpContext.Current.Response.Write("Threading!");

    s_reset.Set();
}

private class WorkerState
{
    public HttpContext HttpContextReference { get; set; }
}

And, of course, it works:

Hope this helps!

Combining and Abusing Delegates

2010-09-20T14:00:00.002-04:00

I had never before thought much about combining delegates until I came across some code that combined them using lambdas, and it got me thinking about other ways to use them. Consider the following example. Note: crazy code ahead!

public class Programmer
{
    Action<string> a;

    public Programmer(string name)
    {
        this.Name = name;
    }

    public string Name { get; set; }

    public bool ShouldDesign
    {
        set
        {
            if (value)
                a += s => { Console.WriteLine(Name + " should design " + s); };
        }
    }

    public bool ShouldDevelop
    {
        set
        {
            if (value)
                a += s => { Console.WriteLine(Name + " should develop " + s); };
        }
    }

    public bool ShouldDeploy
    {
        set
        {
            if (value)
                a += s => { Console.WriteLine(Name + " should deploy " + s); };
        }
    }

    public void Work(string programName)
    {
        a(programName);
    }
}

And then used in a console app like this:

static void Main(string[] args)
{
    var paul = new Programmer("Paul");
    paul.ShouldDesign = true;
    paul.ShouldDevelop = true;
    paul.ShouldDeploy = false;

    paul.Work("my application");

    Console.ReadKey();
}

And the output…

I do not encourage the kind of code I’ve created here, but maybe this will get you thinking!

Thoughts on the Microsoft Ecosystem

2010-09-14T22:53:00.001-04:00

I had the great opportunity to touch a Windows Phone 7 device at the Jacksonville Code Camp a few weeks ago, and it sold me – I’ll likely give up my iPhone 4 for a Windows Phone 7 device when they ship this fall. The biggest selling point as a C# developer is that I can develop both data-driven apps in Silverlight and games in XNA for Windows Phone 7 in the language I use every day – C#. So that got me thinking about where else C# and the .NET platform can be used, both at work and at home.

Windows 7 client apps in WPF (with multi-touch for tablets)
Rich Internet Apps with Silverlight 4 (again with multi-touch)
Websites with ASP.NET and ASP.NET MVC
Scaffolding data-driven sites with ASP.NET Dynamic Data
Windows Phone 7 data-driven apps in Silverlight
Games for Windows Phone 7 with XNA
Games for PC with XNA
Games for Xbox 360 with XNA
Middleware real-time services with WCF
Middleware queued services with WCF, WF, and MSMQ
SQL Server integration with CLR stored procedures
Windows Media Center apps with the Media Center SDK
Embedded device apps with WPF (Windows Embedded)
Small-scale embedded devices with .NET Micro Framework (including Netduino)
Windows Home Server add-ins with the WHS SDK
Cloud apps with the Windows Azure SDK
SharePoint parts and sites
Office add-ins for Outlook, Excel, Word, and others
Surface development with the Surface SDK (which will be in our homes within a few years)
… and probably a dozen other things I’m forgetting.

That’s a huge list, and I’ve heard complaints from people that the ecosystem has gotten too big, and therefore too much to keep track of and learn. I don’t look at it that way – I view all of these varied and important areas as all using the same foundation, C# and the .NET framework. If you know C# and the framework, you can jump from one to the other with a minimal learning curve. A WPF developer can jump to Silverlight and then to Surface and then to Windows Media Center and then to Windows Phone 7 with Silverlight without much to learn. An ASP.NET developer can jump to ASP.NET MVC and to Windows Azure and to SharePoint, again with minimal learning. Compared to jumping to another framework or another language, jumping between any of these technologies is relatively painless.

It’s a great time to be a .NET developer, and the potential with all of these technologies excites me!

My First Workflow Foundation (WF) 4 App

2010-08-20T19:08:00.001-04:00

I came across a book in our company’s “library” today – Microsoft Windows Workflow Foundation, Step by Step – and I started thinking about whether or not I should try to learn WF. Frankly, I haven’t been interested so far. Being a front-end developer, I haven’t really developed many service-level applications or processes, and of the ones I’ve touched, it seems like remoting, WCF, and/or MSMQ works rather well for those tasks. However, I came across NServiceBus this past week and it got me thinking more in the mindset of a service designer, and WF piqued my interest. A good developer tries to be well-rounded and knowledgeable about other technologies, even if he or she doesn’t use them on a daily basis.

I started flipping through the first chapter of this book. I quickly realized that it’s a 3 year old book (a lifetime in software technologies) and is about .NET 3.0 – the red-headed stepchild release of .NET. WF, of course, has seen 2 revisions since, with .NET 3.5 and again with 4.0. Nonetheless, I enjoyed the first chapter, and I started to see where WF could be useful. (Despite, that is, a question I posted on twitter asking if anyone has used WF, to which I got zero responses.)

I came home, fired up my beast of a work laptop (Core i7 4core/8thread, 8GB RAM), and launched Visual Studio 2010. File – New Project. Immediately I noticed a difference from the first chapter of this book. In the .NET 3 version, you have to choose between a Sequential or State Machine workflow type and then between a console app or library, or an “activity library”, or an empty workflow project. In VS2010, you only have 2 non-library Workflow project types – WCF Workflow Service, and Workflow Console App. I chose the Workflow Console App because it more closely matched the example. Then the similarities came to a screeching halt.

I hadn’t kept up with WF, otherwise I should have known this. WF in 4.0 uses XAML to describe workflows, and the only “code” in the workflow are “expressions” in… wait for it… VB. Yes, even though I created a C# Workflow Console App, the expressions are in Visual Basic. Furthermore, the example in the book is a .cs file (not .xaml), and has an accompanying .Designer.cs file as a “code-behind”. Better still, when you create “Code” activities in the older WF, they are methods in a C# file. The only equivalent to the “Code” activity I found in WF 4 is the “InvokeMethod” activity, which can only call a method on a type not defined in the workflow.

Still, I was able to accomplish a fairly basic If/Else workflow in WF4. Here’s what it looks like:

Fairly trivial. If a “PostalCodeIsValid”, then I write a line to the console saying it’s valid, and if not, I write a line saying it’s not. Notice the VB ampersands for string concatenation in the “Text” fields.

Look at the Condition field. I’m executing a method on a “Workflow1Helper” static class I created for simplicity. That method simply returns “PostalCode.Length == 5” which is not a true postal code validation routine, but could be replaced with one. Luckily, the Workflow1Helper class is written in C#.

It seems like this is the pattern for WF4 workflows – define your workflow in XAML, and farm out your code to other types. Makes since, especially from a separation of concerns aspect, but it’s hardly similar to WF in .NET 3.0.

So where does that PostalCode field come from? You must define it as an “Argument”. If you look at the bottom of the workflow designer, you’ll see this pane:

The Arguments tab brings up this pane:

That’s where I created the PostalCode argument. You can define any type and number of arguments you want, think of them as “parameters” to your workflow when you invoke it (more on invocation later). Also note you can assign a Default Value, i.e. “New MyType()” (alas, sigh, again in VB.)

Lastly, the invocation. There’s a Program.cs file that gets created as part of the project, and it’s a standard console app entry point class. I just had to modify the invocation part to pass the PostalCode argument:

(I apologize for the code-screenshot, I am lazy and haven’t installed the PreCode plug-in yet.)

Obviously, hitting F5 will run the app, and we get a message saying it’s valid. Yay.

Now time for the dramatic conclusion. WF4 seems much more polished than WF in .NET 3 appears in the book. I love that it’s XAML (although you really don’t want to go in and modify it, it’s pretty ugly), and I love that the code is separated from the workflow logic. It’s all very professional – easy to understand, self-documenting processes, and very easy to grasp. I also created my second WF app, this time as a WCF service, and I think that’s a much more useful paradigm than a console app, especially if it’s possible to use with a MSMQ binding (which I haven’t tried).

For the negatives, I dislike the fact that a C# WF app needs to use VB expressions, because I dislike having to switch gears. I don’t mind coding in VB if I have to, but would it have killed them to allow C# expressions?

I want to read up more on WF, as well as it’s migration from 3 –> 3.5 –> 4, as well as play around more with the WCF version of it before writing another blog post on the subject.

Bottom line, fire up Visual Studio 2010 and create your first WF app and go to town. Come up with some cool real-world ways to use it, and let me know, will you?

Jax Code Camp - August 28th, 2010

2010-08-03T08:50:00.003-04:00

Last year about this time I was just in the process of moving to Jacksonville, but I made sure that despite living out of boxes, I made it to the Jax Code Camp 2009. It was a great event, tons of people (somewhere north of 600?), and had a great after party where you get valuable time socializing with the community.

This year, it's happening again, and I'm a speaker. It's on Saturday, August 28th, 2010 at the UNF campus. You can get more details at http://www.jaxcodecamp.com. Registration is free, and there's many sessions and tracks available, including one all-day session about Windows Phone 7 that you can pop in and out of.

My talk is titled "Dynamic Code with IL and Expressions" and from the IL side I'll be covering how to use DynamicMethod to create functions and methods at runtime with IL emit, as well as how to use AssemblyBuilder to create entire types and assemblies at runtime (such as creating derived "proxy" classes for aspect-oriented programming). From the Expression side, I'll show how to parse Expressions for simple key selectors to advanced LINQ providers, and how to create methods (much like you would in IL) with Expressions to do a number of common tasks.

Hope to see you there! Again, it's a free, all-day conference-style event with breakfast, lunch, and an after-party. You won't want to miss it!

A better, more type-safe, alternative to Cast()

2010-06-30T15:23:00.002-04:00

I ran into a limitation in the Cast extension method included with LINQ (Enumerable.Cast<TResult>(this IEnumerable source)), specifically that it does not allow for explicit/implicit conversion operators. The reason for this is that it is an extension method on IEnumerable, not IEnumerable<T>. Therefore the “Current” property (see previous post on IEnumerable<T>) is of type Object, and it can’t perform the cast from type A to Object to type B if there’s a conversion operator on either type.

I wrote a quick extension method to handle this:

public static IEnumerable<TDest> CastAll<TItem, TDest>(this IEnumerable<TItem> items)
{
    var p = Expression.Parameter(typeof(TItem), "i");
    var c = Expression.Convert(p, typeof(TDest));
    var ex = Expression.Lambda<Func<TItem, TDest>>(c, p).Compile();

    foreach (var item in items)
    {
        yield return ex(item);
    }
}

Basically it builds an Expression that takes TItem, performs a type-safe Convert expression to TDest, and compiles that expression to a lambda of type Func<TItem, TDest> once per call (this could be cached outside of the method), and calls this new function on each item. Now it does a direct cast from TItem to TDest, instead of the type-unsafe A to Object to B casting that Cast<T> does.

Hope this helps!

My Apologies

2010-06-10T09:33:00.001-04:00

I accidentally recently marked many valid comments as rejected when going through them (which was long overdue!). I apologize, there were some good posts there that are now lost. I was attempting to reject just one spam one but accidentally had others checked and Blogger decided I wanted to reject all of them.

Meanwhile, I recently discovered that one of my previous posts on extension methods was incorrect. I'll follow up soon (hopefully) with a corrected version.

Understanding C#’s “yield” Keyword and IEnumerable

2010-06-01T16:10:00.006-04:00

One of the interview questions I usually give candidates for .NET developer positions is around IEnumerable<T>. What is it? What pattern does it represent under the hood? How would you use it? You might be surprised to see how many candidates have no idea what it even is, yet they probably use it everyday, or at least it’s older brother, IEnumerable.

IEnumerable and IEnumerable<T> represent a sequence of items that can be iterated over (forward only), and may be lazy evaluated upon iteration. Note that I carefully didn’t use the term “collection”, rather “sequence”, because collection implies that the items are known ahead of time, before evaluation. With IEnumerable and IEnumerable<T>, you can generate objects on the fly as you iterate over the sequence if you wish.

Before we get to IEnumerable<T>, let’s look at IEnumerable. Bring back your .NET 1.1 hats, ladies and gentlemen. IEnumerable, as the “I” in the name suggests, is an interface only. It does not provide any functionality. IEnumerable only defines one method, called GetEnumerator(), that returns an IEnumerator. The purpose of separating IEnumerable and IEnumerator, I believe, is to logically separate the functions of a sequence of items as a whole, and performing the actual iteration over them.

Let’s create a class that implements IEnumerable, called OldEnumerable (since this is before generics in .NET 2.0).

public class OldEnumerable : IEnumerable
{
    public IEnumerator GetEnumerator()
    {
        return new OldEnumerator();
    }
}

Very simple, right? All we’re doing is returning an instance of OldEnumerator. Do note that an actual class that implements IEnumerable would probably be doing a lot more than this, such as providing utility functions or such. Also, a real-world implementation would probably pass some information about the sequence’s state or identity to the constructor of OldEnumerator, which is not only valid but encouraged, since interfaces can not define the required signatures of any constructors.

Now let’s look at OldEnumerator, before we look at a sample of how to use it.

public class OldEnumerator : IEnumerator
{
    int x = 0;

    public object Current
    {
        get { return x; }
    }

    public bool MoveNext()
    {
        return x++ < 100;
    }

    public void Reset()
    {
        x = 0;
    }
}

This class does one thing and one thing well – return numbers from 1 to 100. Notice that it implements the IEnumerator interface, not IEnumerable. This interface dictates the property and two methods you see above – namely the read-only property Current (note the return type of System.Object), MoveNext() which returns boolean, and Reset(). The names should be pretty self explanatory – Current returns the current item, MoveNext() tries to move to the next item (and returns false if it can not), and Reset(), which resets the enumerator to it’s (hopefully) original state.

In this example, we have a private variable x, which is simply returned by Current whenever it is requested. Note that a real-world example would probably throw an exception if MoveNext() had not yet been called. (And this is an important note: MoveNext() must be called to access the first item before Current can be called, according to the way that IEnumerable is used throughout the framework.)

Our MoveNext() method returns whether the value of x is less than 100, then increments x by 1. This allows 100 to be an inclusive maximum value of this sequence. By initializing x to 0, since MoveNext() should be called before any calls to Current, this ensures that the sequence will start at 1. Finally, the Reset() method sets x to 0, and upon the next MoveNext() call, x will start the sequence over again at 1.

So let’s look at an example of how to use our new OldEnumerable and OldEnumerator classes. (This is in the Main() method of a console application.)

var old = new OldEnumerable();

var oldenum = old.GetEnumerator();

while (oldenum.MoveNext())
{
    object i = oldenum.Current;

    Console.WriteLine(i);
}

Console.ReadKey();

As you can see, we first create our IEnumerable class, then call GetEnumerator to get our IEnumerator class. We don’t actually know that we’re working with GetEnumerator here, we’re merely working by contract with IEnumerator. Next, we have a while loop with a precondition of oldenum.MoveNext(), which returns whether or not we can access the next element in the sequence. If we can, we get the Current element (again of type Object), and implicitly call its ToString() method in the call to Console.WriteLine(). We now get the following output:

(I’m assuming you can trust me when I say it starts at 1. In retrospect, going 1 to 10 would have been a better example.)

When you look at IEnumerable/IEnumerator this way, you quickly realize that the values of x were not pre-calculated. Instead, they were lazy evaluated and calculated on the fly. This is why I chose to use the term “sequence” instead of “collection” earlier.

Obviously, calling GetEnumerator and storing it’s output into a new variable, and calling MoveNext() and Current from a “while” loop is not the cleanest way of looping over items. We’d much rather do this:

var old = new OldEnumerable();

foreach (var i in old)
    Console.WriteLine(i);

Console.ReadKey();

Much better. And, best of all, it still works as expected. Why? There’s a compiler trick going on here. To find what it is, we first step through the code.

After highlighting the foreach keyword and hitting F10 to continue stepping, it first highlights the “old” in the statement as seen above. Next step it highlights “in”:

And then on the next step, it highlights “var i”:

What’s going on here? Why is it moving backwards? Actually, it’s performing GetEnumerator(), MoveNext(), and Current in those three steps, in that order. When “old” is highlighted, it calls GetEnumerator() and stores the enumerator in a hidden variable. When “in” is highlighted, it calls MoveNext(), which upon the first iteration is very convenient because it’s called before Current is referenced. Then, when “var i” is highlighted, it calls Current’s getter method and stores the output in a variable (here inferred to be type Object) called “i”.

Thanks to Visual Studio 2010’s new Intellitrace feature, we can see this in action:

The blue arrows indicate code that has been automatically stepped over, and you can see at each stop point (indicated by red Stop-button icons) that the functions mentioned above are called. Furthermore, when we go another iteration through, we see the following:

We see the first call to Console.WriteLine() in the body of our foreach loop, and then MoveNext() is called again followed by Current. This will continue ad nauseum until MoveNext() returns false and giving us an escape from our iteration. If MoveNext() never returns false, the iteration could continue infinitely, or until an exception is thrown.

Also of note is on our second iteration, “old” is not highlighted. This is because we no longer need a new enumerator, since we already have one. So first “in” is highlighted (MoveNext) followed by “var i” (setting the value of Current to “i”).

At the beginning of this post, I mentioned a question I might ask to a candidate: what pattern does this represent under the hood? While it’s not the most straight-forward question (or the most straight-forward answer), it’s an interesting question to ask because it gets the candidate to think. The answer is a “state machine” pattern, where the object operates based on its state, which may be constantly changing, but the state is persisted in the object for a given period of time (such as the object’s lifespan). The “Current” value of x is our state (which could be the current index of an array, for example), and MoveNext() alters our state.

Now let’s look at the generic version of IEnumerable, IEnumerable<T>. It also has a generic enumerator counterpart, IEnumerator<T>. Interestingly enough, the namespaces that contain the generic versions are imported by default with a new project in Visual Studio 2010 / .NET 4, while the IEnumerable/IEnumerator non-generic versions are in a namespace that is not imported by default, System.Collections. I take this to mean that Microsoft is encouraging the adoption of the generic, type-safe versions of them instead of the non-generic versions. In our example, we get for free the added benefit of type inference as well as we no longer need to box the Int32 variable when we return it in the Current getter, probably resulting in better performance due to less IL being generated.

Like IEnumerable, we have GetEnumerator() in IEnumerable<T>. However, it now has an overload, one which returns IEnumerator<T>, the other which returns IEnumerator. The reason for this is simpler than it may appear on the surface -- IEnumerable<T> inherits from IEnumerable for compatibility reasons. You can safely cast an IEnumerable<T> type to IEnumerable for use with legacy code. However, with value types such as our example, you’ll end up adding boxing as well.

Here’s our IEnumerable<T> implementation:

public class NewEnumerable : IEnumerable<int>
{
    public IEnumerator<int> GetEnumerator()
    {
        return new NewEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return new NewEnumerator();
    }
}

As you can see, we have the new, generic GetEnumerator as well as the old, non-generic one. In both cases we’re returning a new instance of the NewEnumerator() class, since it inherits from IEnumerator<T> as well as IEnumerator, making it a safe implicit cast for both. Here’s our IEnumerator<T> implementation:

public class NewEnumerator : IEnumerator<int>
{
    int x = 0;

    public int Current
    {
        get { return x; }
    }

    public void Dispose()
    {
        // do nothing
    }

    object IEnumerator.Current
    {
        get { return x; }
    }

    public bool MoveNext()
    {
        return x++ < 100;
    }

    public void Reset()
    {
        x = 0;
    }
}

Note that IEnumerator<T> not only inherits from IEnumerator but also IDisposable as well, meaning you can use any IEnumerator<T> inside a “using” block if you wish. Hence, we now have a Dispose method along for the ride. In our implementation, we don’t have any unmanaged resources we need to dispose of, so we do nothing.

We also now have two Current properties – one returns T (in this case, int), the other returns object. When working with the generic version, we’ll be using the T version of Current, and when working this enumerator as IEnumerator, we’ll be using the object version of Current. Since IEnumerator<T> only defines Current, we inherit MoveNext() and Reset() from IEnumerator, and so there’s no change there. Also, here you can see that since Current is now generic and returns int, there is no longer a need to box “x” to an object to return it.

We can now use the NewEnumerator class in exactly the same way as OldEnumerator, but now we don’t need to cast the value to use it as an int. (If we wanted to – we didn’t need to in the previous example as we were only implicitly using ToString() on System.Object.)

var newenum = new NewEnumerable();

foreach (int i in newenum)
    Console.WriteLine(i);

Console.ReadKey();

So that’s all well and good. Now, how do we use the “yield” keyword, and why did I tie it in with a post on IEnumerable<T>?

Because it builds for you an automatic IEnumerator<T>.

That’s pretty much all it does. That – and it maintains the state of the code around it until the next iteration. This may not be the best explanation of the “yield” keyword, but I think it fits.

Here’s a handy extension method to make your code feel more fun and expressive (or confusing and hard-to-maintain, depending on if you’re an optimist or a pessimist).

public static IEnumerable<int> To(this int value, int inclusiveMax)
{
    for (int i = value; i <= inclusiveMax; i++)
        yield return i;
}

This extension method, when placed in a static class in your project will allow you to this:

var ten = 1.To(10);

foreach (var i in ten)
    Console.WriteLine(i);

Since 1 is an int, it gets the extension method To() which returns an IEnumerable<int>. Notice that we have not created a class that inherits from IEnumerable<int>, nor a class that inherits from IEnumerator<int>. The C# compiler does this for us automatically with an anonymous, compiler-generated type. We can pull it up in Reflector and see this type:

Notice that the method starts with <To> – that’s the name of the method that uses this enumerator. Also notice the d__0 identifier – that’s how the .NET runtime knows how to access this compiler-generated type. And finally, notice that it inherits from both IEnumerable<T> and IEnumerator<T>, making it both an enumerable and enumerator at the same time. Our previous examples could have done this, but I separated them out for clarity. If you wanted to do this in the previous examples, just have GetEnumerator() return “this”.

There’s a bunch of thread-safe code going on underneath those method signatures, so try it on your own to see what’s happening – I’ll spare the details here.

Nonetheless, the code does what you would expect – it prints 1 through 10 and stops. As you can see, the yield keyword can save you a ton of code. Here’s another extension method to multiply each element so you can better see the benefits of yield:

public static IEnumerable<int> Multiply(this IEnumerable<int> value, int multiplier)
{
    foreach (int v in value)
        yield return v * multiplier;
}

Now we can use the two together like this:

var dbl = 1.To(10).Multiply(2);

foreach (var i in dbl)
    Console.WriteLine(i);

I hope this helps your understanding of IEnumerable, IEnumerable<T>, IEnumerator, IEnumerator<T>, and the “yield” keyword.

Aside: Sadly the “yield” keyword has no equivalent in VB. It’s a feature that’s been sorely missing, and is still missing in .NET 4.

Update: I realized that in the IDisposable.Dispose() method in the above examples, it should be calling Reset(). The reason for this is that many times IEnumerator<T> is used in a "using" block such that once it is disposed, it should be reset.

VS2010: A First Look at Beta 2 for ASP.NET – Part 1

2009-10-21T18:36:00.002-04:00

If you haven’t yet downloaded Visual Studio 2010 Beta 2, what are you waiting for? Until then, here’s a first look at what’s new for ASP.NET developers with .NET 4 and Visual Studio 2010.

Visual Changes

First off, there’s a new splash screen and icon! I know, I know, this really isn’t important for day-to-day use. But I feel it reflects Microsoft’s renewed commitment to great user experience. Personally, I absolutely love it.

This is the new icon that shows up in the taskbar.

Also there’s a new theme for the overall UI. A bit darker, and 100% more awesome. Even the menus are in WPF, so it feels more “2010” and less “2003”.

New ASP.NET Default Template

When you do File –> New Project and choose the ASP.NET Web Application project template, you now get a much more robust project template by default for new web forms projects, complete with authentication, much like the default ASP.NET MVC project template.

Snippets for ASPX Markup

The awesome snippets that make coding in C# and VB more fun have made their way to ASPX markup. Start typing “<button” and press tab twice to get a button snippet like this. One annoying issue I’ve noticed is that trying to type a normal <a> tag is painful, because it tries to put in an <accessdatasource> snippet instead. Hopefully this will be resolved by the next Beta/RC.

Client ID Mode

There is a new ClientIDMode attribute that can be applied to most server controls that changes the output ID to make it more JavaScript and CSS friendly. Given the following ASPX code:

<asp:Panel ID="pnlContent" runat="server" ClientIDMode="Static">
  This is some content
</asp:Panel>

The following HTML is outputted:

<div id="pnlContent">
  This is some content  
</div>

As compared to the following HTML output without ClientIDMode=”Static”:

<div id="MainContent_pnlContent">
  This is some content
</div>

Which, as you know, if that pnlContent panel was nested 5 layers deep in controls, you would see each of those layers’ IDs present in its ID. This makes the IDs of the elements predictable for use in JavaScript and CSS.

HTML Encoding Block Syntax

Especially when dealing with ASP.NET MVC, but also with WebForms, you end up needing to HTML encode output when using the ASP-style blocks. With the following code-behind:

protected void Page_Load(object sender, EventArgs e)
{
  FooterContent = "Hello <World> !";
}

public string FooterContent { get; set; }

And the following ASPX page:

<%= FooterContent %>

We get the following output:

But if we wanted to HTML encode that output, we previously would need to do this:

<%= Server.HtmlEncode(FooterContent) %>

Now, we can use a new block syntax to do the same, without the function call:

<%: FooterContent %>

And now we get properly escaped HTML output:

Hello &lt;World&gt; !

Which shows up properly in our browser as we would expect:

Creating Your Own IoC Container: Part 2

2009-09-30T18:30:00.002-04:00

In the first part of this post series (which, honestly, I didn’t intend to need a Part 2), I discussed how you can easily create your own container for basic inversion of control (IoC) needs. However, many people may need to use Dependency Injection (DI) as well, so I’ve modified the project to support DI.

Also, a colleague pointed out that there’s another reason why you may want to do this – to simply see how it all works. Sure, you can plop Ninject into a project and start using DI/IoC, but creating your own makes you realize what’s really involved and going on behind-the-scenes.

Here I’ve modified the previous example to support DI, and it took less than an hour.

Warning: I have only briefly tested this code, and have not created unit tests. Before using in production, I’d recommend testing it thoroughly. You’ll also need to get the previous post working on your end before integrating these features. I also noticed a bug after publishing this post reading through the code that if you request an IFoo, and Foo : IFoo has a constructor that is asking for an IFoo parameter, you'll end up in an endless loop and probably stack overflow. Ideally this should detect a circular Resolve() call, and throw an exception.

The IServiceResolver Interface

This bit is not required, however I realized as I was writing the DependencyInjector class below that I was tightly coupling it with ServiceResolver from the previous post. Since this is very much an anti-pattern, I decided to make ServiceResolver implement an interface, so that you can use your own IServiceResolver implementation with this DependencyInjector class. Here’s the interface:

using System;

namespace Core
{
   public interface IServiceResolver
   {
       void Register<TFrom, TTo>();
       T Resolve<T>();
       object Resolve(Type fromType);
   }
}

Notice that I’ve added a non-generic version of this class. This was done for compatibility, and now the ServiceResolver class looks like the following. The major changes are it now implements the IServiceResolver interface, and there is the new non-generic method which is called by the generic method. Also, it does not throw an exception if there has not been a registration for the given type. Instead, it creates a new object and looks for any injections. This is to remove the need to bind items to themselves. Note that there is still a tight coupling in the default constructor to DependencyInjector. You may wish to remove this.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Core
{
   /// <summary>
   /// Resolves abstract types or interfaces to concrete implementations. Use <see cref="ServiceLocator" /> for static/shared access.
   /// </summary>
   public class ServiceResolver : IServiceResolver
   {
       private Dictionary<Type, object> _store;
       private Dictionary<Type, Type> _bindings;
      
       /// <summary>
       /// Default constructor; instantiates a new ServiceResolver object.
       /// </summary>
       public ServiceResolver()
       {
           this.DependencyInjector = new DependencyInjector(this);
           _store = new Dictionary<Type, object>();
           _bindings = new Dictionary<Type, Type>();
       }

       /// <summary>
       /// Creates a new ServiceResolver with a given IDependencyInjector.
       /// </summary>
       /// <param name="injector">The IDependencyInjector to use for dependency injection.</param>
       public ServiceResolver(IDependencyInjector injector)
       {
           this.DependencyInjector = injector;
           _store = new Dictionary<Type, object>();
           _bindings = new Dictionary<Type, Type>();
       }

       /// <summary>
       /// Gets an implementation object of a registered abstract type or interface.
       /// </summary>
       /// <typeparam name="T">The registered abstract type or interface to look up.</typeparam>
       /// <returns>Returns an object of the given type.</returns>
       public T Resolve<T>()
       {
           return (T)Resolve(typeof(T));
       }

       /// <summary>
       /// Gets an implementation object of a registered abstract type or interface.
       /// </summary>
       /// <param name="fromType">The registered abstract type or interface to look up.</param>
       /// <returns>Returns an object of the given type.</returns>
       public object Resolve(Type fromType)
       {
           // check for registration
           if (!_bindings.ContainsKey(fromType))
               return DependencyInjector.GetInjectedInstance(fromType);
              
           // get destination type
           Type dest = _bindings[fromType];

           // check for already requested object
           if (_store.ContainsKey(dest))
               return _store[dest];

           // create a new instance of this type
           object obj = DependencyInjector.GetInjectedInstance(dest);

           // add to store for future use
           _store.Add(dest, obj);

           return obj;
       }

       /// <summary>
       /// Registers a type with its corresponding implementation type.
       /// </summary>
       /// <typeparam name="TFrom">The abstract type or interface to use as a key.</typeparam>
       /// <typeparam name="TTo">The implementation type to use as a value.</typeparam>
       public void Register<TFrom, TTo>()
       {
           _bindings.Add(typeof(TFrom), typeof(TTo));
       }

       /// <summary>
       /// Gets or sets a dependency injector to use for types that need injection.
       /// </summary>
       public IDependencyInjector DependencyInjector { get; set; }

   }
}

The InjectAttribute class

In order to tell our DependencyInjector class that we want to inject something, we need to decorate either a constructor or some properties (or both) with an [Inject] attribute. If you’ve never created your own attributes, all you have to do is create a new class with a name that ends in Attribute (the “Attribute” bit is cut off on use) and make it inherit from Attribute. Here’s our empty InjectAttribute class:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Core
{
   [AttributeUsage(AttributeTargets.Property | AttributeTargets.Constructor)]
   public class InjectAttribute : Attribute
   {

   }
}

the IDependencyInjector Interface

Since we want to make our DependencyInjector loosely coupled with any use of it, we want to make it implement an interface.

using System;

namespace Core
{
   public interface IDependencyInjector
   {
       T GetInjectedInstance<T>() where T : class;
       object GetInjectedInstance(Type fromType);
       IServiceResolver ServiceResolver { get; set; }
   }
}

The DependencyInjector Class

Now that we have all of the plumbing out of the way, we can show off our new DependencyInjector class.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;

namespace Core
{
   /// <summary>
   /// A class for getting instances of objects that need dependencies injected to function.
   /// </summary>
   public class DependencyInjector : IDependencyInjector
   {
       /// <summary>
       /// Creates a new DependencyInjector with a default IServiceResolver for resolving types.
       /// </summary>
       public DependencyInjector() : this(new ServiceResolver())
       { }

       /// <summary>
       /// Creates a new DependencyInjector with a given IServiceResolver for resolving types.
       /// </summary>
       /// <param name="resolver">The IServiceResolver to use for resolving types to implementations.</param>
       public DependencyInjector(IServiceResolver resolver)
       {
           this.ServiceResolver = resolver;
       }

       /// <summary>
       /// Gets or sets an IServiceResolver to use for resolving types to implementations.
       /// </summary>
       public IServiceResolver ServiceResolver { get; set; }

       /// <summary>
       /// Gets an injected instance of a given type.
       /// </summary>
       /// <typeparam name="T">The type to instantiate and inject.</typeparam>
       /// <returns>Returns a new instance of the given type.</returns>
       public virtual T GetInjectedInstance<T>() where T : class
       {
           return (T)GetInjectedInstance(typeof(T));
       }

       /// <summary>
       /// Gets an injected instance of a given type.
       /// </summary>
       /// <param name="fromType">The type to instantiate and inject.</param>
       /// <returns>Returns a new instance of the given type.</returns>
       public virtual object GetInjectedInstance(Type fromType)
       {
           object obj = null;

           foreach (var constructor in fromType.GetConstructors())
           {
               // look for inject attribute
               var attr = GetConstructorInjectAttribute(constructor);

               if (attr != null)
               {
                   // get parameters to inject
                   var parmValues = GetResolvedParameterValues(constructor);

                   if (parmValues.Count > 0)
                       obj = Activator.CreateInstance(fromType, parmValues.ToArray());

                   break;
               }
           }

           // handle case where no constructor injections
           if (obj == null)
               obj = Activator.CreateInstance(fromType);

           foreach (var prop in fromType.GetProperties())
           {
               // look for inject attribute
               var attr = GetPropertyInjectAttribute(prop);

               if (attr != null)
                   prop.SetValue(obj, ServiceResolver.Resolve(prop.PropertyType), new object[] { });
           }

           return obj;
       }

       /// <summary>
       /// Gets an InjectAttribute (if any) for the given constructor.
       /// </summary>
       /// <param name="constructor">The constructor to inspect for an InjectAttribute.</param>
       /// <returns>Returns an InjectAttribute if exists, or null if not.</returns>
       protected virtual InjectAttribute GetConstructorInjectAttribute(ConstructorInfo constructor)
       {
           var attrs = constructor.GetCustomAttributes(typeof(InjectAttribute), true);
           return attrs.OfType<InjectAttribute>().FirstOrDefault();
       }

       /// <summary>
       /// Gets an InjectAttribute (if any) for the given property.
       /// </summary>
       /// <param name="prop">The property to inspect for an InjectAttribute.</param>
       /// <returns>Returns an InjectAttribute if exists, or null if not.</returns>
       protected virtual InjectAttribute GetPropertyInjectAttribute(PropertyInfo prop)
       {
           var attrs = prop.GetCustomAttributes(typeof(InjectAttribute), true);
           return attrs.OfType<InjectAttribute>().FirstOrDefault();
       }

       /// <summary>
       /// Gets a list of parameter values for the given constructor, resolved by the ServiceResolver.
       /// </summary>
       /// <param name="constructor">The constructor to resolve parameters for.</param>
       /// <returns>Returns a new list of parameter values.</returns>
       protected virtual List<object> GetResolvedParameterValues(ConstructorInfo constructor)
       {
           var parms = constructor.GetParameters();
           List<object> parmValues = new List<object>();

           foreach (var parm in parms)
           {
               if (parm.ParameterType.IsInterface || parm.ParameterType.IsAbstract)
               {
                   Type parmType = parm.ParameterType;
                   object parmValue = ServiceResolver.Resolve(parmType);
                   parmValues.Add(parmValue);
               }
               else
                   throw new InvalidOperationException("Unable to inject a parameter that is not an interface or abstract type.");
           }

           return parmValues;
       }

   }
}

I’m not going to cover line-by-line what this class does, but basically it looks for any InjectAttributes decorating a constructor or properties, and if it finds them, it resolves instances automatically using the ServiceLocator (another tight coupling) and fills them in.

Usage

Back in our ASP.NET MVC test app, we have created a new interface to use for testing, ILogger. It has one implementation (but could have many), and this one is WebLogger which writes out the log message to the current HttpResponse.

using System;

namespace CustomIoCMvc.Models
{
   public interface ILogger
   {
       void Log(string message);
   }
}

And here’s our WebLogger:

using System;
using System.Web;

namespace CustomIoCMvc.Models
{
   public class WebLogger : ILogger
   {
       public void Log(string message)
       {
           HttpContext.Current.Response.Write(message);
       }
   }
}

We, of course, need to wire up this implementation in our Global.asax.cs:

protected void Application_Start()
{
   RegisterRoutes(RouteTable.Routes);
  
   // register types
   ServiceLocator.Register<ICustomerRepository, CustomerRepository>();
   ServiceLocator.Register<ILogger, WebLogger>();

}

Our CustomerRepository is going to now use an ILogger for all of its calls. Here it is with a Constructor injection:

using System;
using System.Data;
using System.Configuration;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Collections.Generic;
using Core;

namespace CustomIoCMvc.Models
{
   public class CustomerRepository : ICustomerRepository
   {
       [Inject]
       public CustomerRepository(ILogger logger)
       {
           this.Logger = logger;
       }

       public Customer Find(int id)
       {
           Logger.Log("Find called with param value " + id.ToString());
           return FindAll().Where(c => c.Id == id).FirstOrDefault();
       }

       public List<Customer> FindAll()
       {
           Logger.Log("FindAll called.");
           var data = new List<Customer>();
           data.Add(new Customer() { Id = 1, Name = "Joe" });
           data.Add(new Customer() { Id = 2, Name = "Steve" });
           data.Add(new Customer() { Id = 3, Name = "Karen" });
           return data;
       }

       public ILogger Logger { get; set; }
   }
}

And here’s our CustomerRepository with Property injection:

using System;
using System.Data;
using System.Configuration;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Xml.Linq;
using System.Collections.Generic;
using Core;

namespace CustomIoCMvc.Models
{
   public class CustomerRepository : ICustomerRepository
   {

       public Customer Find(int id)
       {
           Logger.Log("Find called with param value " + id.ToString());
           return FindAll().Where(c => c.Id == id).FirstOrDefault();
       }

       public List<Customer> FindAll()
       {
           Logger.Log("FindAll called.");
           var data = new List<Customer>();
           data.Add(new Customer() { Id = 1, Name = "Joe" });
           data.Add(new Customer() { Id = 2, Name = "Steve" });
           data.Add(new Customer() { Id = 3, Name = "Karen" });
           return data;
       }

       [Inject]
       public ILogger Logger { get; set; }
   }
}

Both have been tested with the same result. But first, a little background about what’s going on here.

Our CustomersController is requesting from the service locator an instance of ICustomerRepository. It finds that we’ve bound ICustomerRepository to CustomerRepository, and goes to instantiate that class. What we’ve modified our code to do is to look, before we instantiate, if there’s a constructor with an [Inject] attribute. If there is, we fill in the constructor parameters with the needed types. If not, we go ahead and create the object with the default constructor.

Next, after we’ve instantiated the object, it looks for any properties with an [Inject] attribute, and does the same. Finally, it returns the object.

Therefore, in this case, our DependencyInjector is getting a request for a new CustomerRepository, it looks for a constructor with [Inject], sees one (in the first example) and resolves ILogger to the bound WebLogger type, gets an instance of WebLogger, and fills it in to the constructor. In the second example, it uses a default constructor but finds the [Inject] decorated Logger property, resolves ILogger to WebLogger, and sets it.

So here’s our output. You can’t really see it (because it’s a cheap quick hack), but theres a “FindAll called.” string at the top of the page:

Let me know in the comments if you have any issues or constructive criticism of this code. Hope this helps!

Creating Your Own IoC Container

2009-09-23T21:55:00.002-04:00

A few posts ago I covered how to take your first steps into Dependency Injection with Ninject. Continuing on the DI/IoC theme, let’s now look at how you can create your own Inversion of Control (IoC) container.

Suppose that your organization has very strict limits on what outside software you can use due to licensing, but you still want to do IoC. Or, perhaps you don’t need your IoC container to do very much other than the basics and you don’t want the weight of another full-featured DLL. This is what we will be creating today, with 2 classes: a ServiceResolver and a ServiceLocator.

(Aside: For those that feel I’m using the term “Service Locator” inappropriately, please forgive me. For this example that’s the name I came up with.)

A basic IoC container needs to do the following:

Register abstract types or interfaces to concrete implementation types
Resolve abstract types or interfaces to implementation objects
Keep track of the registered types
Keep already-resolved objects available for re-use
Create instances of the implementation types behind-the-scenes

Our two classes will accomplish that, but only one has most of the logic – the ServiceResolver. The reason for the ServiceLocator class is to provide static methods around the ServiceResolver, and maintain a static instance of the resolver. Since static methods are difficult to test, this allows you to test the functionality of the ServiceResolver class, and trust that the basic wrapper functionality of the ServiceLocator just works.

The Light At The End

Sometimes it’s fun to see what we’re aiming to do, instead of starting from the beginning, right? Basically we’re going to have a simple ASP.NET MVC site that is going to have a Customers controller. The Index action will ask the service locator for an implementation of ICustomerRepository so that it is loosely coupled. In our Global.asax class, we will register the binding of ICustomerRepository to CustomerRepository. The reason for this is we are pretending that CustomerRepository hits the database, so that for our unit tests we could create a mock repository that does not.

Our Global.asax.cs file looks like this:

 protected void Application_Start()
         {
             RegisterRoutes(RouteTable.Routes);
             
             // register types
             ServiceLocator.Register<ICustomerRepository, CustomerRepository>();

         }

Note that in a real-world app, you may wish to register types on each page request, not on application start.

And our Index action looks like this:

 public ActionResult Index()
         {

             var repo = ServiceLocator.Resolve<ICustomerRepository>();

             ViewData["customers"] = repo.FindAll();

             return View();

         }

The ServiceResolver Class

Let’s look at the ServiceResolver class that does all the heavy lifting (although there really isn’t much).

 using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Text;

 namespace Core
 {
     /// <summary>
     /// Resolves abstract types or interfaces to concrete implementations. Use <see cref="ServiceLocator" /> for static/shared access.
     /// </summary>
     public class ServiceResolver
     {
         private Dictionary<Type, object> _store;
         private Dictionary<Type, Type> _bindings;

         /// <summary>
         /// Default constructor; instantiates a new ServiceResolver object.
         /// </summary>
         public ServiceResolver()
         {
             _store = new Dictionary<Type, object>();
             _bindings = new Dictionary<Type, Type>();
         }

         /// <summary>
         /// Gets an implementation object of a registered abstract type or interface.
         /// </summary>
         /// <typeparam name="T">The registered abstract type or interface to look up.</typeparam>
         /// <returns>Returns an object of the given type.</returns>
         public T Resolve<T>()
         {
             // check for registration
             if (!_bindings.ContainsKey(typeof(T)))
                 throw new InvalidOperationException(string.Format("Requested type {0} has not been registered.", typeof(T).ToString()));

             // get destination type
             Type dest = _bindings[typeof(T)];

             // check for already requested object
             if (_store.ContainsKey(dest))
                 return (T)_store[dest];

             // create a new instance of this type
             T obj = (T)Activator.CreateInstance(dest);

             // add to store for future use
             _store.Add(dest, obj);

             return obj;
         }

         /// <summary>
         /// Registers a type with its corresponding implementation type.
         /// </summary>
         /// <typeparam name="TFrom">The abstract type or interface to use as a key.</typeparam>
         /// <typeparam name="TTo">The implementation type to use as a value.</typeparam>
         public void Register<TFrom, TTo>()
         {
             _bindings.Add(typeof(TFrom), typeof(TTo));
         }

     }
 }

First, notice the _store and _bindings members. Those are our ways of keeping track of registered types (_bindings) and reusable already-resolved objects (_store).

The Register<TFrom, TTo>() method adds to the _bindings dictionary the “from” and “to” types to use later, whenever Resolve<T>() is called. Since we’re just storing types in the dictionary, there is little overhead and it’s okay to register all our types in advance.

Finally, the Resolve<T>() method looks for a pre-registered type binding, and throws an error if it doesn’t find one. Then, it looks to see if an object has already been created for this type. If so, it returns it. If not, it creates an instance of the type and adds it to the _store dictionary before returning it.

You can certainly use the ServiceResolver class by itself for IoC, but I prefer using static methods for conciseness. That’s why we need a static wrapper class, called ServiceLocator.

The ServiceLocator Class

Here’s our ServiceLocator static wrapper class.

 using System;
 using System.Collections.Generic;
 using System.Linq;
 using System.Text;

 namespace Core
 {
     /// <summary>
     /// A service locator to resolve abstract types or interfaces to concrete implementations.
     /// </summary>
     public class ServiceLocator
     {

         private static ServiceResolver _instance = null;
         private static object _lock = new object();

         /// <summary>
         /// Gets a shared instance of the ServiceResolver.
         /// </summary>
         /// <returns>Returns the shared instance of a ServiceResolver, or a new one if it has not yet been accessed.</returns>
         private static ServiceResolver GetInstance()
         {
             lock (_lock)
             {
                 if (_instance == null)
                     _instance = new ServiceResolver();

                 return _instance;
             }
         }

         /// <summary>
         /// Binds an abstract type to a concrete implementation.
         /// </summary>
         /// <typeparam name="TFrom">The abstract type or interface to use as a key.</typeparam>
         /// <typeparam name="TTo">The implementation type to use as a value.</typeparam>
         public static void Register<TFrom, TTo>()
         {
             GetInstance().Register<TFrom, TTo>();
         }

         /// <summary>
         /// Gets an implementation of the given type.
         /// </summary>
         /// <typeparam name="T">The abstract type or interface to look up.</typeparam>
         /// <returns>Returns an implementation of the given type.</returns>
         public static T Resolve<T>()
         {
             return GetInstance().Resolve<T>();
         }

     }
 }

Notice that we’ve got one static instance of the service resolver, and a GetInstance() method that instantiates it if it doesn’t exist. Also notice our Resolve and Register methods that have the same signature (albeit static) as our ServiceResolver class.

This enables us to simply call ServiceLocator.Resolve<T>() without needing to find an instantiated resolver or create one.

Just to show you that this was tested, here’s our view:

 <asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

     <h2>Customers</h2>
     
     <ul>
     <% foreach (Customer c in (List<Customer>)ViewData["customers"])
        { %>
         <li><%= c.Name %></li>     
     <% } %>
     </ul>
     
 </asp:Content>

Here’s our CustomerRepository:

 namespace CustomIoCMvc.Models
 {
     public class CustomerRepository : ICustomerRepository
     {

         public Customer Find(int id)
         {
             return FindAll().Where(c => c.Id == id).FirstOrDefault();
         }

         public List<Customer> FindAll()
         {
             var data = new List<Customer>();
             data.Add(new Customer() { Id = 1, Name = "Joe" });
             data.Add(new Customer() { Id = 2, Name = "Steve" });
             data.Add(new Customer() { Id = 3, Name = "Karen" });
             return data;
         }

     }
 }

And here’s the output:

Hope this helps! Please leave constructive comments below. Also note that I'm still playing around with formatting code, please forgive me if it doesn't render correctly!

Pair Programming in the News

2009-09-22T08:45:00.003-04:00

I’ve been a huge fan of pair programming for a while now. It really is more productive, and it effectively is a real-time code review as you write it. I’ve had the chance to do some pair programming here at the new gig, and it’s worked out really well. A new favorite quote of mine when paraphrased goes something like “You don’t learn from people that agree with you” and with pair programming that is definitely the case. You learn from the mistakes you make when your partner disagrees with what you just wrote.

So I was very excited to find an article about pair programming in the New York Times. Check it out and let me know in the comments what your thoughts are.

I’ve got a few new discoveries with ASP.NET MVC and Dependency Injection that I’m gearing up some posts about, and as you may have noticed, I’m still trying to figure out the best way to get code into this blog as a formatted, copy-and-paste-able format.

I’m looking forward to the next meetings (and my first) of JaxDUG (Jacksonville .NET User Group), ArcSIG (for Architects), and the Jacksonvile SQL Server Users Group. I’m a big fan of community, and if you’ve never been to a local .NET user group, I strongly encourage you to give it a try.

Update: It appears that at least one person is asserting a more pessimistic view of this article. I really am not a proponent of that kind of negative, borderline arrogant language, as I try to make this blog positive and forward-thinking for beginners as well as experts -- but it's an interesting read nonetheless.

ASP.NET: WebForms Validation with Data Annotations

2009-08-19T10:23:00.001-04:00

Last night at my last regular trip to the Lakeland .NET User Group I had a discussion with someone about how it’s great that Data Annotations is being used by Dynamic Data, RIA services, and now ASP.NET MVC 2, but that there isn’t a WebForms validation control (like the PropertyProxyValidator in the Validation block of Enterprise Library) to auto-validate against Data Annotations. I suggested we write one. I did so this morning.

If you aren’t familiar with Data Annotations, it’s a really cool feature of .NET 3.5 SP1. Check out those 3 links above (Dynamic Data, RIA, and MVC) for more info of how they’re used elsewhere.

The DataAnnotationValidator Class

Here’s the code for the Data Annotations Validator that I built for WebForms. I just created this as a class file in the App_Code folder of my web project for testing, but you’d probably want to move it into your shared library (if you have one). You’ll need to add a reference to System.ComponentModel.DataAnnotations first.

And there’s just 2 properties in this class:

Data Annotating Your Class

Here’s a test class I wrote using some common annotations:

Here you see you can add multiple validators together (such as Required and StringLength in this example). And there’s also a RegularExpression validator:

Usage

To use this DataAnnotationValidator on your page, you must first register the namespace. (Note: you can also do this in the web.config to force it on all pages in your site.)

The namespace value must match the namespace of DataAnnotationValidator.

To add a validator to a form field, just create a new <val:DataAnnotationValidator> tag for each field:

Notice the SourceType property? That value must match the full type name of the object you’re validating.

Now when you try and submit your form you get this:

(In this example, the Address 2 field is not marked as required.)

You can also simply add a ValidationSummary to the page to show what is wrong:

And now we get a helpful list of errors:

You’re probably thinking, though, “what’s so special about this? I could just use a RequiredFieldValidator.” True, but we now have multiple validators per property with just one validator tag, and we don’t have to make the front end logic match the back end annotations. Separation of concerns!

Here’s the RegularExpression data annotations validator at work:

You can see where this becomes handy – you annotate your class once, and you can then use it in RIA services, ASP.NET MVC 2, and now WebForms, and you don’t have to have any validation logic in your front end code. This idea could easily be modified for Windows Forms or WPF as well. You could also easily modify the code to set a CSS style for the textbox that would change the background color on error.

Hope this helps! Let me know any questions or concerns in the comments.

Also, I couldn’t have done this without some guidance from the Enterprise Library PropertyProxyValidator source code, and this Stack Overflow question/answer.

Update: Using DisplayName

I realized that I was forgetting a key part of data annotations – that it supports the DisplayNameAttribute! This removes all of the string error messages from the class definition and generates them for you. Below are the modifications to support DisplayName. If a display name is not given, it will use the property name instead, which is great for single word property names like “City”.

In your class file that you’re annotating, import System.ComponentModel.

In the DataAnnotationValidator class, modify the routine to look up the DisplayName or property name like this:

Also make sure you modify the Me.ErrorMessage line to use attr.FormatErrorMessage(displayName) like above.

Now, you can yank out all of those error message strings! If you’ve got a single word property name, like Id, you can just do this:

And if you need to add a display name, you can add the DisplayName() attribute:

Once we’ve made these modifications (which make the class definition much more concise), we get the following output on our form, without having to write our own error messages:

You’ll still want to keep the error message specified for the RegularExpression annotation validator, because it actually shows the RegEx expression in the error message, which will confuse your users.

First Steps into Dependency Injection with Ninject

2009-08-17T18:49:00.001-04:00

I recently started playing around with dependency injection, but it was very much a by-hand process using constructor injection without any kind of framework. It worked well for my proof of concepts, but I had a breakthrough today when I tried Ninject. If you’re looking to get into DI/IoC, this hopefully will be a good place to start. I’m right there with you, I’m a newbie to DI as well.

If you’re already confused by the first paragraph, Dependency Injection (hereafter called DI) and Inversion of Control (hereafter called IoC) are almost synonyms for a development methodology where you aim to reduce coupling between classes as much as possible. Coupling means that one class depends on another, which increases complexity for large projects and almost ruins testability. For example, if your class needs to use a database connection, you might not want to couple it with SqlClient.SqlConnection, you might just want to couple it to the interface IDbConnection instead, so that it can accept any type of connection. (SqlConnection implements IDbConnection.) This makes your code more flexible for testing, because you can create a mock connection that implements IDbConnection and perform unit tests without hitting your database. This is just one example, although there are many reasons to use DI.

While there are other methods of injection, I’m only going to talk about 2 in this post – constructor injection and property injection.

In this example, let’s say you have a Customer class that needs to use a database connection. Since you want to roll your own database connection wrapper classes, you also want to implement logging so you can keep track of your database requests.

Let’s start out with a console application.

Disclaimer: This is demo code only. It doesn’t actually connect to a database, and does not implement best practices for security or anything else. Please keep that in mind!

Downloading Ninject

You can download Ninject and take a short tutorial at www.ninject.org. The download is a .zip file with all of the Ninject DLLs that you’ll ever need, but really we’re just concerned with the Ninject.Core assembly.

Add Ninject as a Reference

Create a new console application, and from the My Project pages, add the extracted Ninject.Core.dll file as a reference.

It’ll also make it easier later on to go ahead and import the Ninject.Core namespace from the References property page:

The Old Way

First, let’s look at how we might previously have implemented the Customer class without DI.

Here you can see that we’ve got a private SqlConnection object that is created in the constructor. There’s no way here to swap that out for a mock connection for testing, and we’ve got a coupling between Customer and SqlConnection.

Now let’s look at how SqlConnection does its logging (note that this class is obviously just for demo purposes):

As you might have guessed, our SqlConnection object now has a tight coupling with ConsoleLogger. What if we wanted to log to a database or email instead? With this method, we can’t.

Dependency Injection By Hand

As I mentioned earlier, I started out by doing DI by hand, so let’s see what that might look like.

First let’s make an interface for our database connection:

Now, here’s what our SqlConnection class looks like:

We still have a dependency on ConsoleLogger, but we’ll remove that later.

Now our customer class no longer has a dependency on SqlConnection:

And here’s how we use it in our console app:

And the result is (with our ConsoleLogger output):

We still have to inject the SqlConnection by hand, which would work in front end code, but is not ideal.

So, proceeding onto removing the dependency on ConsoleLogger, how would we accomplish this with the method above? Well, we’d probably have to pass in a new ConsoleLogger (implementing ILogger) into our customer object as well. However, then we’d have to pass that logger from the customer into the SqlConnection by a constructor or property. And what if we have to create multiple objects that use the same connection or logger? It becomes a mess very quickly. This is where Ninject steps in to help.

Let’s wrap up a few more things, such as creating an interface for our loggers:

Then we’d make ConsoleLogger implement ILogger.

Setting Up our Injections

How Ninject and other DI solutions work is by automatically wiring up our dependencies for us. For example, we need to wire up 2 dependencies: anytime we want an IDataConnection in this app we want to use a SqlConnection, and anytime we want an ILogger we want a ConsoleLogger. This makes the code testable because you can wire up in your tests to use a mock IDataConnection instead, with another type of logger if you wish.

We’re going to use those two methods of injection as mentioned here before. First, constructor injection. We want to use the constructor of the Customer object to inject a dependency on SqlConnection. Here’s how we mark that constructor for injection:

Next, we want to use property injection to inject a dependency of ConsoleLogger into the SqlConnection.

Note that we’re accomplishing the same goal, but using a Property instead of a Constructor.

Tying It All Together

Ninject uses the idea of a “kernel” to generate all the dependencies. And the kernel can have passed into it multiple “modules” to wire them all together. First we’ll create the DataModule, although you can call it whatever you like:

Note that it must inherit from StandardModule for this to work.

Those 2 lines of code inside the Load method are pretty powerful. They’re saying, using generics, that anytime a class requests an IDataConnection, we want a SqlConnection, and anytime a class requests an ILogger, we get a ConsoleLogger. This is dependency injection at work!

So now that we have our loosely coupled classes (because no class depends on another) and our module for wiring up our connection and logger, we need to actually use the kernel.

Hooray for DI! Now, our front end code doesn’t need to know that it’s using a SqlConnection or ConsoleLogger, it’s happening for us behind the scenes. We could even make the SqlConnection or ConsoleLogger a singleton so that there’s only one instance of it in our application, just by adding the <Singleton()> attribute to the class.

I hope this shows off the basics of using Ninject in an application. Beyond this, I’m not an expert. I only recently got involved in DI, and only today with Ninject. But I’m really impressed so far, and I think once you play around with it you will be too.

Please do not hesitate to (kindly) let me know your questions or concerns in the comments.

Jacksonville, here I come!

2009-08-13T15:59:00.001-04:00

I am happy to say that I have taken a position as a .NET developer at Football Fanatics in Jacksonville! It’s a booming business with a lot of smart developers and they’re really doing some cool things. I’m excited to take on the challenge!

And, to show that it will be a learning experience, they pointed out in my interview that my last post, Conditionally Removing Items from a Generic List, is probably not the best way to do things. After the interview, a large forehead-slap was in order.

So yes, you can remove items conditionally from the list by just using the RemoveAll function with a lambda passed in.

D’oh.

A New Adventure

2009-08-10T12:18:00.001-04:00

After 2 years of living in Lakeland, my wife and I decided that now was a good point in our lives to make a very risky jump – to move to Jacksonville without any jobs lined up to speak of. With a bad job market, this may end up being a bad decision, but we’re confident that things will work out in one way or another. Jacksonville is more our speed, and we just aren’t really happy here. I let my work know today, and it’s going to be a nice, clean, professional break. The job opportunities I’ve been connected with seem like great ways to advance my career and work with some smart people, so I’m excited!

In a month or so we’ll be relocating to Jax and starting the next chapter of our lives. In the mean time, I’ll make my last visit to the Lakeland .NET User Group as a resident of Lakeland, try to write at least another blog post (I still need to finish up one draft), and pack everything up.

I look forward to joining the Jacksonville user groups and I’ll be attending the Jacksonville Code Camp (and helping Russ Fustino with his “It’s All About The Tools” channel9 episode filming) on August 29th. Hope to see you there!

Generics: Conditionally Removing Items from a List

2009-08-06T16:22:00.003-04:00

Consider this scenario: you have a generic list of items, and you want to loop over each item in the list and if it matches some condition, you want to remove it.

You might try the following code at first, to remove all even items from a list of integers, 0-9:

The problem is, since you’re enumerating over the list in the first foreach loop, you actually are modifying the list as you’re enumerating over it, so it throws the following error:

Even though it’s clearly a beginner’s mistake, I still find myself wanting to be able to do this easily.

So what are your other options? You can keep a separate list going of items to remove, and then enumerate over the list to remove and handle it that way, or you can skip the foreach entirely and operate based on indexes, but either way, you’re adding a lot of code to keep track of which objects to remove and to make sure you don’t encounter errors.

What if you just wanted to have the items removed from the list as soon as you’re done enumerating over it? Unfortunately, to my knowledge, that’s not supported in .NET. Please correct me if I’m wrong!

So, I created a quick helper class to handle this situation. It implements IEnumerable<T> so you can do a foreach over it, as well as IDisposable so that you can use it in a Using block and as soon as it goes out of scope, it removes the items from the list.

Here’s the usage:

Notice that all you have to do is add one line of true code, a using block around your existing removal code, and just call “dc.Remove” (or “dc.RemoveAt”) instead of “data.Remove”! And in this example, I’m enumerating over “dc” just to show you that you can, but since nothing is actually removed until that ending curly brace of the using block, you could just as easily say “foreach (int i in data)” like before.

Here’s the DelayedCleanup<T> class:

This implementation actually has a second list that stores the references (or values for value types) of the items to remove, but you could easily modify this to use indices and then sort them descending to remove the items.

Hope this helps! Please leave constructive feedback in the comments, I’d love to hear any thoughts or concerns you have.

Lakeland .NET User Group - Speaker Idol

2009-07-22T09:41:00.002-04:00

I had a great time last night at the Lakeland .NET User Group at PSC. (Polk State College, formerly Polk Community College. The new name still trips me up, especially since I used to work for the PSC, the Florida Public Service Commission.) Great speakers, lots of fun.

The trifecta team of the school board each spoke, with great presentations on the Array class, RIA services and concurrency, and Ben Geiger on the Balsamiq mockup software. Also, Nikita Polyakov gave an introduction to Windows Mobile development with WM 6.5 and the new Marketplace opening next week, and Megan Hopkins on what to do (and not to do) when trying to land a tech job.

My talk was on VB's XML Literals with a code-only presentation from scratch. The swag I took home was a free license of Balsamiq, which after Ben's talk, I'm very excited about! It's an Adobe AIR-based application that allows you to do SketchFlow-like things in a different way for creating UI mockups.

(I ended up winning Speaker Idol, but I don't want that to take away from how great the other presentations were! Check out their blogs, follow them on Twitter.)

I mentioned a video on Channel9 where a guy created an entire ASP.NET MVC view engine using only XML Literals in VB, with no .aspx files, so the entire website can be compiled into a single DLL. Amazing stuff. Make sure you check out the video. Even if you don't use VB, it's very fun to watch and think about.

Tonight I'll be heading over to the Tampa UG (my first visit!) to check out the filming of Russ' Tool Shed. Looking forward to meeting Tampa folks, and hope to see you there!

ASP.NET: Serving ASPX files as .XML (or .HTML, etc.)

2009-07-15T14:15:00.001-04:00

Say you want to serve/rename/rewrite a .aspx file as a .xml file so that your URL looks like http://mysite.com/mypage.xml instead of http://mysite.com/mypage.aspx. This is useful for scenarios such as RSS feeds. (Or, perhaps, you want to serve it as a .html file, or something else. For the rest of this example, replace .xml with the file extension you want.)

Step 1: Rename Your File

First, create your .aspx file with a codebehind and verify that it works. Then, rename the .aspx file (and NOT the .aspx.vb or .aspx.cs file!) to .xml. You should then have 2 files that look like MyPage.xml and MyPage.aspx.vb (or MyPage.aspx.cs).

Step 2: Register the Build Provider

Open up your Web.config file, and locate the compilation/buildProviders section. Add a tag for the new extension to tie it to the System.Web.Compilation.PageBuildProvider build provider like so:

Step 3: Register the HttpHandlers for IIS6 and IIs7

In our current environment, our development systems are running IIS7 while our production server is running IIS6, so I need to handle both cases. You may only need to handle the IIS6 or IIS7 specific tags, but it’s not a bad idea to handle both.

For IIS6, locate the httpHandlers section of your Web.Config and add the .xml handler:

For IIS7, locate the system.webServer/handlers section of your web.config and add the .xml handler as well:

Step 4a: Register the .XML Handler in IIS7

If you’re running IIS7, you may need to add a managed handler in the IIS Manager control panel by doing the following:

1) Select the site you wish to enable this on.

2) Open the Handler Mappings section:

3) In the top-right pane, choose Add Managed Handler:

4) Enter the following details:

Step 4b: Register the .XML Handler in IIS6

If you’re running II6, you may need to direct all .xml files (or all files) to the ASP.NET engine for handling.

1) From the IIS6 manager, right click the site and choose Properties.

2) Choose the Home Directory tab, and click Configuration:

3a) (For just .XML files) Add a .xml handler to point to ASP.NET by clicking the Add button:

Then add a .xml extension pointing to the aspnet_isapi.dll file (you can copy and paste the path from the .aspx entry in the list):

3b) (For all files) Add a wildcard handler by clicking Insert:

And paste in the same aspnet_isapi.dll path:

If you’re using ASP.NET Routing, you may wish to uncheck Verify that File Exists. It’ll help you out later!

Conclusion

That’s it! Now you should be able to navigate to the same ASPX file but with the .xml file extension and it should work. If not, contact me or let me know in the comments.

Hope this helps!

ASP.NET: Moving Session Out-of-Process with StateServer

2009-06-29T13:39:00.001-04:00

I recently ran into an issue with the ASP.NET SessionState. It isn’t a fault of the SessionState itself, but likely an issue with my configuration or uses. Essentially the state was being reset too often. Although I had a timeout value of 1440 minutes, users were getting kicked out after 10-15 minutes. I eventually found out that (for some reason) the IIS worker process was being reset (although it wasn’t configured to self-reset), probably due to an unrecoverable error in some of our legacy-based code. And since our SessionState was set to InProc, all of the session data was stored in-the-process and was thus lost whenever it died.

I started researching the alternatives and discovered the proper way to configure the StateServer that comes with ASP.NET to move your sessions out-of-process. This way, you can literally reset IIS (or if the StateServer is on another machine, reboot your IIS server machine) without losing session. This seemed like a very appealing situation, and one that many people online endorse as best practice.

Another benefit of moving the SessionState out-of-process is that you set yourself up nicely for eventually moving to multiple web servers, or even running simultaneous multiple instances of your application pools on the same machine to boost performance.

The only downside (and yes, there’s always a catch) is that out-of-process state does not give as good performance as InProc does. However, from my initial testing, I haven’t found any significant, noticeable difference after the session is initialized. Another catch, which I’ll discuss later, is that all data that goes into an out-of-process session must be serializable and flagged as such with the SerializableAttribute.

Introduction

Let’s start from the top. The SessionState is a collection of data that is persisted across multiple web requests to ASP.NET. This can be authentication information, a shopping cart, a theme, or whatnot – essentially any information that you want the server to remember for the next time the user “does something” on your site. This can also be accomplished on the page level with ViewState, but that sends more data back and forth between the client and your server.

If you’re using the cookie method of “tagging” your SessionState (which you should, because cookieless is vulnerable to session hijacking), you’ll have a tiny little harmless cookie called ASP.NET_SessionId which contains a unique session ID that looks something like “okeiohntcofecw55svocxwiz”. This ID is sent to the web server to let the server know which session to retrieve.

If the SessionState is running InProc, all ASP.NET has to do is look at the memory it has of that session information and retrieve or set the values required. However, if that process gets reset (due to an IIS reset, power outage, reboot, failed process, etc) then it no longer has a record of that session information, so that SessionId is no longer valid and the user is “kicked off”.

Additionally, if you increase the number of worker processes per application pool, thinking you’ll be getting better performance on a multiprocessor server, you’ll find that the users continually get kicked off, because each process doesn’t know about the session state of the other so they continually reset the session on each other. This is the same problem you’ll encounter if you try to move to two load-balanced web servers.

The StateServer Solution

Included with .NET is a Windows service called the ASP.NET State Service. This is disabled by default, so if you’re reading this far you may not know about it. This service runs as an additional process so that if the IIS worker process gets reset, the state service is still running with all the session information.

You can even run this State Service on another Windows Server machine. This way, you can have one machine managing your session state, while you can have one or more web servers handling requests. An example situation might look something like this:

(I was trying to find a shape to use for the StateServer to differentiate it from the others… and I chose the “eCommerce Server” shape. As in cash = cache… get it?)

Even though that might be what a more advanced operation might look like, you will likely (such as in development or for a small-load web server) run the StateServer on the same machine as IIS.

Keep in mind that the SessionState is still being stored in memory with the StateServer solution… there’s no persisting of the state to disk. So if the StateServer process gets restarted or rebooted, so does your session information.

The SQL Server Solution

Another solution supported natively by ASP.NET is to use SQL Server to persist state information to disk. This way, even the server handling your state can be rebooted without losing session. This may be the preferred way of doing things for very high-end operations or situations where you need to maintain that information for security or contractual purposes. However, I will not be discussing that here, because I haven’t tried it myself. There’s many resources to learn about this on the web, such as this article from Microsoft.

Enabling StateServer

To enable the ASP.NET State Service, all you have to do is configure the service on both your development and production machines.

Click Start / Run or type Win + R.
Type in services.msc and press Enter or click OK.
Locate the ASP.NET State Service in the Services (local) list.
Right click on it and choose Properties.
Change the Startup Type to Automatic so that it starts on boot.
Click the Start button to get it started now.
Click OK to close the dialog.

Now, if you pull up Task Manager, you’ll notice a nice little aspnet_state.exe process running in addition to the IIS worker process (w3wp.exe). This process is the new StateServer that will maintain all your state data. But in order to use it, we must enable your ASP.NET web site to use the out-of-process StateServer.

Modifying your Web.Config

For the site that you’d like to have use the out-of-process StateServer, first open your web.config file for that site.

Locate (or add) a sessionState element in the system.web section of the config file, like this:

Note the cookieless=”UseCookies” and mode=”StateServer” attributes. These are required to use the StateServer in a cookie’d fashion.

The timeout attribute is the time, in minutes, that you want the session to remain valid.

Also note that this example above is for the StateServer running on the same machine as IIS. With no connection string specified, it looks for a StateServer running on the local machine. If you need to move the StateServer onto another machine, you must match up your MachineKeys and set a StateServer connection string for IIS to connect to. Google is your friend.

Now, your site should be using the StateServer for all of its session data. You may (or may not, but it might be a good idea) need to restart IIS for this to be optimally configured.

Non-Serializable Session Data

The only caveat in this post, and it’s a big one, is that you will receive an error if you try to store non-Serializable data into the session now that you have an out-of-process state (i.e. a System.Data.DataView). Serializable classes are those that have the Serializable attribute set and are optimized for serialization (i.e. a System.Data.DataTable).

You will need to review and test your code (or write new code accordingly) to make sure that you are not storing non-Serializable data to your session when using out-of-process state. If you are using custom classes to store session data, review them for serializable members and properties, and then mark them as serializable.

Final Thoughts

I’ve seen developers proclaim online that all ASP.NET devs should design their applications around an out-of-process session model, and now that I’ve discovered it, I am inclined to agree. If you design from the beginning to be compatible with a StateServer or SQL database state server, you can easily make the jump from one web server to two.

A few things to think about are the amount of memory available to the state service, latency and the connection between servers if the StateService is running on another machine, and how to minimize state since it’s now being transferred between processes.

What are your experiences with out-of-process state, and do you have any advice for others?

SQL Server 2008: Importing TIGER/Line Spatial GIS Data

2009-06-25T15:07:00.003-04:00

If you’ve been itching to use the spatial data and query features of SQL Server 2008 but haven’t figured out a way to get data to use, you’re in the same boat I was. Until today.

I have a whole slew of address information, but no way to convert that into latitude/longitude values to do any meaningful spatial querying – I was pretty much limited to Zip Code statistics only. Then I remembered that the US Census Bureau puts out a freely available database of everything from roads to highways to railways to geological and political borders with their coordinates called TIGER/Line. Since 2007, the TIGER/Line data has been in the Shapefile format, which makes it easier to use, although it is a binary file.

It would be quite a bit of effort to try and parse the TIGER/Line data yourself, so the use of a utility greatly helps here. Download SQL Server 2008 Spatial Tools to follow along with this blog post, although Microsoft has a sponsored project on Codeplex which I haven’t used called SQL Server Spatial Tools as well.

Step 1: Download the TIGER/Line Data

To start with, you’ll need to visit the TIGER/Line download site. From there, since you’ll likely want to start with just a small dataset of information (which is still relatively large), just download the files for your county. In my case, I chose Florida from the right-hand side, and then Polk County from the next page. On the county page, you’ll want to download the All Lines package.

This is a Zip file with a few files inside. The only one you’re concerned with is the one with the file extension of .shp – this is the Shapefile format file that we can import with the SQL Server 2008 Spatial Tools into SQL Server. Extract this file somewhere on your hard drive. The only other file you may be interested in is the .shp.xml file -- this contains all the descriptions of the columns, which may be a bit cryptic for your tastes.

Do note that this, even though it’s just at the county level, contains a lot of information. Polk County’s file, for example, is 18.8 MB and contains over 100,000 rows of information. One thing you can do after the information is imported is blow away rows you don’t need (such as railways, geographical/political boundaries, etc.), but you may need all of it. Also there’s extra columns you may not need that, using the utility, you can choose not to import. After importing, my dataset took up over 35 MB in the database.

Step 2: Import the Data

Extract the SQL Server 2008 Spatial Tools from the zip file and run the Shape2Sql.exe program. After putting in your SQL Server connection information, it looks like this:

In the top box (by using the ellipsis button to the right), choose the .shp file that was extracted from the TIGER/Line Zip file.

Now you’ll want to change the radio button from Planar Geometry to Geography (Spheric). This will allow you to query using lat/long values. I’m not sure how it would work with geometry in this example, anyways.

Check the box beside Set SRID and leave the value as 4326. Change the Table Name field to give it a friendly name as you would want it in your database – if this table doesn’t exist, the utility will create it for you.

Advanced users: if you’ve done this before, you will probably want to uncheck any columns on the right-side that you know you don’t need. However, if this is your first time, you’ll probably want to see all the data to see if you need to use it in your application.

When done, click Upload to Database and wait. For 102,000 rows, it took about 20 minutes from my machine.

Step 3: Query Data

Now that you’ve got the TIGER/Line data in your database, you can now query the data. The utility above created a column called “geom” on the table which is the SQL Geography data type.

Doing a simple query of SELECT TOP 5000 * FROM TigerLine_Data WHERE FEATCAT=’S’; returns the top 5000 results that are roads (“FEATCAT=’S’”). Here’s how the results look in SQL Server Management Studio 2008:

Notice that since there’s a geography column returned, there’s now a “Spatial Results” tab. Here’s how it looks with these results:

If you’re from Polk County, you notice that that’s more or less the shape of it, but it’s missing a whole lot of roads, because the Spatial Results screen can’t handle more than 5000 records. We’re off to a good start, but that just isn’t really meaningful data just yet. Let’s set the “FULLNAME” column as the label column (do that on the panel on the right side of the Spatial Results tab) and zoom into some roads:

Now that we can see that we’ve got some data there, let’s work with the spatial querying built into SQL Server 2008. Let’s say we wanted to see all roads within 2 KM of a given lat/long. Here’s the query I’ll use:

SELECT * FROM TigerLine_Data
WHERE ROADFLG='Y' AND FEATCAT='S'
AND geom.STDistance(geography::STGeomFromText('POINT(-81.889472 28.009785)', 4326)) / 1000 < 2.0;

Notice the interesting syntax. We’re saying, in the last part of the where clause, that we want the distance between the value in the “geom” column and a given value, calculated from a POINT with a long/lat pair. (Note the order.) The STDistance function returns the distance, in meters, between the two points. So we divide that by 1000 and compare it less than 2.0 km.

Here’s our results:

Finally we can see what we’re working with! It’s not the prettiest thing in the world, but it helps you quickly visualize the spatial results of your query.

Using functions like STDistance, you could do things such as finding all customers within a range of a certain latitude/longitude point, which I hope to explore in a future blog post. But once you overcome getting data into your system, it’s just SQL queries from here on out.

Oh, and did I mention that this is all free? :-)

Lakeland .NET Users Group - I'm Speaking!

2009-05-26T22:43:00.002-04:00

Next month at the Lakeland .NET Users Group I'll be speaking on jQuery with ASP.NET. I'm covering everything from the barebones basics (assuming you know how to "alert" in JavaScript and what a function is) to animations, advanced selectors, working with server-side controls, and extending jQuery... along with a bunch of real-world examples.

I'll have more details soon, but for now check out the Lakeland .NET Users Group site:
www.lakelandug.net

.NET: Getting HTTP Headers

2009-04-29T13:01:00.001-04:00

As part of the Silverlight application I’m working on, I want to reduce our bandwidth requirements as well as give the users the option of having a faster experience by offering to cache the images locally on the user’s Isolated Storage. However, with Silverlight you only get 1 MB of Isolated Storage when online in-the-browser, and with Silverlight 3 you get 25 MB out-of-browser, but I need more than that. The problem is I didn’t want to download each file first to figure out how much space I needed to request from the Isolated Storage mechanism (because you have to specifically ask to increase the quota to a certain size, and then the user must accept it in a dialog).

So HTTP headers come to the rescue. Using the HEAD command, I can get something that looks like the following from each of the images I know I need to cache, without having to download the whole thing:

Notice the Content-Length: 26529. That’s the size, in bytes, of that file. And also notice that there’s no data returned after the headers. That means that this request will go VERY fast, and I can blow through them all very quickly. Note that this is also useful for finding the last modified date, which I will be using to determine if the locally cached file is out of date.

cURL gives a good interface for calling the HTTP HEAD verb, all you have to do is add the “--head” argument. But how do we do this in .NET?

Answer: use System.Net.HttpWebRequest!

Notice line 8: here we’re telling the request object to use the HEAD verb so that no data is returned. Then, we call request.GetResponse to get the response, and the ContentLength is a property on that returned WebResponse object. Pretty easy! The output is:

And we see that the values match, of course. Make sure you put that request.Method = “HEAD” line in there. Other examples on the web left out that line, and so it was actually doing a full request.

If you notice above, I didn’t give a type for the request and response objects. Even though I called HttpWebRequest.Create(), it returns a WebRequest object. Although that works for getting the content length, there’s a bunch more you can do with the HttpWebRequest and HttpWebResponse objects. Let’s try the caching concept I mentioned earlier.

Using the HTTP Header of If-Modified-Since, we can give the web server the date of our cached version, and if it hasn’t changed since then, it returns an HTTP 304 Not Modified status code. If it has changed, it returns HTTP 200 OK. The HttpWebRequest actually throws a WebException if it gets a 304 code back, so we have to catch it.

First, in the above code, we’re setting the HttpWebRequest.IfModifiedSince property to 1/1/2008. (The file was modified in 2006.) Then, if it’s been modified since 1/1/2008, we print out the response status code and description, as well as the content length and last-modified date. If it returns 304, it throws a WebException, but in the ex.Response property we can access the status code and description and other headers. So here’s what this example returns:

So now we know that we do not need to get the data, because it hasn’t been modified since our request date. But let’s move that request.IfModifiedSince date back to 2005 and see what happens.

So you can see that the file was modified in 2006, after our request date of 2005, so we should get the data.

Note that if you’re strictly doing a cache-update scenario and you don’t need to pay attention to the file size, you don’t have to just do a HEAD request. You could do a full GET and have the data returned if it has been modified, and if it hasn’t, it’ll throw a 304 Not Modified without any data.

Now, I’m not sure if the whole HttpWebRequest and HttpWebResponse API is available in Silverlight yet, but this at least gets me started.

Hope this helps!