So there was used to be a pre-calculated sum stored in the dictionary by a user control.

class SomeClass
{
    public Decimal DailyFunctionalAmount { get; set; }
    public Decimal MonthToDateFunctionalAmount { get; set; }
    ///..... have much more here
}

Decimal GetTotal(String fieldName, IDictionary<String, Decimal> lookups)
{
    // used to be as simple as getting the pre-calculated sum via dictionary (populated somewhere else by control)
    var totalByLookup = lookups[fieldName];
    return totalByLookup;
}

Now, I need to rely on the underlying data rows to calculate the sum.

var lists = new List<SomeClass> {
    new SomeClass { DailyFunctionalAmount = 10, MonthToDateFunctionalAmount = 100},
    new SomeClass { DailyFunctionalAmount = 10, MonthToDateFunctionalAmount = 100},
};

// I could not use the following code as this is compiled/pre-determined code where we actually need the selector in run-time based on the generated property name by convention
var totalByLinq = lists.Sum(r => r.DailyFunctionalAmount); 

Luckily, there is this expression trees which seems to be perfect for the job, rather than a nasty static function returning selector based on possible combinations for the property name by convention.

// returns -> dtoType => dtoType.propertyName
Func<SomeClass, Decimal> GetMyFunc(string propertyName)
{
    var dtoTypeParameter = Expression.Parameter(typeof(SomeClass), "dtoType");
    var dtoPropertySelector = Expression.Property(dtoTypeParameter, propertyName);
    var lamdaExpression = Expression.Lambda<Func<SomeClass, Decimal>>(dtoPropertySelector, new ParameterExpression[] { dtoTypeParameter });

    return lamdaExpression.Compile();
}

Decimal GetTotal(String fieldName, IEnumerable<SomeClass> lists)
{
    // solution - generate the func in run-time
    var runTimeSelector = GetMyFunc(fieldName);
    var totalByLinq = lists.Sum(runTimeSelector);
    return totalByLinq;
}

It’s surely world of possibilities with this expression trees ;)

Full source code below:

[TestClass]
public class UnitTest1
{
    [TestMethod]
    public void TestMethod1()
    {
        var lists = new List<SomeClass> {
            new SomeClass { DailyFunctionalAmount = 10, MonthToDateFunctionalAmount = 100},
            new SomeClass { DailyFunctionalAmount = 10, MonthToDateFunctionalAmount = 100},
        };

        var lookups = new Dictionary<String, Decimal>(); // stored with the property name as key in the dictionary and the sum as value
        lookups.Add("DailyFunctionalAmount", 20);
        lookups.Add("MonthToDateFunctionalAmount", 200);

        var dailyFunctionalFieldName = GetFieldName("Daily", "Functional");
        var monthToDateFunctionalFieldName = GetFieldName("MonthToDate", "Functional");

        // old way
        Assert.AreEqual(20, GetTotal(dailyFunctionalFieldName, lookups));
        Assert.AreEqual(200, GetTotal(monthToDateFunctionalFieldName, lookups));

        // new way 
        Assert.AreEqual(20, GetTotal(dailyFunctionalFieldName, lists));
        Assert.AreEqual(200, GetTotal(monthToDateFunctionalFieldName, lists));
    }

    Decimal GetTotal(String fieldName, IDictionary<String, Decimal> lookups)
    {
        // used to be as simple as getting the pre-calculated sum via dictionary (populated somewhere else by control)
        var totalByLookup = lookups[fieldName];
        return totalByLookup;
    }

    Decimal GetTotal(String fieldName, IEnumerable<SomeClass> lists)
    {
        // now it needs to be manually calculated from the list

        //var totalByLinq = lists.Sum(r => r.DailyFunctionalAmount); // but this is compiled/pre-determined code where we actually need the selector in run-time

        // solution - generate the func in run-time
        var runTimeSelector = GetMyFunc(fieldName);
        var totalByLinq = lists.Sum(runTimeSelector);
        return totalByLinq;
    }

