Seeing unexplicable “System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain.” errors?

You might be a victim of nunit’s bug #423611.

See also here, here and here.

A typical error message looks like this:

Unhandled exceptions:
1) : System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain.

I’ve uploaded a minimal solution exhibiting the problem to the bugreport and I hope that’ll help clearing the issue up.

<ListView ItemsSource="{Binding Instances}" />

For some strange reason all the mouse events seem to be directly routed instead of bubbling like other input events. Only some magic of the framework causes them to be raised for every hit control. This causes the sender to be totally worthless, since it is always the “current” object.

Uncle Google just brought up a useless and wrong answer on the “site with a hyphen.” But after some fiddling I found the answer: just use an EventSetter to set the handler on all items:

<ListView ItemsSource="{Binding Instances}" >
    <ListView.Resources>
        <Style TargetType="ListViewItem">
            <EventSetter Event="MouseDoubleClick"
                Handler="OnDoubleClick" />
        </Style>
    </ListView.Resources>
</ListView>

Then I wanted to post the question and answer to stackoverflow so others can profit from it too. It turns out that this is an already solved problem: WPF ListView: Attaching a double-click (on an item) event. Furthermore, both this page and the linked thread on the MSDN Forum were also available on the google results. Meh.

Reading the linked articles gave me much joy. Here are some highlights:

• In FOREACH Redux, Eric Niebler describes his long path to the BOOST_FOREACH macro, which emulates C#’s foreach statement in C++. At the core, it all revolves around using the conditional operator ?: with templates to work the compilers type inference engine:

  
  struct rvalue_probe
  {
     template< class R > operator R ()
     {
          throw "rvalue";
     }
     template< class L > operator L &amp; () const
     {
          throw "lvalue";
     }
  };
  
  #define RVALUE_TEST(container) \
     try { ( true ? rvalue_probe() : (container) ); } \
     catch( char const * result ) { cout <<result << '\n'; }
  

  This snippet for example uses the overload resolution rules to decide whether container is an rvalue or an lvalue, without evaluating it. For a detailed explanation, read the full article.

• The next link leads to the Spirit parser generator’s quick start. Except that Spirit is no parser generator like yacc. All rules are directly defined in C++. This one-liner calls f every time a real number is recognized. Multiple numbers are separated with comma.
  
real_p[&f] >> *(',' >> real_p[&f])

real_p is a parser for real numbers, >> puts parsers into sequences and * is the Kleene Star. Read the quick start for an explanation how this all fits together.

So whatever you do, don’t say C++ didn’t make any progress.

Have fun and a nice Sunday!

First, my local results of the benchmark. I compiled them as Release under VS 2008 SP1. Running without debugging on a Q6600@2.40GHz, .NET 3.5 SP1. They pretty exactly match Jon’s numbers so I won’t duplicate them here, but you can find them in the page’s source.

============ Doubles ============
============ double[] ============
For 1,00
ForHoistLength 1,00
ForEach 1,00
IEnumerableForEach 8,28
Enumerable.Sum 8,27

============ List ============
For 2,00
ForHoistLength 1,43
ForEach 6,02
IEnumerableForEach 14,03
Enumerable.Sum 14,04

============ Ints ============
============ int[] ============
For 1,00
ForHoistLength 2,06
ForEach 1,38
IEnumerableForEach 15,46
Enumerable.Sum 16,06

============ List ============
For 2,84
ForHoistLength 3,53
ForEach 4,86
IEnumerableForEach 26,33
Enumerable.Sum 26,33

Out of interest how the differences are when there is more to do in the loop’s body, I added a test suite that formatted the sum as string and appended it to a StringBuilder:

var sbArraySuite = TestSuite.Create("build Strings from Array", doubleArray, String.Join("", doubleArray.Select(d => String.Format("{0:0.00}\n", d)).ToArray()))
    .Add(input =>
    {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < input.Length; i++)
            sb.AppendFormat("{0:0.00}\n", input[i]);
        return sb.ToString();
    }, "For")
    .Add(input =>
    {
        StringBuilder sb = new StringBuilder(); int length = input.Length;
        for (int i = 0; i < length; i++)
            sb.AppendFormat("{0:0.00}\n", input[i]);
        return sb.ToString();
    }, "ForHoistLength")
    .Add(input =>
    {
        StringBuilder sb = new StringBuilder();
        foreach (double d in input)
            sb.AppendFormat("{0:0.00}\n", d);
        return sb.ToString();
    }, "ForEach")
    .Add(IEnumerableForEachToString)
    .RunTests();

    ...

    static string IEnumerableForEachToString(IEnumerable<double> input)
    {
        StringBuilder sb = new StringBuilder();
        foreach (double d in input)
        {
            sb.AppendFormat("{0:0.00}\n", d);
        }
        return sb.ToString();
    }

Which gives these results:

============ build Strings from Array ============
For                        1,01
ForHoistLength             1,01
ForEach                    1,01
IEnumerableForEachToString 1,03

============ build Strings from List ============
For                        1,00
ForHoistLength             1,00
ForEach                    1,02
IEnumerableForEachToString 1,05

Suddenly the relative differences between for/foreach and array/list collapse to 1-5%. Which confirms my intuition that algorithms usually matter much more and such optimisations are quite useless. At least we all had good fun on a saturday