    String GetFieldName(String periodic, String currency)
    {
        // the field name is generated by some convention [Daily/MonthToDate] + [Functional/Transaction] + "Amount"
        return periodic + currency + "Amount";
    }

    // returns -> dtoType => dtoType.propertyName
    Func<SomeClass, Decimal> GetMyFunc(string propertyName)
    {
        var dtoTypeParameter = Expression.Parameter(typeof(SomeClass), "dtoType");
        var dtoPropertySelector = Expression.Property(dtoTypeParameter, propertyName);
        var lamdaExpression = Expression.Lambda<Func<SomeClass, Decimal>>(dtoPropertySelector, new ParameterExpression[] { dtoTypeParameter });

        return lamdaExpression.Compile();
    }
}

class SomeClass
{
    public Decimal DailyFunctionalAmount { get; set; }
    public Decimal MonthToDateFunctionalAmount { get; set; }
    ///..... have much more here
}

So imagine if you have defined the backing view model below

public class MainViewModel
{
	public MainViewModel()
	{
		// Insert code required on object creation below this point.
	}
	public IList<Person> Persons { get; set; }
}

public abstract class Person
{
	public String Name { get; set; }
	public Int32 Age { get; set; }
	public String Initials { get{ return "some initials"; } }
}

public class Male : Person
{
}

public class Female : Person
{
}

You can then open the view, on the top right panel, click on the Create Sample Data from Class option below

Choose the view model to generate the sample data, click Ok

Bam! the sample data file has been generated nicely below, and notice one thing, the read only Initials property can be “set” as well there :)

Before moving on to the next step, be sure to replace Person Type on the rows into either Male or Female.

Now, time to get into the view with the d:DataContext binding and data templates by Data Type for each Male and Female.

hhhmm… a little bit disappointing, isn’t it? all are seem to be in place, but why it’s displaying these weirds _.di12.NameSpace.Class rather than our expected data template result?
Now back to the xaml, add d:IsDesignTimeCreatable=”False” attribute on both data template elements, save, close and reopen the xaml again.

And there’s the shiny UI with some sample data in it :)

Notice that Blend sometimes doesn’t refresh the design view as soon as we make some changes on the data template (it works fine on non data template changes).
I only found that the effective way is to just close and reopen to see the changes effect, so if you’re editing something on the data template and it’s not reflecting, try to close and reopen it first :)

I found this sample data feature is very useful, how bout you?

Have also shared the sample project for grabs here.

Hope this helps :)

You see, I was working on a defect/bug yesterday, it was a pretty simple bug that I was happily to fix as it looks like a less than an hour job, so I did the fix below, got the test evidences and marked that defect as fixed, ready for promotion to the test environment.

private Boolean _someFlag;
private String _someOption;

private void Execute()
{
    //... some codes here

    // the following block of codes is the fix to resolve the defect/bug
    if (_someOption.Contains("something"))
    {
        _someFlag = true;
    }
    else
    {
        _someFlag = false;
    }

    //... some codes here
}

To my horror this morning, there’s a new defect being raised, complaining that there’s an error pop-up whenever the user tried to click on the execute button.

And quickly I realized that the error was coming from the modified code above. And to make things worst, the code above is in the base class of let say 10 UI forms and 3 of them are now not working/usable at all due to this new bug.

Now fixing this new bug is another simple task to do, but the thing that stayed on my mind till now is that when I wrote that fix yesterday, it actually came to my mind that I should be putting some unit tests on them, this new bug will definitely get captured if I were to write the unit tests (basic positive, negative, null tests). But nah, my overconfidence took over that this is a simple fix, nothing’s going to ever happen with this fix, everything will be running happily tomorrow, I should check this in ASAP and hurrah! one defect down.

So what are the consequences with that?

1. Testing activities were blocked on for 3 of 10 UIs, where actually without the code fix, all were actually working fine, it’s just a minor dodgy state that was incorrect
2. One more day was wasted to get the new fix promoted so the testing can be continued
3. For having end users/testers to actually see this error message, it’s embarrassing the development team
4. And in the end, this kind of error is truly embarrassing for a .Net programmer, with these years of experiences for sure :|

(hope you don’t mind, Uncle Bob, I’ll make sure that I write the book review when I’m done reading your book :))

As you mature in your profession, your error rate should rapidly decrease towards the asymptote of zero. It won’t ever get to zero, but it is your responsibility to get as close as possible to it.

Hit the nail on the head of what I was expected to do. So moral of the story, be humble, don’t ignore your inner voice, and believe in unit testing/TDD.

PS: Tony, if you actually read this, just know that today in my head, i kept imagining you’re telling me “See, I told you, Bembeng” :p

Now, when I tried to do the regular steps to investigate the root cause, the CLR Profiler was not responding when I clicked the Show Heap now button and eventually display the pop-up below.

Then realised that since we have just upgraded the application to use .Net 4.0, so there’s a chance that there’s a new CLR Profiler on the block for .Net 4.0, and turned out there is actually a new one available in MSDN. And it’s not surprising, considering that .Net 4.0 comes with a new CLR as well (click on the image below to go to the msdn website for more info)

After downloaded the new CLR Profiler 4, it looks like below, notice the new Attach Process and Detach Process buttons, those will be very useful as we always need to start the application in the previous version, sweet! :)

Now, it’s time to duck into the the heap :)

Why would we ever want to do this? wouldn’t it be best if we parallel some activities as many as possible?

For certain cases, we might want to be careful for not creating too many sudden requests at the same time, a good example will be if we’re triggering a long running process in our application server, you wouldn’t want to spawn too many requests at the same time to the server, as the server may not be able to handle so many requests at the same time and not surprisingly go down due to overload. This can be categorized as DOS attack, your back end guys will hate you for this, trust me :p

To set the concurrency level of the actions that you’re going to invoke with the Parallel class is pretty simple.

Parallel.Invoke(new ParallelOptions() { MaxDegreeOfParallelism = concurrencyLevel }, actions);

Find more about the MaxDegreeOfParallelism property in msdn.
We don’t have this such of property in the TaskCreationOptions that we can simply pass for Task, but there’s a LimitedConcurrencyLevelTaskScheduler nicely available which we can achieve the same result below where i basically spawn 10 processes with 2 max concurrency level.


15-Apr-2011 21:04:33.948 - Thead#13 - Creating 10 process definitions
15-Apr-2011 21:04:33.948 - Thead#13 - Start queueing and invoking all 10 processes
15-Apr-2011 21:04:33.948 - Thead#13 - Doing something here
15-Apr-2011 21:04:33.948 - Thead#14 - Doing something here
15-Apr-2011 21:04:34.964 - Thead#13 - Doing something here
15-Apr-2011 21:04:34.964 - Thead#14 - Doing something here
15-Apr-2011 21:04:35.964 - Thead#13 - Doing something here
15-Apr-2011 21:04:35.964 - Thead#14 - Doing something here
15-Apr-2011 21:04:36.964 - Thead#13 - Doing something here
15-Apr-2011 21:04:36.964 - Thead#14 - Doing something here
15-Apr-2011 21:04:37.964 - Thead#13 - Doing something here
15-Apr-2011 21:04:37.964 - Thead#14 - Doing something here
15-Apr-2011 21:04:38.964 - Thead#13 - All processes have been completed


using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace ParallelTests
{
    [TestClass]
    public class TaskSchedulerConcurrencyTest
    {
        [TestMethod]
        public void TestMethod1()
        {
            var p = new ProcessorUsingParallel();
            p.DoProcess(processToCreate: 10, concurrencyLevel: 2);
        }
    }

    public class ProcessorUsingParallel
    {
        public void DoProcess(int processToCreate, int concurrencyLevel)
        {
            SetTurboMode();

            Debug("Creating {0} process definitions", processToCreate.ToString());

            var actions = new Action[processToCreate];
            for (int i = 0; i < processToCreate; i++)
            {
                actions[i] = () => DoSomething(1000);
            }

            Debug("Start queueing and invoking all {0} processes", processToCreate.ToString());
            var options = new ParallelOptions();
            options.MaxDegreeOfParallelism = concurrencyLevel;
            //options.TaskScheduler = new LimitedConcurrencyLevelTaskScheduler(concurrencyLevel); -- we can achieve the same result with this
            Parallel.Invoke(options, actions);

            Debug("All processes have been completed");
        }

        private void DoSomething(int Sleep)
        {
            Debug("Doing something here");
            Thread.Sleep(Sleep);
        }

        /// <summary>
        /// oh i just wish the framework would have this in place like Console.WriteLine
        /// </summary>
        /// <param name="format"></param>
        /// <param name="args"></param>
        private static void Debug(string format, params object[] args)
        {
            System.Diagnostics.Debug.WriteLine(
                string.Format("{0} - Thead#{1} - {2}",
                    DateTime.Now.ToString("dd-MMM-yyyy HH:mm:ss.fff"),
                    Thread.CurrentThread.ManagedThreadId.ToString(),
                    string.Format(format, args)));
        }
        /// <summary>
        /// This is not intended for production purpose
        /// </summary>
        private static void SetTurboMode()
        {
            int t, io;
            ThreadPool.GetMaxThreads(out t, out io);
            Debug("Default Max {0}, I/O: {1}", t, io);

            var success = ThreadPool.SetMinThreads(t, io);
            Debug("Successfully set Min {0}, I/O: {1}", t, io);
        }
    }
}

However, notice one thing below that I’m using ConcurrentBag<T> type which is a thread-safe bag implementation, optimized for scenarios where the same thread will be both producing and consuming data stored in the bag (taken from the msdn page).

An interesting fact with this, it takes around 74 secs to complete where if we’re not concern about return values (remove the usage of the ConcurrentBag<T>), it will only take around 28 seconds where using Task (with or without return values), it will only take 22 secs. I guess we can probably use a “state object” to pass into the invocation to hold the values for each process to avoid the locking costs, but since Task is already doing this well, it will need a justification why we need to do that manually ourselves with Parallel.Invoke solution. Moral of the story: always get the facts first by each alternative for your solution then decision will be easy and justifiable.

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.Threading.Tasks;
using System.Threading;
using System.Collections.Concurrent;

namespace ParallelismTests
{
    [TestClass]
    public class ParallelTest
    {
        [TestMethod]
        public void TestMethod1()
        {
            var p = new ProcessorUsingParallel();
            var counts = p.DoProcess(hiLevelParallelism: 1000, loLevelParallelism: 1000);

            Assert.AreEqual(1000 * 1000, counts);
        }
    }

    public class ProcessorUsingParallel
    {
        public int DoProcess(int hiLevelParallelism, int loLevelParallelism)
        {
            Utility.SetTurboMode();

            Utility.Debug("Start queueing {0} high level processes", hiLevelParallelism.ToString());

            var counts = new ConcurrentBag<int>();
            var r = new Random();

            var actions = new Action[hiLevelParallelism];
            for (int i = 0; i < hiLevelParallelism; i++)
            {
                actions[i] = () => counts.Add(DoHighLevelProcess(r, loLevelParallelism));
            }

            Utility.Debug("Invoking all {0} high level tasks", hiLevelParallelism.ToString());
            Parallel.Invoke(actions);

            Utility.Debug("All processes have been completed");
            return counts.Sum(t => t);
        }

        private int DoHighLevelProcess(Random r, int loLevelParallelism)
        {
            var counts = new ConcurrentBag<int>();
            var actions = new Action[loLevelParallelism];
            for (int i = 0; i < loLevelParallelism; i++)
            {
                actions[i] = () => counts.Add(DoLowLevelProcess(r.Next(1, 10)));
            }
            Parallel.Invoke(actions);

            Utility.Debug("DoHighLevelProcess - Completed with {0} LowLeveProcesses", loLevelParallelism);
            return counts.Sum(t => t);
        }
        private int DoLowLevelProcess(int Sleep)
        {
            Thread.Sleep(Sleep);
            return 1;
        }
    }
}

Now by using WaitHandle.WaitAll, we can see there’s a limit of 64 waithandles for waiting, so with the new Task Parallel Library in .Net 4.0, we don’t have to worry about that kind of limitation anymore.

Using the code in the previous post, I then used the Task class to perform the concurrent processes. Notice the code below, I’m actually create 1.000 high level processes which will create 1.000 low level processes each, so in total 1.000.000 processes. And another very nice thing here is that we can actually return a value from each task very easily compared to the previous solution using Threadpool.

One more interesting here is that, noticed the line#40 & #54: Task.WaitAll(tasks.ToArray());, with that line in place, it would only take 20+ seconds to complete where without it (remove/comment those lines), it would then take 11 minutes. That a pretty huge difference ;)

Reason: I think it makes sense, because without that line, we will be waiting for the task completion sequentially in the SUM operation when Task.Result was being called, where the completion of 1 task with the next/previous task in the collection might be different, where Task.WaitAll will basically get all the signals by each task as when it completed, so when the SUM operation is being called, all the results are already available without any need to wait anymore :)

using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.Threading.Tasks;
using System.Threading;

namespace ParallelismTests
{
    [TestClass]
    public class TaskTest
    {
        [TestMethod]
        public void TestMethod1()
        {
            var p = new ProcessorUsingTask();
            var counts = p.DoProcess(hiLevelParallelism: 1000, loLevelParallelism: 1000);

            Assert.AreEqual(1000*1000, counts);
        }
    }

    public class ProcessorUsingTask
    {
        public int DoProcess(int hiLevelParallelism, int loLevelParallelism)
        {
            SetTurboMode();

            Debug("Start queueing {0} high level processes", hiLevelParallelism.ToString());

            var tasks = new List<Task<int>>();
            var r = new Random();
            for (int i = 0; i < hiLevelParallelism; i++)
            {
                var task = Task.Factory.StartNew<int>(() => DoHighLevelProcess(r, loLevelParallelism));
                tasks.Add(task);
            }

            Debug("Waiting for all {0} high level tasks to complete", hiLevelParallelism.ToString());
            Task.WaitAll(tasks.ToArray()); // try comment this line out and see the performance impact :)

            Debug("All processes have been completed");
            return tasks.Sum(t => t.Result);
        }

        private int DoHighLevelProcess(Random r, int loLevelParallelism)
        {
            var tasks = new List<Task<int>>();
            for (int i = 0; i < loLevelParallelism; i++)
            {
                var task = Task.Factory.StartNew<int>(() => DoLowLevelProcess(r.Next(1, 10)));
                tasks.Add(task);
            }
            Task.WaitAll(tasks.ToArray()); // try comment this line out and see the performance impact :)
            
            Debug("DoHighLevelProcess - Completed with {0} LowLeveProcesses", loLevelParallelism);
            return tasks.Sum(t => t.Result);
        }
        private int DoLowLevelProcess(int Sleep)
        {
            Thread.Sleep(Sleep);
            //Debug("DoLowLevelProcess - Completed after {0} ms", Sleep.ToString());
            return 1;
        }

        /// <summary>
        /// oh i just wish the framework would have this in place like Console.WriteLine
        /// </summary>
        /// <param name="format"></param>
        /// <param name="args"></param>
        private static void Debug(string format, params object[] args)
        {
            System.Diagnostics.Debug.WriteLine(
                string.Format("{0} - Thead#{1} - {2}",
                    DateTime.Now.ToString("dd-MMM-yyyy HH:mm:ss.fff"),
                    Thread.CurrentThread.ManagedThreadId.ToString(),
                    string.Format(format, args)));
        }
        /// <summary>
        /// This is not intended for production purpose
        /// </summary>
        private static void SetTurboMode()
        {
            int t, io;
            ThreadPool.GetMaxThreads(out t, out io);
            Debug("Default Max {0}, I/O: {1}", t, io);

            var success = ThreadPool.SetMinThreads(t, io);
            Debug("Successfully set Min {0}, I/O: {1}", t, io);
        }
    }
}

In the initial stage when I started the changes, I hit the following exception System.NotSupportedException: The number of WaitHandles must be less than or equal to 64. We then introduced some threshold limit for the degree of parallelism to avoid this exception. So all are working fine afterwards.

Now after one change to another, we started to see the opportunity of increasing the parallelism degree such as below, this brought me into a doubt where this 64 handles limitation is being applied (process / app domain level) and whether this recursive method will trigger the same issue if in the end we’re waiting for more than 64 handles for all layers.

Now if we RTFM, it basically says “The WaitAll method returns when all the handles are signaled. On some implementations, if more than 64 handles are passed, a NotSupportedException is thrown”

Just to confirm this, I created a test below which will basically execute x number of high level parallel processes which will then also execute x number low level parallel processes based on the provided parameters. So the code below will try to create around 64 * 64 = 4096 handles in totals

var p = new Processor();
p.DoProcess(hiLevelParallelism : 64, loLevelParallelism : 64);

Results

05-Apr-2011 00:42:06.781 - Thead#13 - Start queueing 64 high level processes
05-Apr-2011 00:42:06.815 - Thead#13 - Waiting for all 64 high level handles to complete
05-Apr-2011 00:42:07.049 - Thead#17 - DoHighLevelProcess - Completed with 64 LowLeveProcesses
05-Apr-2011 00:42:07.141 - Thead#15 - DoHighLevelProcess - Completed with 64 LowLeveProcesses
05-Apr-2011 00:42:07.287 - Thead#24 - DoHighLevelProcess - Completed with 64 LowLeveProcesses
..
.. omitted 58 similar lines here
..
05-Apr-2011 00:42:08.087 - Thead#28 - DoHighLevelProcess - Completed with 64 LowLeveProcesses
05-Apr-2011 00:42:08.179 - Thead#27 - DoHighLevelProcess - Completed with 64 LowLeveProcesses
05-Apr-2011 00:42:08.297 - Thead#17 - DoHighLevelProcess - Completed with 64 LowLeveProcesses
05-Apr-2011 00:42:08.455 - Thead#13 - All processes have been completed

It always feel much better if we see it running in the code, doesn’t it? :)

Source code

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System.Threading;
using System.Diagnostics;

namespace ParallelismTests
{
    [TestClass]
    public class WaitHandleTest
    {
        [TestMethod]
        public void TestMethod1()
        {
            var p = new Processor();
            p.DoProcess(hiLevelParallelism : 64, loLevelParallelism : 64);
        }
    }

    public class Processor
    {
        public void DoProcess(int hiLevelParallelism, int loLevelParallelism)
        {
            SetTurboMode();

            Debug("Start queueing {0} high level processes", hiLevelParallelism.ToString());

            var r = new Random();
            var hiLevelHandles = new AutoResetEvent[hiLevelParallelism];
            for (int i = 0; i < hiLevelParallelism; i++)
            {
                var hiLevelHandle = new AutoResetEvent(false);
                hiLevelHandles[i] = hiLevelHandle;
                ThreadPool.QueueUserWorkItem((s) =>
                {
                    DoHighLevelProcess(r, loLevelParallelism);
                    hiLevelHandle.Set();
                });
            }

            Debug("Waiting for all {0} high level handles to complete", hiLevelParallelism.ToString());
            WaitHandle.WaitAll(hiLevelHandles);

            Debug("All processes have been completed");
        }

        private void DoHighLevelProcess(Random r, int loLevelParallelism)
        {
            var loLevelHandles = new AutoResetEvent[loLevelParallelism];
            for (int i = 0; i < loLevelParallelism; i++)
            {
                var loLevelHandle = new AutoResetEvent(false);
                loLevelHandles[i] = loLevelHandle;
                ThreadPool.QueueUserWorkItem((s) =>
                {
                    DoLowLevelProcess(r.Next(1, 10));
                    loLevelHandle.Set();
                });
            }
            WaitHandle.WaitAll(loLevelHandles);

            Debug("DoHighLevelProcess - Completed with {0} LowLeveProcesses", loLevelParallelism);
        }
        private void DoLowLevelProcess(int Sleep)
        {
            Thread.Sleep(Sleep);
            //Debug("DoLowLevelProcess - Completed after {0} ms", Sleep.ToString());
        }

        /// <summary>
        /// oh i just wish the framework would have this in place like Console.WriteLine
        /// </summary>
        /// <param name="format"></param>
        /// <param name="<span class=" />args">
        private static void Debug(string format, params object[] args)
        {
            System.Diagnostics.Debug.WriteLine(
                string.Format("{0} - Thead#{1} - {2}",
                    DateTime.Now.ToString("dd-MMM-yyyy HH:mm:ss.fff"),
                    Thread.CurrentThread.ManagedThreadId.ToString(),
                    string.Format(format, args)));
        }
        /// <summary>
        /// This is not intended for production purpose
        /// </summary>
        private static void SetTurboMode()
        {
            int t, io;
            ThreadPool.GetMaxThreads(out t, out io);
            Debug("Default Max {0}, I/O: {1}", t, io);

            var success = ThreadPool.SetMinThreads(t, io);
            Debug("Successfully set Min {0}, I/O: {1}", t, io);
        }
    }
}

Interestingly it was then breaking with the exception: The calling thread must be STA, because many UI components require this when trying to perform some action on the WPF control where it’s working fine for the existing winform version.

Turned out that this was due to the code was being invoked from a background thread through threadpool. Now it’s pretty easy to resolve this, we can use the Dispatcher property which is inherited by DispatcherObject abstract class which is the base class of WPF User Control.

Now the Dispatcher class itself turned out to have a DispatcherExtensions class (below) as well which accept Action type

So in order to fix the calling thread exception, we just need to have the following code.

void OnSomeRequest()
{
    if (!Dispatcher.CheckAccess())
    {
        Dispatcher.Invoke(() => OnSomeRequest());
    }
    else
    {
        someUserControl.DoSomething();
    }
}

Now if we only have 1 certain place which will perform some UI update in the code, this is okay, but imagine if you have many places in the code that you need to repeat the pattern above :p

So we can simplify the above again into below, we have reduced the code from 8 lines into just 1 line :)

void OnSomeRequest()
{
    Dispatcher.InvokeIfRequired(() => someUserControl.DoSomething());
}

The new extension over existing DispatcherExtension is simple.

using System;
using System.Windows.Threading;

namespace ExtensionTests
{
    public static class AnotherDispatcherExtensions
    {
        public static void InvokeIfRequired(this Dispatcher dispatcher, Action action)
        {
            if (!dispatcher.CheckAccess())
            {
                dispatcher.Invoke(action);
            }
            else
            {
                action();
            }
        }
    }
}

Note that we can always add more extensions into this class, for me, I only have one above as I only require it, simple and only introduce when you need it :)

Eric De Carufel has written the more complete extensions as well in his blog post
And if you’re wondering why VS intellisense is giving you a false alarm that CheckAccess is not available for Dispatcher, Claus Konrad explained it in his blog post