Peretz.Net

2011-04-16T17:48:00.001-07:00

How to turn off your monitor



namespace TurnoffMonitor
{
    /// 
    /// Interaction logic for MainWindow.xaml
    /// 

    public partial class MainWindow : Window
    {
        [DllImport("user32.dll")]
        static extern IntPtr SendMessage(IntPtr hWnd, uint Msg,
                      IntPtr wParam, IntPtr lParam);

        const int SC_MONITORPOWER = 0xF170;
        const uint WM_SYSCOMMAND = 0x0112;
        
        const int MONITOR_ON = -1;
        const int MONITOR_OFF = 2;
        const int MONITOR_STANBY = 1;
        
        public MainWindow()
        {
            InitializeComponent();
        }

        private void ExecuteButton_Click(object sender, RoutedEventArgs e)
        {
            WindowInteropHelper helper = new WindowInteropHelper(this);
            var handle = helper.Handle;

            
            SendMessage(handle, WM_SYSCOMMAND, new IntPtr(SC_MONITORPOWER), new IntPtr(MONITOR_OFF));
        }
    }
}

WCF 4.0 Service Discovery - Adding the binding to the discovery

2010-04-10T13:15:00.000-07:00

With WCF 4.0 a wonderful new feature is added. Service Discovery allows us to see what services are running and where they are. However, when I started to look into this in detail, I noticed the information you get on services only contains the A (Address) and C (Contract) of the ABC, The Address and the Contract - but not the binding. So in this article I will show how to add the binding to the discovery information with little ease.

Note: All the code is developed on Visual Studio 2010 RC

EndpointDiscoveryMetadata

Within the discovery this class is probably one of the most important ones. This is the information we get when services go up and down. Below you can see that there is no binding information about the service.

Notice you can get the contact names, using:
Collection ContractTypeNames { get; }

and you can get the address using:
public EndpointAddress Address { get; set; }

But, no binding information!

When I posted on the forum asking why was it done this way, they told me that the binding are not part of the discovery standard (WS Discovery), they also told me that you can get the binding without problems by simply discovering the Mex endpoint and then issuing a call to get the metadata of the service. But, that is not ideal, you would need to discovery the service, and then get its metadata just to know the full ABC of an endpoint (2 network trips).
(http://social.msdn.microsoft.com/Forums/en/wcfprerelease/thread/ca6bc4be-bc46-4740-ba1e-dca8cf39aa5f)

One key field that EndpointDiscoveryMetadata has is Extensions. So right away I decided to see how I can fill up these extensions and add my own custom information in there. In this case it would be binding information.

The code

The example below is based on the WCF / WF code examples from Microsoft. The code has been modified to add binding information to the discovery metadata. I have used the Service Proxy example for this prototype.

You can get the Microsoft sample code here: http://www.microsoft.com/downloads/details.aspx?FamilyID=35ec8682-d5fd-4bc3-a51a-d8ad115a8792&displaylang=en

Adding Extensions to the EndpointDiscoveryMetadata

To add an extension to the Discovery Metadata, you need to create a new Endpoint Behavior and add it to the Endpoint.Behaviors collection. The behavior is a special behavior that belongs to the Discovery sub-system, it is called EndpointDiscoveryBehavior. Once you create this behavior you can add extensions to it using the Extension collection.
endpointDiscoveryBehavior.Extensions.Add

To make sure that the binding information is attached to the discovery metadata of each endpoint, the best approach was to create a new ServiceBehavior, and add a EndpointDiscoveryBehavior to each endpoint.

Below is the code of the Service Behavior:


    public class BindingDiscoveryServiceBehavior : Attribute, IServiceBehavior
    {
        public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection endpoints, BindingParameterCollection bindingParameters)
        {
            
        }

        public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
        {
            var endpoints = serviceDescription.Endpoints;

            foreach (ServiceEndpoint endpoint in endpoints)
            {
                var endpointDiscoveryBehavior = new EndpointDiscoveryBehavior();

                StringBuilder sb = new StringBuilder();

                sb.Append(endpoint.Address); 
                sb.Append(Environment.NewLine);
                sb.Append(endpoint.Binding.Scheme);
                sb.Append(Environment.NewLine);
                sb.Append(endpoint.Binding.Name);

                string bindingInfo = sb.ToString();
                string largeData = String.Empty;

                StringBuilder sb2 = new StringBuilder();
                for (int i = 0; i < 3000000; i++)
                    sb2.Append("Lots of data " + i.ToString() + Environment.NewLine);

                largeData = sb2.ToString();

                // add the binding information to the endpoint
                endpointDiscoveryBehavior.Extensions.Add(
                    new XElement(
                        "root",
                        new XElement("BindingData", bindingInfo),
                        new XElement("LargeData", largeData)));

                // add the extension
                endpoint.Behaviors.Add(endpointDiscoveryBehavior);

            }
        }

        public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
        {
            
        }
    }

Note that I have also added a very large data to the extension, just to show that you can pass large amount of data in the Extensions. (but you need to increase the limits on the discovery proxy TCP binding).

The next step is simple, you just need to add your Service Behavior to your service. You can do this by configuration, or simply applying it as an attribute on the service:


[BindingDiscoveryServiceBehavior]
public class CalculatorService : ICalculatorService

Getting the information when a service is "Discovered"

To see the binding information when a service is discovered, I have modified the Service Proxy from the WCF discovery example:

When a service is discovered, the OnBeginOnlineAnnouncement is called..

Below is the modified implementation:


    [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)]
    public class DiscoveryProxyService : DiscoveryProxy
    {
        // Repository to store EndpointDiscoveryMetadata. A database or a flat file could also be used instead.
        Dictionary onlineServices;

        public DiscoveryProxyService()
        {
            this.onlineServices = new Dictionary();
        }

        // OnBeginOnlineAnnouncement method is called when a Hello message is received by the Proxy
        protected override IAsyncResult OnBeginOnlineAnnouncement(DiscoveryMessageSequence messageSequence, EndpointDiscoveryMetadata endpointDiscoveryMetadata, AsyncCallback callback, object state)
        {        
            this.AddOnlineService(endpointDiscoveryMetadata);
            return new OnOnlineAnnouncementAsyncResult(callback, state);
        }

        protected override void OnEndOnlineAnnouncement(IAsyncResult result)
        {
            OnOnlineAnnouncementAsyncResult.End(result);
        }

        // OnBeginOfflineAnnouncement method is called when a Bye message is received by the Proxy
        protected override IAsyncResult OnBeginOfflineAnnouncement(DiscoveryMessageSequence messageSequence, EndpointDiscoveryMetadata endpointDiscoveryMetadata, AsyncCallback callback, object state)
        {            
            this.RemoveOnlineService(endpointDiscoveryMetadata);
            return new OnOfflineAnnouncementAsyncResult(callback, state);
        }

        protected override void OnEndOfflineAnnouncement(IAsyncResult result)
        {
            OnOfflineAnnouncementAsyncResult.End(result);
        }

        // OnBeginFind method is called when a Probe request message is received by the Proxy
        protected override IAsyncResult OnBeginFind(FindRequestContext findRequestContext, AsyncCallback callback, object state)
        {
            this.MatchFromOnlineService(findRequestContext);
            return new OnFindAsyncResult(callback, state);
        }

        protected override void OnEndFind(IAsyncResult result)
        {
            OnFindAsyncResult.End(result);
        }

        // OnBeginFind method is called when a Resolve request message is received by the Proxy
        protected override IAsyncResult OnBeginResolve(ResolveCriteria resolveCriteria, AsyncCallback callback, object state)
        {
            return new OnResolveAsyncResult(this.MatchFromOnlineService(resolveCriteria), callback, state);
        }

        protected override EndpointDiscoveryMetadata OnEndResolve(IAsyncResult result)
        {
            return OnResolveAsyncResult.End(result);
        }

        // The following are helper methods required by the Proxy implementation
        void AddOnlineService(EndpointDiscoveryMetadata endpointDiscoveryMetadata)
        {
            lock (this.onlineServices)
            {
                this.onlineServices[endpointDiscoveryMetadata.Address] = endpointDiscoveryMetadata;                
            }

            PrintDiscoveryMetadata(endpointDiscoveryMetadata, "Adding");
            // show the binding information
            PrintBindingInformation(endpointDiscoveryMetadata);
        }

        private void PrintBindingInformation(EndpointDiscoveryMetadata endpointDiscoveryMetadata)
        {
            // Get the binding data
            XElement element = endpointDiscoveryMetadata.Extensions.Elements("BindingData").FirstOrDefault();
            string bindingInfo = element.Value;

            Console.WriteLine("Binding Data");
            Console.WriteLine(bindingInfo);          
        }

        void RemoveOnlineService(EndpointDiscoveryMetadata endpointDiscoveryMetadata)
        {            
            if (endpointDiscoveryMetadata != null)
            {
                lock (this.onlineServices)
                {
                    this.onlineServices.Remove(endpointDiscoveryMetadata.Address);                    
                }

                PrintDiscoveryMetadata(endpointDiscoveryMetadata, "Removing");
            }    
        }

        void MatchFromOnlineService(FindRequestContext findRequestContext)
        {
            lock (this.onlineServices)
            {
                foreach (EndpointDiscoveryMetadata endpointDiscoveryMetadata in this.onlineServices.Values)
                {
                    if (findRequestContext.Criteria.IsMatch(endpointDiscoveryMetadata))
                    {                        
                        findRequestContext.AddMatchingEndpoint(endpointDiscoveryMetadata);
                    }
                }
            }
        }

        EndpointDiscoveryMetadata MatchFromOnlineService(ResolveCriteria criteria)
        {
            EndpointDiscoveryMetadata matchingEndpoint = null;
            lock (this.onlineServices)
            {
                foreach (EndpointDiscoveryMetadata endpointDiscoveryMetadata in this.onlineServices.Values)
                {
                    if (criteria.Address == endpointDiscoveryMetadata.Address)
                    {
                        matchingEndpoint = endpointDiscoveryMetadata;
                    }
                }
            }
            return matchingEndpoint;
        }

        void PrintDiscoveryMetadata(EndpointDiscoveryMetadata endpointDiscoveryMetadata, string verb)
        {
            Console.WriteLine("\n**** " + verb + " service of the following type from cache. ");
            foreach (XmlQualifiedName contractName in endpointDiscoveryMetadata.ContractTypeNames)
            {
                Console.WriteLine("** " + contractName.ToString());
                break;
            }
            Console.WriteLine("**** Operation Completed");
        }

        sealed class OnOnlineAnnouncementAsyncResult : AsyncResult
        {
            public OnOnlineAnnouncementAsyncResult(AsyncCallback callback, object state)
                : base(callback, state)
            {
                this.Complete(true);
            }

            public static void End(IAsyncResult result)
            {
                AsyncResult.End(result);
            }
        }

        sealed class OnOfflineAnnouncementAsyncResult : AsyncResult
        {
            public OnOfflineAnnouncementAsyncResult(AsyncCallback callback, object state)
                : base(callback, state)
            {
                this.Complete(true);
            }

            public static void End(IAsyncResult result)
            {
                AsyncResult.End(result);
            }
        }

        sealed class OnFindAsyncResult : AsyncResult
        {
            public OnFindAsyncResult(AsyncCallback callback, object state)
                : base(callback, state)
            {
                this.Complete(true);
            }
    
            public static void End(IAsyncResult result)
            {
                AsyncResult.End(result);
            }
        }
    
        sealed class OnResolveAsyncResult : AsyncResult
        {
            EndpointDiscoveryMetadata matchingEndpoint;
    
            public OnResolveAsyncResult(EndpointDiscoveryMetadata matchingEndpoint, AsyncCallback callback, object state)
                : base(callback, state)
            {
                this.matchingEndpoint = matchingEndpoint;
                this.Complete(true);
            }
    
            public static EndpointDiscoveryMetadata End(IAsyncResult result)
            {
                OnResolveAsyncResult thisPtr = AsyncResult.End(result);
                return thisPtr.matchingEndpoint;
            }
        }
    }

Notice that I am getting the binding information in the code below:

XElement element = endpointDiscoveryMetadata.Extensions.Elements("BindingData").FirstOrDefault();
string bindingInfo = element.Value;

Now I have the binding information, so when I ask for a specific contract, I can get the binding as well as the address back to the client that is requesting the endpoint information. Now we can discover the full A B C and not just the A and C.

WAS hosting for services with multiple msmq binding endpoints - not ideal!

2009-09-19T07:25:00.000-07:00

I have been looking into this issue of hosting a service with multiple message queue endpoints with WAS for sometime. One thing that kept bothering me is that the SVC file name of the service needed to match the name of the queue. Furthermore, it was not just the name of the queue, but the name of the virtual folder + the queue name so the activation service will detect messages in my queue and then activate my service.

Once I got all the pieces to work, I renamed my SVC file, checked the permission of my queue to allow the activation service to peek into it, and got the service hosted in WAS, I realized that I can't get another queue on the same service to work. Considering the SVC file needs to match the queue, only one endpoint is satisfied, having another queue endpoint is possible, but the activation service will not look at it. This means that the service will process messages of another queue, but the service will not be activated based on these other queues. So you will need to first activate the service using the SVC named queue, and then the other queues will work.

This means that if you try to host a service with multiple queue endpoints, you must choose which queue will be responsible for the activation of the service. Only one must be chosen (and that queue needs to have the SVC file name renamed after it). Other queues, will not force activation of the service.

I have confirmed this to be true with Micrsofot support. They couldn't even give a good explanation why this was done this way. Why do you need to rename the SVC file? why can't you just use a configuration? or read the metadata of the service... I can think of many other ways to handle activation of queues, without the limitation of one queue per service, and forcing the user to rename his SVC file.

So how do you handle a service with multiple queue endpoints? Well, one simple way is not to use WAS hosting and use Windows Service Hosting, this problem does not exist with non-was hosting, but you loose on the activation model. You can make your own activation model, but that's like re-doing WAS.

Another option if you like using WAS, is to create multiple SVC files, one named after each queue within your service. The SVC files will all point to the same service class / assembly, but it will cause multiple service instances to be created depending on which queue forced the activation. You place all these SVC files within the same virtual folder. This might work only if the service is completely stateless.

Other work-around is to make sure the idle timeout is really large, so your service is only activated once, and then stays alive "forever". But, that just takes the activation out of WAS, which at that point, you may as well host it within a windows service.

Microsoft support also told me, that you can "ping" your service, to make sure it is activated, but that's just crazy... so I will not write more about that option.

Or... you can simply avoid having multiple queues in the same service (if you are planning to host your service under WAS).

I plan to update this post with an official KB article explaining this issue. Microsoft Support told me they will send it to me once they all agree this is a limitation by design.

Although this is not a popular feature of WAS, I feel there might be others out there trying the very same thing I am trying. I hope this helps them a little bit.

Pub / Sub with WCF and Silverlight 3.0 (using polling duplex)

2009-08-18T19:11:00.000-07:00

A good exmaple to check out
http://tomasz.janczuk.org/2009/07/pubsub-sample-using-http-polling-duplex.html

GetHashCode using MD5

2009-08-14T11:07:00.000-07:00

Wanted to have a way to get a hash code for an object, and the code will be different when the data within the object changes. Only supported for objects that support serialization... but it is better then nothing...


   public static class HashCodeGenerator
   {
      public static string GetMD5HashCode(this object obj)
      {
         MemoryStream stream = new MemoryStream();
         BinaryFormatter formatter = new BinaryFormatter();
         formatter.Serialize(stream, obj);
         stream.Flush();
         var data = stream.ToArray();
         StringBuilder sBuilder = new StringBuilder();

         // get the hash code of the object.
         MD5CryptoServiceProvider md5 = new MD5CryptoServiceProvider();
         var hashBytesArray =  md5.ComputeHash(data);

         // Loop through each byte of the hashed data 
         // and format each one as a hexadecimal string.
         for (int i = 0; i < hashBytesArray.Length; i++)
         {
            sBuilder.Append(hashBytesArray[i].ToString("x2"));
         }

         return sBuilder.ToString();
      }

      public static bool CompareMD5HashCode(this object obj, string hashCode)
      {
         string hash = obj.GetMD5HashCode();
         bool isMatch = false;
         if (hash == hashCode)
            isMatch = true;

         return isMatch;        
      }      
   }

Object to XML and XML to Object

2009-08-13T17:54:00.000-07:00

I always need this code... so now its on my page!


   internal static class XmlSerializerHelper
   {
      public static object GetObjectFromXml(string xml, Type type)
      {
         XmlSerializer ser = new XmlSerializer(type);
         object value = ser.Deserialize(new StringReader(xml));
         return value;
      }

      public static string GetXmlFromObj(object obj, Type type)
      {
         string xml;
         XmlSerializer ser = new XmlSerializer(type);
         using (StringWriter writer = new StringWriter())
         {
            ser.Serialize(writer, obj);
            writer.Flush();
            xml = writer.ToString();
         }

         return xml;
      }

      public static string ToXml(this object obj)
      {
         Type type = obj.GetType();
         string xml = GetXmlFromObj(obj, type);
         return xml;
      }

   }

DataForm Control supporting nested classes

2009-08-13T17:12:00.000-07:00

One of the cool things in the toolkit is a new DataForm control. You can give it any object and it will produce a form that will allow you to edit / read your object. However, I noticed that the DataForm, out of the box does not support "auto generation" of fields for nested complex types. This is something that sounds simple to support out of the box, becasue a nested class is really another DataForm control nested within its parent DataForm. Still, when tyring to put a complex type, the Dataform control simply puts a textbox and put the ToString() value of your complex type as its value. Not very useful.

With the help of the UI guy at my work, we found a way to change this limitation and allow for nested UI. I will include the code in this post, but it is mostly testing code and prototype code. You can take it and modify it for your needs.

To do this we creaed a SuperDataForm control


using System;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Ink;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.Windows.Data;
using System.Collections.Generic;

namespace ParameterManagement
{
   public class SuperDataForm : DataForm
   {
      List Controls = new List();

      public bool CompositeItemIsValid;
      public SuperDataForm()
      {     
         this.Loaded += new RoutedEventHandler(SuperDataForm_Loaded);

      }

      void SuperDataForm_Loaded(object sender, RoutedEventArgs e)
      {
         if (this.CurrentItem == null)
         {
            this.CurrentItem = this.DataContext;
         }     
      }

      protected override void OnAutoGeneratingField(DataFormAutoGeneratingFieldEventArgs e)
      {
         // normally change this condition to check it is one of your complex types
         // or that it is not a basic type.
         if (e.PropertyType == typeof(NestedComplexType))
         {
            var control = new SuperDataForm();

            control.CommandButtonsVisibility = DataFormCommandButtonsVisibility.All;
            control.IsReadOnly = false;
            Controls.Add(control);
            Binding binding = new Binding(e.PropertyName);
            binding.Mode = BindingMode.TwoWay;
            binding.ValidatesOnExceptions = true;
            binding.NotifyOnValidationError = true;
            control.SetBinding(DataForm.CurrentItemProperty, binding);
            e.Field.IsReadOnly = false;
            e.Field.Content = control;
         }

      }

      protected override void OnValidatingItem(System.ComponentModel.CancelEventArgs e)
      {
         // this is needed to have validation on the children controls
         foreach (var control in Controls)
         {
            if (!control.ValidateItem())
            {
               CompositeItemIsValid = false;
               break;
            }         
         }                
      }

      protected override void OnCurrentItemChanged(EventArgs e)
      {
     
      }

  

   }
}

Download Code Here

Silverlight 2.0 + IE6 + Compression - BUG!

2009-05-15T20:43:00.000-07:00

I have been running into a problem with Silverlight 2.0 when dynamic compression was set on IIS7. I found out that the issue was only with IE6 and not with IE7. After googling for some time I found this article… http://otoole.wordpress.com/2009/03/10/18/

After trying a few things in the article like setting caching off, I decided to call Microsoft and hear what they have to say about all this.

Microsoft replied, and said this is a bug with IE6. What makes things worst is that the bug has no work-around or solution. The only solution will be in Silverlight 3.0, and even that is considered a work-around to the real bug which is in IE6.

At the end, the only way to get our Silverlight app to work with IE6 was to turn compression off, which caused some performance issues…

The issue with Microsoft is still open; I have asked them to validate IE8 and the use of SSL, which has been causing problems too…

Generic Singleton method

2009-04-19T10:28:00.000-07:00

This is a general purpose method to create a singleton. It uses generics and takes two arguments, one is the type of the singleton and the other is the type of the interface you wish to return (this is optional). Notice that the method is thread safe, there is a double check to verify that another thread did not create instance after the first if statement. The idea is to have the lock done only once if possible.

Code looks like this:


      private static TInterface GetSingleton(ref TInterface instance)
         where TComponent : class, TInterface, new()
      {
         try
         {
            if (instance == null)
            {
               lock (mLockObject)
               {
                  if (instance == null)
                  {
                     instance = new TComponent();
                  }
               }
            }
            return instance;
         }
         catch (Exception ex)
         {
            LogException(ex);
            throw ex;
         }
      }

Jitting at runtime (Jit methods on the fly)

2009-03-15T11:17:00.001-07:00

What is Jit

Jit stands for Just in time complication. You can read more about JIT here. However, the idea is that the
code is not fully complied, it is pre-complied. The first time your method is executed, the .NET runtime checks if the method has been complied for the target machine, if it did not then it compiles it on the fly. This is called JIT. This behaviour also causes a delay when executing methods for the first time. The bigger the method, the bigger the delay. I have noticed this delay the most when doing UI applications, the generated code would take a long time to JIT. You can also add performance counters to see how much time your application is jitting. In fact most classes that use generated code, can be good candidate for jitting (typed dataset, UI screens, EDMX...)

NGen

NGen is the alternative solution to runtime Jitting. Everything is complied by the NGen tool and a compiled image is placed within the GAC. At runtime when loading the assembly, the runtime will check for a compiled image based on the assembly name and version, if it finds one it will load it without Jitting. Still, NGen needs to run on the target machine before running the application. NGen is also not as efficient as Jit, that's because Jit executes at runtime and has much more information about the method and how to optimize it. You can read more about NGen here.

Is it possible to control the Jitting

I always wanted to have something to control the jitting at runtime. Similar to the GC class, I can control at runtime when the GC is executed, there is not built in class called Jit that will allow me to Jit certain methods. However, it is possible. The method that allows for this type of functionality is RuntimeHelpers.PrepareMethod Method (RuntimeMethodHandle). However, here is a little warning for you all, in the MSDN article it indicates: The classes in System.Runtime.CompilerServices are for compiler writers' use only.. Still, I decided to use it, there are times that I would like to control when Jitting happens.

JitHelper and the PreJit attribute

The idea is very simple. I want to have a helper class that will jit any method that is marked with an attribute of PreJit. Normally the coder knows which are the heavy methods, this way the coder has the control of marking methods that can take long to jit. For example:


        [PreJit]
        private void InitializeComponent()
        {
            this.components = new System.ComponentModel.Container();
            this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
            this.Text = "Form1";
        }

Notice the PreJit attribute on the method.

PreJit is just a marker attribute. Here is the code for it.


    [AttributeUsage(AttributeTargets.Method)]
    public class PreJitAttribute : Attribute
    {
        public PreJitAttribute()
        {

        }
    }

Now, all that is left to do is Jit the methods that are marked with the [PreJit] attribute. Lets take a look at one method that handle jitting based on the type of a CLR class.


        private static void PreJitMarkedMethods(Type type)
        {
            // get the type of all the methods within this instance
            var methods = type.GetMethods(BindingFlags.DeclaredOnly |
                                        BindingFlags.NonPublic |
                                        BindingFlags.Public |
                                        BindingFlags.Instance |
                                        BindingFlags.Static);

            // for each time, jit methods marked with prejit attribute
            foreach (var method in methods)
            {
                // checks if the [PreJit] Attribute is present
                if (ContainsPreJitAttribute(method))
                {
                    // jitting of the method happends here.
                    RuntimeHelpers.PrepareMethod(method.MethodHandle);
                }
            }
        }

        // (helper method) checks if the [PreJit] attribute is present on a method
        private static bool ContainsPreJitAttribute(MethodInfo methodInfo)
        {
            var attributes = methodInfo.GetCustomAttributes(typeof(PreJitAttribute), false);
            if (attributes != null)
                if (attributes.Length > 0)
                {
                    // attribute found return true
                    return true;
                }

            return false;
        }

Lets note the important stuff. This method is able to jit all marked methods with the PreJit attribute based on a CLR type

Getting all methods, private, public and even static

Only Jit methods that have an attribute of [PreJit]
On each method we get the MethodInfo object

Passing MethodInfo.MethodHandle to PrepareMethod allows us to jit a method

The Jitter

Now that it is possible for me to jit every method within a type, all I have to do is create high level
methods that will allow me to do the following:

Jit only methods that are marked with PreJit attribute

Jit on a different thread

Jit based on an instance (Jit methods within the instance)

Jit based on a Type (Jit methods for a given class type)

Jit based on an assembly (Jit methods within all the classes in an assembly

Lets see the full class code for the Jitter


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Reflection;
using System.Threading;
using System.Runtime.CompilerServices;

namespace JitHelper
{
    public class Jitter
    {
        public static void PreJit(object instance)
        {
            PreJitMarkedMethods(instance.GetType());
        }


        public static void PreJitAll(object instance)
        {
            PreJitAllMethods(instance.GetType());
        }

        public static void BeginPreJitAll(object instance)
        {
            Thread preJitThread = new Thread(() =>
            {
                PreJitAllMethods(instance.GetType());
            });

            preJitThread.Name = "PreJittingThread";
            preJitThread.Priority = ThreadPriority.Lowest;
            preJitThread.Start();

        }

        public static void PreJit() where T : class
        {
            PreJitMarkedMethods(typeof(T));
        }


        public static void PreJitAll() where T : class
        {
            PreJitAllMethods(typeof(T));
        }

        public static void BeginPreJitAll() where T : class
        {
            Thread preJitThread = new Thread(() =>
            {
                PreJitAllMethods(typeof(T));
            });

            preJitThread.Name = "PreJittingThread";
            preJitThread.Priority = ThreadPriority.Lowest;
            preJitThread.Start();
        }

        public static void PreJitAll(Assembly assembly)
        {
            var classes = assembly.GetTypes();
            foreach (var classType in classes)
            {
                PreJitAllMethods(classType);
            }
        }

        public static void BeginPreJitAll(Assembly assembly)
        {
            Thread preJitThread = new Thread(() =>
            {
                PreJitAll(assembly);
            });

            preJitThread.Name = "PreJittingThread";
            preJitThread.Priority = ThreadPriority.Lowest;
            preJitThread.Start();
        }


        public static void PreJit(Assembly assembly)
        {
            var classes = assembly.GetTypes();
            foreach (var classType in classes)
            {
                PreJitMarkedMethods(classType);
            }
        }


        public static void BeginPreJit(Assembly assembly)
        {
            Thread preJitThread = new Thread(() =>
            {
                PreJit(assembly);
            });

            preJitThread.Name = "PreJittingThread";
            preJitThread.Priority = ThreadPriority.Lowest;
            preJitThread.Start();
        }

        public static void BeginPreJit(object instance)
        {
            Thread preJitThread = new Thread(() =>
            {
                PreJit(instance);
            });

            preJitThread.Name = "PreJittingThread";
            preJitThread.Priority = ThreadPriority.Lowest;
            preJitThread.Start();
        }

        private static void PreJitMarkedMethods(Type type)
        {
            // get the type of all the methods within this instance
            var methods = type.GetMethods(BindingFlags.DeclaredOnly |
                                        BindingFlags.NonPublic |
                                        BindingFlags.Public |
                                        BindingFlags.Instance |
                                        BindingFlags.Static);

            // for each time, jit methods marked with prejit attribute
            foreach (var method in methods)
            {
                if (ContainsPreJitAttribute(method))
                {
                    // jitting of the method happends here.
                    RuntimeHelpers.PrepareMethod(method.MethodHandle);
                }
            }
        }


        private static void PreJitAllMethods(Type type)
        {
            // get the type of all the methods within this instance
            var methods = type.GetMethods(BindingFlags.DeclaredOnly |
                                        BindingFlags.NonPublic |
                                        BindingFlags.Public |
                                        BindingFlags.Instance |
                                        BindingFlags.Static);

            // Jit all methods
            foreach (var method in methods)
            {
                // jitting of the method happends here.
                RuntimeHelpers.PrepareMethod(method.MethodHandle);
            }
        }


        private static bool ContainsPreJitAttribute(MethodInfo methodInfo)
        {
            var attributes = methodInfo.GetCustomAttributes(typeof(PreJitAttribute), false);
            if (attributes != null)
                if (attributes.Length > 0)
                {
                    return true;
                }

            return false;
        }
    }
}

A few notes about the code:

Methods beginning with "Begin" are executed on a low priority thread. This allows for background jitting. I have not done a callback feature to know when jitting ends, I don't think it is required, but you are free to modify the class and add it.

Method ending with "All", will Jit all methods and not just the one marked as PreJit attribute

Not all methods can be PreJit, for example methods marked as DllExport are not .NET methods, so be careful with the All feature. For performance reasons I have not checked for DllExport attribute, but you can add it if needed.

Notice that one method uses generics, this is simply so the caller can pass the type via generic without doing typeof operator.

Using the Jitter

I will simply show you an exmaple, the following example everything within Form1 is pre-Jitted.


        [STAThread]
        static void Main()
        {
            // Jitting all the methods within Form1 class.
            Jitter.PreJitAll();
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Form1());
        }

if you want to pre-jit within a thread, then simply use:


        [STAThread]
        static void Main()
        {
            Jitter.BeginPreJitAll();
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Form1());
        }

Benchmarking

It is not that simple to benchmark this type of code because it really depends how your application works. However, the Jit operation happends the first time a method is executed. So the first time of any method will cause a delay. I have created a windows form full of text boxes controls, and I used the Jitter to Jit everything within the form class. On the form show event I display the time it took to show the form:

Without using the jitter: ~0.12 milliseconds
With the Jitter: ~0.12 milliseconds
Timing after Jitting: ~0.09 milliseconds

With the Jitter or without it, it took about the same amount of time to show the form.

Without timing the Jitter, just the load operation after the Jit, it took 0.09 miliseconds to show

Overall it means that the Jitter class can have a significate performance improvment at runtime, if a class is jitted before it is being used.

Conclusion

Let me first say that I coded this class mostly because I wanted to have the control over Jitting. But overall .NET runtime does a very good job Jitting when needed. The same way we should not call GC.Collect() we should not call Jitting functions. Having said that, there are times it would be nice to control Jitting and have an alternative to NGen. Use this tool only if you have a performance issue, or a startup timing issue. If you do not have a performance issue - do not use this. This class also uses reflection to find out the methods to Jit. Reflection is slow, which is another reason to avoid using this class unless required. You should consider trying pre-jitting your classes when you are using generated code classes, such as typed dataset, LINQ to entities, or winform UI classes.

Even if you are not planning to use the Jitter class, it is better to have the Jitter class and not need it, then need it and not have it.

Thank you for reading. Have a nice day, and happy .Netting.

Download JitHelper - 91.23 KB

SDF (Compact sql database) with .NET 3.5SP1 Buggy with Entity Framework

2009-01-28T14:42:00.001-08:00

I just can't believe Microsoft will ship this technology with such major bugs within it. If you are looking into SDF files with support of entity framework, you might want to look into the major bugs they are having. For example, you will not be able to use a string variable in a compare operation with a LINQ statement. Sounds basic, but still it does not work. Look at the blob on this bug

http://social.msdn.microsoft.com/forums/en-US/sqlce/thread/b6bac277-cf66-4c74-a0b3-e48abedbd161/

I wonder if Microsoft forgot to unit-test this stuff before shipping.

How to find an avaiable TCP port

2009-01-08T05:15:00.000-08:00

This simple method will return the next avaiable TCP port

      private static int GetAvaiablePort()
      {
         IPEndPoint endPoint = new IPEndPoint(IPAddress.Any, 0);
         using (Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp))
         {
            socket.Bind(endPoint);
            IPEndPoint local = (IPEndPoint)socket.LocalEndPoint;
            return local.Port;
         }
      }

DM-V-VM

2008-12-30T11:03:00.000-08:00

Links for DataModel View ViewModel Pattern

https://blogs.msdn.com/dancre/archive/tags/DM-V-VM/default.aspx

http://www.nikhilk.net/Entry.aspx?id=198

http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx

ICommand for Silverlight with Attached Behaviors

http://www.codeproject.com/KB/WPF/AttachedBehaviors.aspx

Understanding SynchronizationContext Part III

2008-12-29T14:19:00.000-08:00

Download STASyncSolution.zip - 55.28 KB

Introduction

This article is the last part of the 3 part series on SynchronizationContext, SynchronizationContext is a class introduced by .NET 2.0 with little documentation or explanation of how to use it. I have tried to explain in part one how to use this class, and in part two how to create your own SynchronizationContext. In part two, I have showed how to build a SynchronizationContext that will marshal code from any .NET thread into a STA thread. I have done this so I can execute COM code that needs to run on the STA thread. The next step is to create a WCF service that will execute all its service operations on the STA thread (using the SynchronizationContext I provided in part II). In this article, I will show you how to configure WCF to provide a custom STA SynchronizationContext so each method on a WCF service will execute on the same STA thread. This will allow me to provide a simple programming model, that will be fully compatible with COM and I will not need to worry about thread safety because all my code will run within the same thread.

WCF - The Power

I will not even try to give a full explanation of WCF here, WCF is vast in functionality and does much more then just "remoting" or web services. I am starting to believe that WCF should be treated as a runtime rather then a communication framework. WCF provides us "out of the box" the following programming models:

built-in support for error handling

built-in support for concurrency

built-in support for security

built-in support for transaction

built-in support for data encryption

built-in support for durable services

built-in support for method interception and inspection (AOP)

built-in support for one way communication, and callbacks

and much more...

Just listen to this arcast, where Juval Lowy believes every class should be a WCF class. http://channel9.msdn.com/shows/ARCast+with+Ron+Jacobs/ARCastTV-Every-Class-a-WCF-Service-with-Juval-Lowy/ At first, I said to myself, this is too much, every class to be a WCF class is just insane. But the more I looked at WCF and what it had to offer, the more it made sense to me. WCF is a very extensible framework, allowing the developer to do a lot of custom configuration. For example providing a SynchronizationContext for your service is something you will not be able to do within native .NET classes, but only in WCF (and that's just one feature among many). Although I must say I did not go as far as making each class a WCF class, I have decided to make each component a WCF service, even if I don't plan to run my component remotly, I still believe the benefits of the WCF runtime are worth coding my components as WCF services. Bottom line, WCF is more then web services or remoting services, it provides a solid programming model that apply in every type of development. If you don't know WCF, I strongly recommend you learn it, it is by far one of the better frameworks Micrsooft have released. For this article, I assume you have basic knowledge of WCF services.

A simple WCF Service

Let me just say this right away, I have coded a WCF service for this article just for testing. I do not recommend you code services the way that I have. To be more specific, in my code the service implementation and the service contact are within the same assembly - this is not recommended. However, because I am dealing with testing my SynchronizationContext within a prototype/testing project, I wanted to keep the number of assemblies and code to a minimum. Normally, when I code a WCF service I have 3 projects.

Project containing the service contact (interface) and possibly any data contacts (DTOs)

Project containing the service implementation

Project hosting the service (optional)

So please no bashing, I am stating it here that the code is just for testing and not for production, now that we got it out of the way, let me show the service contact and implementation

[ServiceContract]
public interface IStaService
{
  [OperationContract]
  string DoWorkOnSTAThread(string state);
}

There is really not much to say about this service, it is very simple. Let me show you the implementation of this service

public class StaService : IStaService
{
  public string DoWorkOnSTAThread(string state)
  {
     ApartmentState aptState = Thread.CurrentThread.GetApartmentState();
     if (aptState == ApartmentState.STA)
        Trace.WriteLine("Using STA thread");

     int id = Thread.CurrentThread.ManagedThreadId;
     Trace.WriteLine("WCF current thread: " + id);
     return "processed by " + aptState.ToString() + " Thread id: " + id.ToString();
  }
}

Notes:

DoWorkOnSTAThread will be the method I plan to execute on the STA thread, so I coded some tracking code to make sure I am running this method on the STA thread. I check the ApartmentState and make sure it is an ApartmentState.STA

I also log the thread ID, considering I want all my code to run on the same STA thread, the ID should always be the same

However I did not write any code to indicate using the STA Sync Context, so for now, STA thread marshaling is not used

Testing our service

We will be running our service a few times, so lets learn how to test it. My service is hosted using webdev, and it is running as a web service. To test it, I have used the WCF test client applicaiton.It can normally be found at "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\WcfTestClient.exe" by calling DoWorkOnSTAThread multiple times, I get the following output

Output window:

WCF current thread: 12
WCF current thread: 12
WCF current thread: 11
WCF current thread: 11
WCF current thread: 11
WCF current thread: 13
WCF current thread: 10
WCF current thread: 11
WCF current thread: 10
WCF current thread: 10
WCF current thread: 13

To find out the service behavior, you can view the ServiceDescription within a custom ServiceHost (I will show the custom service host code later in the article)

Notice that I am running the same method on multiple threads. This is because by default WCF created my service using PerSession InstanceContextMode and ConcurrencyMode of Single (see image above). This means that the method will be executed one at the time, but each time it is executed by a thread assigned by the thread pool. First, you should avoid using PerSession for your services, PerSession simply does not scale, I consider it evil for coding scalable services, so, I am going to change the service behavior

[ServiceBehavior(UseSynchronizationContext=true, ConcurrencyMode=ConcurrencyMode.Multiple,
  InstanceContextMode=InstanceContextMode.PerCall)]
public class StaService : IStaService
{
  public string DoWorkOnSTAThread(string state)
  {
     ApartmentState aptState = Thread.CurrentThread.GetApartmentState();
     if (aptState == ApartmentState.STA)
        Trace.WriteLine("Using STA thread");

     int id = Thread.CurrentThread.ManagedThreadId;
     Trace.WriteLine("WCF current thread: " + id);
     //throw new Exception("boom");
     return "processed by " + aptState.ToString() + " Thread id: " + id.ToString();
  }
}

Using the WCF service behavior attribute [ServiceBehavior(UseSynchronizationContext=true, ConcurrencyMode=ConcurrencyMode.Multiple, InstanceContextMode=InstanceContextMode.PerCall)] I ask WCF to create this service using InstanceContextMode.PerCall, this means every method call will create an instance of the service, and as soon as the method completes the instance is destroyed. Using ConcurrencyMode.Multiple allows for clients to execute methods within this service concurrently, allowing multiple threads to execute the same method at the same time. UseSynchronizationContext=true means that I ask the service to use the SynchronizationContext attached to the host's thread. Using this new service behavior, lets see our output by executing the method 3 times:

WCF current thread: 12
WCF current thread: 9
WCF current thread: 6

Same results more or less... Our service can scale better, but still have no control on which thread the code is executed on.

Providing your service a SynchronizationContext

You noticed that no matter if the service is using single or multiple concurrency mode, in both the invocation is controlled by WCF using different threads from the thread pool. In order to provide your own SynchronizationContext you have two choices:

Set the SynchronizationContext on the hosting thread before opening the host

Create your own ServiceBehavior and override the SynchronizationContext on the service endpoint

I will explore the second option simply because we don't always create our own hosting program and in many cases the hosting is done in WAS or IIS. Let me show you the ServiceBehvior attribute I created to use STA thread synchronization.

public class StaServiceBehaviorAttribute : Attribute, IContractBehavior, IServiceBehavior
{
  StaSynchronizationContext mStaContext;
  public StaServiceBehaviorAttribute()
  {
     mStaContext = new StaSynchronizationContext();
  }
  #region IContractBehavior Members

  void IContractBehavior.AddBindingParameters(ContractDescription contractDescription, 
    ServiceEndpoint endpoint, 
    System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
  {

  }

  void IContractBehavior.ApplyClientBehavior(ContractDescription contractDescription,
    ServiceEndpoint endpoint, 
    System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)
  {

  }

  void IContractBehavior.ApplyDispatchBehavior(ContractDescription contractDescription,
    ServiceEndpoint endpoint,
    System.ServiceModel.Dispatcher.DispatchRuntime dispatchRuntime)
  {
     dispatchRuntime.SynchronizationContext = mStaContext;
  }

  void IContractBehavior.Validate(ContractDescription contractDescription, 
    ServiceEndpoint endpoint)
  {

  }

  #endregion

  #region IServiceBehavior Members

  void IServiceBehavior.AddBindingParameters(ServiceDescription serviceDescription,
    System.ServiceModel.ServiceHostBase serviceHostBase,
    System.Collections.ObjectModel.Collection endpoints,
    System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
  {

  }

  void IServiceBehavior.ApplyDispatchBehavior(ServiceDescription serviceDescription, 
    System.ServiceModel.
    ServiceHostBase serviceHostBase)
  {

  }

  void IServiceBehavior.Validate(ServiceDescription serviceDescription, 
    System.ServiceModel.ServiceHostBase serviceHostBase)
  {
     serviceHostBase.Closed += delegate
     {
        mStaContext.Dispose();
     };
  }

  #endregion
}

By creating my own custom ServiceBehvior attribute I can set certain settings that are otherwise not available to me.

Notice that I am creating the StaSynchronizationContext at the constructor

public StaServiceBehaviorAttribute()
{
    mStaContext = new StaSynchronizationContext();
}

The other most important part is implementing the ApplydispatchBehvior method. This method will be executed once on each endpoint within your service. It allows me to override the default SynchronizationContext with my own custom one.

void IContractBehavior.ApplyDispatchBehavior(ContractDescription contractDescription,
    ServiceEndpoint endpoint,
    System.ServiceModel.Dispatcher.DispatchRuntime dispatchRuntime)
{
    dispatchRuntime.SynchronizationContext = mStaContext;
}

To make sure my STA thread ends correctly, I have also modified the IServiceBehavior.Validate and provided an event handler for closing the host

void IServiceBehavior.Validate(ServiceDescription serviceDescription,
     System.ServiceModel.ServiceHostBase serviceHostBase)
{
 serviceHostBase.Closed += delegate
 {
    mStaContext.Dispose();
 };
}

Using the STA Synchronization Context

Let's take another look at our service, now that we have created own ServiceBehavior to apply a custom Synchronization Context

[StaServiceBehaviorAttribute]
[ServiceBehavior(UseSynchronizationContext=true, ConcurrencyMode=ConcurrencyMode.Multiple,
  InstanceContextMode=InstanceContextMode.PerCall)]
public class StaService : IStaService
{
  public string DoWorkOnSTAThread(string state)
  {
     ApartmentState aptState = Thread.CurrentThread.GetApartmentState();
     if (aptState == ApartmentState.STA)
        Trace.WriteLine("Using STA thread");

     int id = Thread.CurrentThread.ManagedThreadId;
     Trace.WriteLine("WCF current thread: " + id);
     //throw new Exception("boom");
     return "processed by " + aptState.ToString() + " Thread id: " + id.ToString();
  }
}

Notice that I kept the WCF service behavior to use PerCall and ConcurrentcyMode.Multiple. Considering we are planning to marshal our code to one STA thread, using ConcurrencyMode.Single will have the same behavior as ConcurrencyMode.Multiple

Notice I have placed my StaServiceBehaiorAttribue on the service, this will create the STA thread, and apply a STA synchronization context on all the endpoints my service exposes (in the example I only have one endpoint)

Very well, lets try it, but using the WCF client tool, I have send multiple request to my service and here are the results

Using STA thread
WCF current thread: 9
Using STA thread
WCF current thread: 9
Using STA thread
WCF current thread: 9
Using STA thread
WCF current thread: 9
Using STA thread
WCF current thread: 9
Using STA thread
WCF current thread: 9
Using STA thread
WCF current thread: 9
Using STA thread
WCF current thread: 9

Notice that all the calls to the WCF method are executed on thread 9

Notice that thread 9 is a STA thread as we expected

Now I am able to control on which thread the WCF service is executing on.

A word about hosting

Notice that using this method you can control the synchronization context of your service no matter what hosting method you choose. If you are hosting using a console application, you could set the synchronization context to STA (using the SynchronizationContext.SetSynchronizationContext) before opening the host, it will have the same effect.I tried to use a custom ServiceHostFactory and set the synchronization context there, but it did not work. Let me show you the custom ServiceHostFactory and the custom ServiceHost.

public class StaCustomHostFactory : ServiceHostFactory
   {
      protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
      {
         return new StaCustomHost(serviceType, baseAddresses);
      }
   }

public class StaCustomHost : ServiceHost
   {
      public StaCustomHost(Type serviceType, params Uri[] baseAddresses) :
         base(serviceType, baseAddresses)
      {

      }

      protected override void InitializeRuntime()
      {
         int id = Thread.CurrentThread.ManagedThreadId;
         base.InitializeRuntime();
      }

      protected override void ApplyConfiguration()
      {
         int id = Thread.CurrentThread.ManagedThreadId;
         // get the configuration from the app.config first
         base.ApplyConfiguration();

         // create the STA Thread Sync object and attach it to this hosting
         // thread.
         StaSynchronizationContext staContext = new StaSynchronizationContext();
         SynchronizationContext.SetSynchronizationContext(staContext);
      }
   }

<%@ ServiceHost 
    Language="C#" Debug="true" 
    Factory="StaServiceHost.StaCustomHostFactory" 
    Service="TestStaService.StaService" 
    CodeBehind="StaService.svc.cs" %>

Notice I set the SynchronizationContext within the ApplyConfiguration method. WCF will take whatever SynchronizationContext is set on the host's thread and use it for each invocation. However it did not work at all. I don't know exactly why, but the only explanation I can come up with is that the code within ApplyConfiguration does not run within the same thread as the ServiceHost.Open. Considering that the host is opened by webdev or IIS, I really don't know how to set the synchronization context on these threads. Therefore, I recommend you stick to using custom service behavior as I have shown before for overriding the synchronization context of your service's endpoints.

One little comment about closing the host, as you seen in part II, the STA thread is created as soon as the STA SynchronizationContext object is created. In this case it is created within the service behavior. It is important that this thread ends when the host closes. That's the reason I have coded this event handler:

void IServiceBehavior.Validate(ServiceDescription serviceDescription,
    System.ServiceModel.ServiceHostBase serviceHostBase)
{
 serviceHostBase.Closed += delegate
 {
    mStaContext.Dispose();
 };
}

I have tested this code by stopping the webdev process and placing a break-point on the event handler. I validated that the STA thread is exiting when webdev is closing. Thanks for small WCF miracles.

Is WCF using Send or Post?

You might be wondering if the Send or the Post of our sync-context is used. I really didn't know, so I set a breakpoint on both the Send and Post methods, and found out that WCF always uses the Post method. I have changed the service concurency-mode to ConcurrencyMode.Single and still Post was used. So using Single or Multiple concurency, in both cases the Post method is used to marshal code into the STA thread. What about exceptions? Notice I have modified my service to throw an exception:

   [StaServiceBehaviorAttribute]
   [ServiceBehavior(UseSynchronizationContext=true, ConcurrencyMode=ConcurrencyMode.Multiple,
      InstanceContextMode=InstanceContextMode.PerCall)]
   public class StaService : IStaService
   {
      public string DoWorkOnSTAThread(string state)
      {
         ApartmentState aptState = Thread.CurrentThread.GetApartmentState();
         if (aptState == ApartmentState.STA)
            Trace.WriteLine("Using STA thread");

         int id = Thread.CurrentThread.ManagedThreadId;
         Trace.WriteLine("WCF current thread: " + id);
         throw new Exception("boom");
         //return "processed by " + aptState.ToString() + " Thread id: " + id.ToString();
      }
   }

Initially, I believed that this might cause the STA thread to terminate, it is an unhandled exception running on the STA thread, but WCF does handle the exception for you. So the STA thread does not end even if you throw exceptions within the STA thread. WCF catches any unhanlded exception and converts them to FaultException on the client thread. This saves our STA thread from ending, so it keeps running regardless if exceptions are thrown. Thank god for another WCF miracle.

Conclusion

In this article I got into the inner working of WCF and grabbed control on "where" a service method is executed on. I am able to "tell" WCF to marshal all the method calls on a STA thread, allowing us not to worry about calling COM objects that are designed to work on the STA thread. This will also allow you to pop UI within your service method, but I really don't recommend it. By marshaling the code yourself, you can add additional logic to log and validate each invocation. You might even add security at this level and refuse marshaling a call if it does not fit a certain criteria. However, do not use this as a wild card, service side method interception can also do the same thing. Still, now that you know about this feature, you might find a good use for it within your projects.

Thank you for reading and happy dot netting.

Download STASyncSolution.zip - 55.28 KB

Understanding SynchronizationContext Part II

2008-12-25T19:10:00.000-08:00

Introduction

In part one I explained the role of SynchronizationContext within the .NET framework 2.0. It is mostly used to allow threads to communicate with the UI thread. We have learned in part one that the SynchronizationContext by itself does nothing to marshal code between threads, in fact this class should of been an abstract class. The .NET framework provided us a version of this class to marshal code into the UI thread, but what about coding your own version of SynchronizationContext to do somthing else. Sounds like a daunting task, but it is really not that bad. I will try to show you in this article how to code your own SynchronizationContext for marshaing code from any thread into a STA thread. In part III of the series I will leverage this class within the WCF framework. But before we start running, we must learn to walk. So lets start.

switching work into an STA threads

You might be wondering why I am coding this in the first place. STA is a threading model that is used by COM. Long long time ago, before the age of .NET remoting and WCF (sounds like hundred years ago). Developers coded COM classes that can only run on Single Apartment Threads. Why? because the COM runtime would handle thread marshaling for the developer and always made sure that your COM class would execute on the same thread. This way, the COM developer did not need to worry about multi-threading, Mutexes, Semaphores, Events and all the other multi-threading toys out there. Just for the record, COM also provided a Multi Apartment Threading model, for the brave ones. With MTA, the developer had to worry about multi-threading issues but had more control. There is a lot of documentation out there about MTA and STA, all you have to do is google "STA MTA" and read all the history about it. Thank god I don't need to code COM anymore. However, there is a lot of COM out there, and within our company a lot of business logic was coded into COM classes that can only execute on an STA thread. To be able to call these classes from any thread in .NET, I decided to code a custom STA thread synchronization context. After all the sweat and work put into it, it felt right to share it with you, hoping some poor developer out there might find it useful. Although, this article explains how to marshal code into an STA thread, you can take the information in this article and have your own sync context do something else.

How do we switch between two threads?

The first question is how would we manage marshaling between two running threads. This problem is typically solved by implementing some sort of a common communication block that both threads can read and write from. An ideal communication object between two threads is a queue.

A queue provides us the ability to send work from one thread to another based on the invocation order. This is the typical Consumer / Provider model, where one thread plays the role of a consumer (reading from the queue), and another thread plays the role of a provider (writing items to the queue). To simplify things, lets see how this might work:

Thread 1: Sends a message to a common queue

Thread 2: Listens for incoming messages from the common queue

In our case Thread 2 will be an STA thread.

A closer look at the blocking queue

I wanted to have a queue to queue up work items from thread X to my STA thread. I also wanted my thread to dequeue items only when there are items in the queue. If there are no items, I want the dequeue method to wait until something pops into the queue. Typically, this is called a "Blocking Queue". Lets see the code:

internal interface IQueueReader : IDisposable
{
  T Dequeue();
  void ReleaseReader();
}

internal interface IQueueWriter : IDisposable
{
  void Enqueue(T data);
}


internal class BlockingQueue : IQueueReader, IQueueWriter, IDisposable
{
  // use a .NET queue to store the data
  private Queue mQueue = new Queue();
  // create a semaphore that contains the items in the queue as resources.
  // initialize the semaphore to zero available resources (empty queue).
  private Semaphore mSemaphore = new Semaphore(0, int.MaxValue);
  // a event that gets triggered when the reader thread is exiting
  private ManualResetEvent mKillThread = new ManualResetEvent(false);
  // wait handles that are used to unblock a Dequeue operation. Either when there is an item in the queue
  // or when the reader thread is exiting.
  private WaitHandle[] mWaitHandles;

  public BlockingQueue()
  {
    mWaitHandles = new WaitHandle[2] { mSemaphore, mKillThread };
  }
  public void Enqueue(T data)
  {
    lock (mQueue) mQueue.Enqueue(data);
    // add an available resource to the semaphore, because we just put an item
    // into the queue.
    mSemaphore.Release();
  }

  public T Dequeue()
  {
    // wait until there is an item in the queue
    WaitHandle.WaitAny(mWaitHandles);
    lock (mQueue)
    {
      if (mQueue.Count > 0)
         return mQueue.Dequeue();
    }
    return default(T);
  }

  public void ReleaseReader()
  {
    mKillThread.Set();
  }


  void IDisposable.Dispose()
  {
    if (mSemaphore != null)
    {
      mSemaphore.Close();
      mQueue.Clear();
      mSemaphore = null;
    }
  }
}

Because this queue is used by multiple threads, notice that I am blocking access to the queue using the lock statement.

Normally I block the Dequeue method until there is an item in the queue. The way this works is by having a semaphore that represents all the items in the queue as resources. When the semaphore is created for the first time, the queue is empty and therefore there are no resources available, so calling Dequeue will block. (notice there is zero at the first argument indicating no available resources and a large number for the second argument representing the size of the queue.
private Semaphore mSemaphore = new Semaphore(0, int.MaxValue);

Notice that when I dequeue an item, I block on an array of WaitHandles (WaitHandle.WaitAny(mWaitHandles);). This code means "Wait until there is a message, or until the read thread is marked to stop running."

I have not shown yet the actual thread, I will show it next. However, the STA thread will be the reading thread, spending most of his time waiting for a message on the queue or processing a message from the queue.

Notice that when a message is enqueued into the queue, it releases the semaphore, indicating that a resource is available, this will cause the dequeue method to unblock.

The semaphore has a max limit of Int.Max, we should never reach anything close to this limit as long as the thread is dequing more of less as fast as it is enqueuing.

The SendOrPostCallbackItem class

Notice that the blocking queue class is generic, this was done in case I decide to re-use it in another application (and you are free to use it for your needs as well). So what are we planning to put into this queue? Considering this queue is responsible to marshal code from one thread into another, the ideal item to queue is a delegate. Still, we need a little more then a delegate and not just a simple delegate but a SendOrPostCallback delegate.


internal enum ExecutionType
{
   Post,
   Send
}

internal class SendOrPostCallbackItem
{
   object mState;
   private ExecutionType mExeType;
   SendOrPostCallback mMethod;
   ManualResetEvent mAsyncWaitHandle = new ManualResetEvent(false);
   Exception mException = null;

   internal SendOrPostCallbackItem(SendOrPostCallback callback,
      object state, ExecutionType type)
   {
      mMethod = callback;
      mState = state;
      mExeType = type;
   }

   internal Exception Exception
   {
      get { return mException; }
   }

   internal bool ExecutedWithException
   {
      get { return mException != null; }
   }

   // this code must run ont the STA thread
   internal void Execute()
   {
      if (mExeType == ExecutionType.Send)
         Send();
      else
         Post();
   }

   // calling thread will block until mAsyncWaitHandle is set
   internal void Send()
   {
      try
      {
         // call the thread
         mMethod(mState);
      }
      catch (Exception e)
      {
         mException = e;
      }
      finally
      {
         mAsyncWaitHandle.Set();
      }
   }

   /// 
   /// Unhandled exceptions will terminate the STA thread
   /// 

   internal void Post()
   {
      mMethod(mState);
   }

   internal WaitHandle ExecutionCompleteWaitHandle
   {
      get { return mAsyncWaitHandle; }
   }
}

SendOrPostCallbackItem contains the delegate we wish to execute on the STA thread.

The Send and Post are really helper methods, they are both responsible for launching the code, and they both designed to be called from the STA thread. However, because the Send is required to block, and to report exceptions back to the calling thread (non-sta thread),I use a ManualResentEvent to single when the execution is complete. I also keep track of the exception, if there is one it will be thrown on the non-sta thread (producer thread)

Post is simple, it just calls the method, no need to notify when it is done and there is no need to track the exception either.

Overall, this class is responsible for two main tasks. Storing the delegate to execute, and executing it in two possible modes. Send and Post, Send requires additional tracking (such as the exception and notification of complication), post just executes the method without doing anything else. Normally, if Post is executed on the STA thread, any exceptions reported by the delegate will cause the thread to end. I will explain this more in part III of the article when I introduce WCF into the mix. But for now, just keep this issue in mind

The STA thread and all its glory

Finally we can show and explain the meat and potatoes of this sync context. Now that we have a queue, and we know what we are planning to push into it, lets look at the STA thread (the thread responsible for marshaling code).


internal class StaThread
{
   private Thread mStaThread;
   private IQueueReader mQueueConsumer;

   private ManualResetEvent mStopEvent = new ManualResetEvent(false);


   internal StaThread(IQueueReader reader)
   {
      mQueueConsumer = reader;
      mStaThread = new Thread(Run);
      mStaThread.Name = "STA Worker Thread";
      mStaThread.SetApartmentState(ApartmentState.STA);
   }

   internal void Start()
   {
      mStaThread.Start();
   }


   internal void Join()
   {
      mStaThread.Join();
   }

   private void Run()
   {

      while (true)
      {
         bool stop = mStopEvent.WaitOne(0);
         if (stop)
         {
            break;
         }

        SendOrPostCallbackItem workItem = mQueueConsumer.Dequeue();
        if (workItem != null)
            workItem.Execute();
      }
   }

   internal void Stop()
   {
      mStopEvent.Set();
      mQueueConsumer.ReleaseReader();
      mStaThread.Join();
      mQueueConsumer.Dispose();

   }
}

One of the most important parts of this class is in the constructor, so lets take a look at it again


internal StaThread(IQueueReader reader)
{
   mQueueConsumer = reader;
   mStaThread = new Thread(Run);
   mStaThread.Name = "STA Worker Thread";
   mStaThread.SetApartmentState(ApartmentState.STA);
}

This class takes an interface of type IQueueReader, this is really our blocking queue. the reason I decided to put an interface here, is because this thread is a reading thread, and should not have access to writing methods

The thread is being setup as a STA thread, giving the thread a name helps when debugging using the thread output window.

Notice the thread is not started yet. A method called Start will start the thread, and this will happen within our StaSynchronizationContext class which I will show soon.

Lets take a look at the Run method. The run method represents our STA thread. Its main job is to dequeue items from our blocking queue and execute them. Executing any work items on the Run method means executing them on the STA thread. Therefore, it doesn't really matter which thread has placed them in the queue, what's important is that items are read within the STA thread, and executed in the STA thread. If you think about this, this is in fact thread marshalling in action.


private void Run()
{
   while (true)
   {
      bool stop = mStopEvent.WaitOne(0);
      if (stop)
      {
         break;
      }

     SendOrPostCallbackItem workItem = mQueueConsumer.Dequeue();
     if (workItem != null)
         workItem.Execute();
   }
}

I tried to keep the Run method as simple as possible, but lets stress out a few points.

The STA thread is running all the time, so I have made a while(true) loop. Normally, I am not a fan of this type of loop, but I wanted the reader of the code to understand, this thread is not suppose to go down unless the context class is disposed. A while(true) sends this type of message.

mStopEvent is a ManualResetEvent, it is signaled when the STA thread is marked to stop running. When the Stop() method is called, the mStopEvent is set, causing the main loop to exit. The Stop method also releases any waiting Dequeue operation by marking the queue to stop processing messages.
mQueueConsumer.Dequeue() is responsible for reading work items from the queue. This method will block until a work item is in the queue.

When a work-item is dequeued, the work-item is executed. Execute() if you remember will execute the code in the delegate associated with the work item. It is during this Execute method that the code is marshaled on the STA thread.

Creating the STA Synchronization Context class

We almost have all the pieces we need to have our STA Sync Context running. We got a work item that contains our delegate to execute on the STA thread. We got a nice little blocking queue to handle communication between the STA thread and any other thread. We even have our little STA Run method always looking at our queue, pumping messages out of it and running any work items that are fetched. The only thing we are missing now is the actual Synchronization Context class itself. So lets see it and go over the code in detail...

StaSynchronizationContext.cs


public class StaSynchronizationContext : SynchronizationContext, IDisposable
{
   private BlockingQueue mQueue;
   private StaThread mStaThread;
   public StaSynchronizationContext()
      : base()
   {
      mQueue = new BlockingQueue();
      mStaThread = new StaThread(mQueue);
      mStaThread.Start();
   }

   public override void Send(SendOrPostCallback d, object state)
   {
      // create an item for execution
      SendOrPostCallbackItem item = new SendOrPostCallbackItem(d, state, ExecutionType.Send);
      // queue the item
      mQueue.Enqueue(item);
      // wait for the item execution to end
      item.ExecutionCompleteWaitHandle.WaitOne();

      // if there was an exception, throw it on the caller thread, not the
      // sta thread.
      if (item.ExecutedWithException)
         throw item.Exception;
   }

   public override void Post(SendOrPostCallback d, object state)
   {
      // queue the item and don't wait for its execution. This is risky because
      // an unhandled exception will terminate the STA thread. Use with caution.
      SendOrPostCallbackItem item = new SendOrPostCallbackItem(d, state, ExecutionType.Post);
      mQueue.Enqueue(item);
   }

   public void Dispose()
   {
      mStaThread.Stop();

   }

   public override SynchronizationContext CreateCopy()
   {
      return this;
   }
}

This is really the class that uses all the other classes I have showed before. I have named it the StaSynchronizationContext because it is responsible to marshal code into an STA thread, allowing the caller to execute COM APIs that must be on an STA thread. Lets look a the Send API which is responsible for sending work on the STA thread. Notice this class inherits from SynchronizationContext, but overrides the default Send and Post methods.


public override void Send(SendOrPostCallback d, object state)
{
   // create an item for execution
   SendOrPostCallbackItem item = new SendOrPostCallbackItem(d, state, ExecutionType.Send);
   // queue the item
   mQueue.Enqueue(item);
   // wait for the item execution to end
   item.ExecutionCompleteWaitHandle.WaitOne();

   // if there was an exception, throw it on the caller thread, not the
   // sta thread.
   if (item.ExecutedWithException)
      throw item.Exception;
}

Notice that the send operation is a blocking operation, this means we block until the operation on the STA thread is complete. Remember we have placed a ManualReset event on the SendOrPostCallbackItem class, so we know when the execution is done. We are also trapping and caching any exceptions within SendOrPostCallbackItem so we can throw them on the calling thread and not on the STA thread. The Post on the other hand is not a waiting call, so all we do is queue the item and we are not waiting for the delegate execution to finish.

That's it, we now have a SynchronizationContext that will marshal code between any thread into a single STA thread. In my case, this will allow me to execute COM APIs within my STA thread, so COM classes can feel at home, as if they are running in VB6. To actually test this class, I have created a test program, here is the code


   public class Params
   {
      public string Output {get; set;}
      public int CallCounter { get; set; }
      public int OriginalThread { get; set; }
   }

   class Program
   {
      private static int mCount = 0;
      private static StaSynchronizationContext mStaSyncContext = null;
      static void Main(string[] args)
      {

         mStaSyncContext = new StaSynchronizationContext();
         for (int i = 0; i < 100; i++)
         {
            ThreadPool.QueueUserWorkItem(NonStaThread);

         }
         Console.WriteLine("Processing");
         Console.WriteLine("Press any key to dispose SyncContext");
         Console.ReadLine();
         mStaSyncContext.Dispose();
      }


      private static void NonStaThread(object state)
      {
         int id = Thread.CurrentThread.ManagedThreadId;

         for (int i = 0; i < 10; i++)
         {
            var param = new Params { OriginalThread = id, CallCounter = i };
            mStaSyncContext.Send(RunOnStaThread, param);
            Debug.Assert(param.Output == "Processed", "Unexpected behavior by STA thread");
         }
      }

      private static void RunOnStaThread(object state)
      {
         mCount++;
         Console.WriteLine(mCount);
         int id = Thread.CurrentThread.ManagedThreadId;
         var args = (Params)state;
         Trace.WriteLine("STA id " + id + " original thread " + args.OriginalThread + " call count " + args.CallCounter);
         args.Output = "Processed";

      }
   }

The test program will create a number of threads using the thread pool. These thread pool threads then use the StaSynchronizationContext to execute the code within the method RunOnStaThread. Running this test program, I have blasted the STA thread from 100 .NET threads, each thread marshaling the code RunOnStaThread 10 times. Notice that the STA thread ID will always be the same. Notice the results below, the STA thread is always 11, and calls are coming from multiple threads (I have shrunk the output)


STA id 11 original thread 7 call count 0
STA id 11 original thread 12 call count 0
STA id 11 original thread 7 call count 1
STA id 11 original thread 12 call count 1
STA id 11 original thread 7 call count 2
STA id 11 original thread 12 call count 2
STA id 11 original thread 7 call count 3
STA id 11 original thread 12 call count 3
STA id 11 original thread 7 call count 4
STA id 11 original thread 12 call count 4
STA id 11 original thread 7 call count 5
STA id 11 original thread 12 call count 5
STA id 11 original thread 7 call count 6
STA id 11 original thread 12 call count 6
STA id 11 original thread 7 call count 7
STA id 11 original thread 12 call count 7
STA id 11 original thread 7 call count 8
STA id 11 original thread 12 call count 8
STA id 11 original thread 7 call count 9
STA id 11 original thread 12 call count 9
STA id 11 original thread 7 call count 0
STA id 11 original thread 12 call count 0
STA id 11 original thread 7 call count 1
STA id 11 original thread 12 call count 1
STA id 11 original thread 7 call count 2
STA id 11 original thread 12 call count 2
STA id 11 original thread 7 call count 3
STA id 11 original thread 12 call count 3
STA id 11 original thread 7 call count 4
STA id 11 original thread 12 call count 4
STA id 11 original thread 7 call count 5
STA id 11 original thread 12 call count 5
STA id 11 original thread 7 call count 6
STA id 11 original thread 12 call count 6
STA id 11 original thread 7 call count 7
STA id 11 original thread 12 call count 7
STA id 11 original thread 7 call count 8
STA id 11 original thread 12 call count 8
STA id 11 original thread 7 call count 9
STA id 11 original thread 12 call count 9
STA id 11 original thread 7 call count 0
STA id 11 original thread 12 call count 0
STA id 11 original thread 7 call count 1
STA id 11 original thread 12 call count 1
STA id 11 original thread 7 call count 2
STA id 11 original thread 12 call count 2
STA id 11 original thread 7 call count 3
STA id 11 original thread 12 call count 3
STA id 11 original thread 7 call count 4
STA id 11 original thread 12 call count 4
STA id 11 original thread 7 call count 5
STA id 11 original thread 12 call count 5
STA id 11 original thread 7 call count 6
STA id 11 original thread 12 call count 6

Wait a minute, I can do the same thing without using a SynchronizationContext, so why bother?

True, there is really no need to build a synchronization context to marshal code into another thread. I could of just used my queue and the STA thread to do all the work directly within my code. Its nice that I am playing by the rules of .NET and I provide my own implementation, so others can use it, but really it is not required. So why bother? The reason is because of WCF. WCF allows you to provide a SynchronizationContext for the execution of operations within a service. This is a very powerful feature of WCF that is normally used to marshal WCF service calls into the UI thread. However, in my case, because I played nice and I created a SynchronizationContext class and not just any class, I can now tell WCF to execute all my service methods on an STA thread. This was the main reason for writing the series on this class.

Conclusion

This article shows that you can create your own version of a SynchronizationContext class. I have showed that a Blocking Queue is a good candidate for communication between threads. We successfuly marshalled code from any thread into a single STA thread. Now that we have our Synchronization Context class, we can put it to work within a WCF service. This will be the main focus on the 3ed part of the series. Once you understand how to build your own Synchronization Context and apply it to a WCF service, you are in control of "where" your code is running when a WCF method is executed - a very powerful feature within a very powerful WCF framework.

For those of you that want the code. I will provide a full VS2008 solution within the 3ed part of the articles

Understanding SyncrhronizationContext

2008-12-21T21:26:00.000-08:00

SynchronizationContext - MSDN lets you down

I don't know why, but there is really not much information about this new class within the .NET framework. The MSDN documentation contains very little information on how to use SynchronizationContext. Initially, I must say that I had a hard time understanding the reason for this new class and how to use it. After reading a lot on the subject, I finally understood the purpose of this class and how it should be used. I decided to write this article to help other developers understand how to use this class, and what it can and can not do for you. (MSDN)

Using SyncrhronizationContext to Marshal Code from One Thread to Another

Let's get some technical points out of the way so we can show how to use this class. A SyncrhronizationContext allows a thread to communicate with another thread. Suppose you have two threads, Thread1 and Thread2. Say, Thread1 is doing some work, and then Thread1 wishes to execute code on Thread2. One possible way to do it is to ask Thread2 for its SyncrhronizationContext object, give it to Thread1, and then Thread1 can call SyncrhronizationContext.Send to execute the code on Thread2. Sounds like magic... Well, there is a something you should know. Not every thread has a SyncrhronizationContext attached to it. One thread that always has a SyncrhronizationContext is the UI thread.

Who puts the SyncrhronizationContext into the UI thread? Any guesses? Give up? OK, here it is, the first control that is created on the thread places the SyncrhronizationContext into that thread. Normally, it is the first form that gets created. How do I know? Well, I tried it out.

Because my code uses SynchronizationContext.Current, let me explain what this static property gives us. SynchronizationContext.Current allows us to get a SynchronizationContext that is attached to the current thread. Let's be clear here, SynchronizationContext.Current is not a singleton per AppDomain, but per thread. This means that two threads can have different instances of SynchronizationContext when calling SynchronizationContext.Current. If you wonder where the actual context is stored, it is stored within the Thread data store (and as I said before, not in the global memory space of the appdomain).

OK, let's look at the code that places a SynchronizationContext within our UI thread.

[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
// lets check the context here
var context = SynchronizationContext.Current;
if (context == null)
MessageBox.Show("No context for this thread");
else
MessageBox.Show("We got a context");

// create a form
Form1 form = new Form1();
// lets check it again after creating a form
context = SynchronizationContext.Current;
if (context == null)
MessageBox.Show("No context for this thread");
else
MessageBox.Show("We got a context");

if (context == null)
MessageBox.Show("No context for this thread");

Application.Run(new Form1());
}

As you can see, there are a few points to note:

The first message box will indicate that there is no context attached to the thread. That's because .NET doesn't even know what is going to happen on this thread, and there is no runtime class that initializes the Sync Context for this thread.

Right after creating the form, notice that the context is set. The Form class is responsible for this. It checks if a Sync Context is present, and if it is not, it places it there. Remember that the context is always the same on the same thread, so any UI control can access it. This is because all UI operations must be running on the UI thread. To be more specific, the thread that creates the window is the thread that can communicate with the window. In our case, it is the main thread of the application.

How do I use it?

Now that the UI thread is nice enough to give us a Sync Context so we can "run code" under the UI thread, how do we use it?

First, do we really have to marshal code into the UI thread? Yes. If you are running on a thread other than the UI thread, you can not update the UI. Want to be a hero and try it? You will get an exception (in version 1.0, they didn't enforce the exception, it just crashed the application, but in version 2.0, there is a fat ugly exception that pops in your face).

To be fair, I will say that you don't have to use this class to sync into the UI thread. You can use the InvokeRequired property (which is on every UI control class) and see if you need to marshal your code. If you get a "true" out of InvokeRequired, then you have to use Control.Invoke to marshal the code to the UI thread. Great! Why keep reading? Well, there is an issue with this technique. You must have a Control in order to call Invoke on it. It doesn't matter which UI control, but you need at least one control reference available to you within your non-UI thread in order to do this type of thread marshalling. From a design prospective, you never want to have a UI reference within your BI layer. So, you can leave all sync operations on the UI class, and make sure the UI is responsible to marshal its own work (see my article on the MVP pattern). However, this puts more responsibility on the UI, and makes the UI smarter than we want it to be, I must say. It would be nice for the BI to have the ability to marshal code to the UI thread without having a reference to a control or a form.

So, how is it done?

Simple. Create a thread, sent it the sync context, and have this thread use the sync object to marshal code into the UI thread. Let's see an example:

In the following example, I have a list box that is populated from a worker thread. The thread simulates a computation and then writes to the UI list box. The thread used to update the UI is launched from the mToolStripButtonThreads_Click event handler.

First, let's see what's on the form:

 private void InitializeComponent()
{
System.ComponentModel.ComponentResourceManager resources =
new System.ComponentModel.ComponentResourceManager(typeof(Form1));
this.mListBox = new System.Windows.Forms.ListBox();
this.toolStrip1 = new System.Windows.Forms.ToolStrip();
this.mToolStripButtonThreads = new System.Windows.Forms.ToolStripButton();
this.toolStrip1.SuspendLayout();
this.SuspendLayout();
//
// mListBox
//
this.mListBox.Dock = System.Windows.Forms.DockStyle.Fill;
this.mListBox.FormattingEnabled = true;
this.mListBox.Location = new System.Drawing.Point(0, 0);
this.mListBox.Name = "mListBox";
this.mListBox.Size = new System.Drawing.Size(284, 264);
this.mListBox.TabIndex = 0;
//
// toolStrip1
//
this.toolStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] {
this.mToolStripButtonThreads});
this.toolStrip1.Location = new System.Drawing.Point(0, 0);
this.toolStrip1.Name = "toolStrip1";
this.toolStrip1.Size = new System.Drawing.Size(284, 25);
this.toolStrip1.TabIndex = 1;
this.toolStrip1.Text = "toolStrip1";
//
// mToolStripButtonThreads
//
this.mToolStripButtonThreads.DisplayStyle =
System.Windows.Forms.ToolStripItemDisplayStyle.Text;
this.mToolStripButtonThreads.Image = ((System.Drawing.Image)
(resources.GetObject("mToolStripButtonThreads.Image")));
this.mToolStripButtonThreads.ImageTransparentColor =
System.Drawing.Color.Magenta;
this.mToolStripButtonThreads.Name = "mToolStripButtonThreads";
this.mToolStripButtonThreads.Size = new System.Drawing.Size(148, 22);
this.mToolStripButtonThreads.Text = "Press Here to start threads";
this.mToolStripButtonThreads.Click +=
new System.EventHandler(this.mToolStripButtonThreads_Click);
//
// Form1
//
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
this.ClientSize = new System.Drawing.Size(284, 264);
this.Controls.Add(this.toolStrip1);
this.Controls.Add(this.mListBox);
this.Name = "Form1";
this.Text = "Form1";
this.toolStrip1.ResumeLayout(false);
this.toolStrip1.PerformLayout();
this.ResumeLayout(false);
this.PerformLayout();
}
#endregion
private System.Windows.Forms.ListBox mListBox;
private System.Windows.Forms.ToolStrip toolStrip1;
private System.Windows.Forms.ToolStripButton mToolStripButtonThreads;
}

Now, let's see the example:

public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void mToolStripButtonThreads_Click(object sender, EventArgs e)
{
// lets see the thread id
int id = Thread.CurrentThread.ManagedThreadId;
Trace.WriteLine("mToolStripButtonThreads_Click thread: " + id);
// grab the sync context associated to this
// thread (the UI thread), and save it in uiContext
// note that this context is set by the UI thread
// during Form creation (outside of your control)
// also note, that not every thread has a sync context attached to it.
SynchronizationContext uiContext = SynchronizationContext.Current;
// create a thread and associate it to the run method
Thread thread = new Thread(Run);
// start the thread, and pass it the UI context,
// so this thread will be able to update the ui
// from within the thread
thread.Start(uiContext);
}
private void Run(object state)
{
// lets see the thread id
int id = Thread.CurrentThread.ManagedThreadId;
Trace.WriteLine("Run thread: " + id);
// grab the context from the state
SynchronizationContext uiContext = state as SynchronizationContext;
for (int i = 0; i < 1000; i++)
{
// normally you would do some code here
// to grab items from the database. or some long
// computation
Thread.Sleep(10);
// use the ui context to execute the UpdateUI method,
// this insure that the UpdateUI method will run on the UI thread.
uiContext.Post(UpdateUI, "line " + i.ToString());
}
}
/// <summary>
/// This method is executed on the main UI thread.
/// </summary>
private void UpdateUI(object state)
{
int id = Thread.CurrentThread.ManagedThreadId;
Trace.WriteLine("UpdateUI thread:" + id);
string text = state as string;
mListBox.Items.Add(text);
}
}

Let's go over this code. Notice that I log the thread ID of each method so we can review it later.

For example:

// lets see the thread id
int id = Thread.CurrentThread.ManagedThreadId;
Trace.WriteLine("mToolStripButtonThreads_Click thread: " + id);

When pressing on the toolstrip button, a thread is launched with its delegate pointing to the Run method. However, notice that I am passing state to this thread. I am passing the Sync Context of the UI thread by calling SynchronizationContext uiContext = SynchronizationContext.Current;. Because I am running on the event handler thread of the toolstrip button, I know I am currently running on the UI thread, and by calling SynchronizationContext.Current, I will get the sync context for the UI thread.

Run will first grab the SynchronizationContext from its state, so it can have the knowledge of how to marshal code into the UI thread.

// grab the context from the state
SynchronizationContext uiContext = state as SynchronizationContext;

The Run thread writes 1000 lines into the list box. How? Well, first it uses the Send method on the SynchronizationContext:

public virtual void Send(SendOrPostCallback d, object state);

Calling SynchronizationContext.Send takes two arguments, a delegate pointing to a method and a state object. Within our example uiContext.Send(UpdateUI, "line " + i.ToString());, UpdateUI is the value we provide for the delegate, and state contains the string we want to add to the listbox. The code in UpdateUI is supposed to run on the UI thread, and not on the calling thread.

private void UpdateUI(object state)
{
int id = Thread.CurrentThread.ManagedThreadId;
Trace.WriteLine("UpdateUI thread:" + id);
string text = state as string;
mListBox.Items.Add(text);
}

Notice that this code directly runs on the UI thread. There is no checking for InvokerRequired because I know it is on the UI thread due to the fact that it was used with the Send method of the UI SynchronizationContext.

Let's look at the thread IDs and see if it makes sense:

mToolStripButtonThreads_Click thread: 10
Run thread: 3
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
UpdateUI thread:10
... (x1000 times)

This means that the UI thread is 10, the worker thread (Run) is 3, and when we update the UI, notice we are on thread ID 10 again (the UI thread). So, everything is working as advertised.

Error Handling

Very nice, we are able to marshal code into the UI thread, but what happens when the code we marshal throws an exception? Who is responsible to catch it? The UI thread or the worker thread?

private void Run(object state)
{
// lets see the thread id
int id = Thread.CurrentThread.ManagedThreadId;
Trace.WriteLine("Run thread: " + id);
// grab the context from the state
SynchronizationContext uiContext = state as SynchronizationContext;
for (int i = 0; i < 1000; i++)
{
Trace.WriteLine("Loop " + i.ToString());
// normally you would do some code here
// to grab items from the database. or some long
// computation
Thread.Sleep(10);
// use the ui context to execute the UpdateUI method, this insure that the
// UpdateUI method will run on the UI thread.
try
{
uiContext.Send(UpdateUI, "line " + i.ToString());
}
catch (Exception e)
{
Trace.WriteLine(e.Message);
}
}
}
/// <summary>
/// This method is executed on the main UI thread.
/// </summary>
private void UpdateUI(object state)
{
throw new Exception("Boom");
}

I modified the code so that the UpdateUI method throws an exception throw new Exception("Boom");. Also, I have modified the Run method to place a try/catch around the Send method.

try
{
uiContext.Send(UpdateUI, "line " + i.ToString());
}
catch (Exception e)
{
Trace.WriteLine(e.Message);
}

When running this code, I noticed that the exception is caught in the Run thread and not on the UI thread. This is interesting because you might expect the exception to bring down the UI thread, considering no class is catching the exception on the UI thread.

Therefore, the Send method is doing a little magic; it is executing our code in a blocking fashion, and it reports back any exception during its execution.

Send vs. Post

Using Send is only one of two possible methods you can use to marshal code on the UI thread. There is another method called Post. What's the difference? A lot!

Maybe it is time to see this class in more detail, so let's review the interface of SynchronizationContext:

// Summary:
// Provides the basic functionality for propagating a synchronization context
// in various synchronization models.
public class SynchronizationContext
{
// Summary:
// Creates a new instance of the System.Threading.SynchronizationContext class.
public SynchronizationContext();
// Summary:
// Gets the synchronization context for the current thread.
//
// Returns:
// A System.Threading.SynchronizationContext object representing the current
// synchronization context.
public static SynchronizationContext Current { get; }
// Summary:
// When overridden in a derived class, creates a copy of the synchronization
// context.
//
// Returns:
// A new System.Threading.SynchronizationContext object.
public virtual SynchronizationContext CreateCopy();
//
// Summary:
// Determines if wait notification is required.
//
// Returns:
// true if wait notification is required; otherwise, false.
public bool IsWaitNotificationRequired();
//
// Summary:
// When overridden in a derived class, responds to the notification that an
// operation has completed.
public virtual void OperationCompleted();
//
// Summary:
// When overridden in a derived class, responds to the notification that an
// operation has started.
public virtual void OperationStarted();
//
// Summary:
// When overridden in a derived class, dispatches an asynchronous message to
// a synchronization context.
//
// Parameters:
// d:
// The System.Threading.SendOrPostCallback delegate to call.
//
// state:
// The object passed to the delegate.
public virtual void Post(SendOrPostCallback d, object state);
//
// Summary:
// When overridden in a derived class, dispatches a synchronous message to a
// synchronization context.
//
// Parameters:
// d:
// The System.Threading.SendOrPostCallback delegate to call.
//
// state:
// The object passed to the delegate.
public virtual void Send(SendOrPostCallback d, object state);
//
// Summary:
// Sets the current synchronization context.
//
// Parameters:
// syncContext:
// The System.Threading.SynchronizationContext object to be set.
public static void SetSynchronizationContext(SynchronizationContext syncContext);
//
// Summary:
// Sets notification that wait notification is required and prepares the callback
// method so it can be called more reliably when a wait occurs.
protected void SetWaitNotificationRequired();
//
// Summary:
// Waits for any or all the elements in the specified array to receive a signal.
//
// Parameters:
// waitHandles:
// An array of type System.IntPtr that contains the native operating system
// handles.
//
// waitAll:
// true to wait for all handles; false to wait for any handle.
//
// millisecondsTimeout:
// The number of milliseconds to wait, or System.Threading.Timeout.Infinite
// (-1) to wait indefinitely.
//
// Returns:
// The array index of the object that satisfied the wait.
[PrePrepareMethod]
[CLSCompliant(false)]
public virtual int Wait(IntPtr[] waitHandles, bool waitAll, int millisecondsTimeout);
//
// Summary:
// Helper function that waits for any or all the elements in the specified array
// to receive a signal.
//
// Parameters:
// waitHandles:
// An array of type System.IntPtr that contains the native operating system
// handles.
//
// waitAll:
// true to wait for all handles; false to wait for any handle.
//
// millisecondsTimeout:
// The number of milliseconds to wait, or System.Threading.Timeout.Infinite
// (-1) to wait indefinitely.
//
// Returns:
// The array index of the object that satisfied the wait.
[ReliabilityContract(Consistency.WillNotCorruptState, Cer.MayFail)]
[PrePrepareMethod]
[CLSCompliant(false)]
protected static int WaitHelper(IntPtr[] waitHandles,
bool waitAll, int millisecondsTimeout);
}

Notice the comment for the Post method:

//
// Summary:
// When overridden in a derived class, dispatches an asynchronous message to
// a synchronization context.
//
// Parameters:
// d:
// The System.Threading.SendOrPostCallback delegate to call.
//
// state:
// The object passed to the delegate.
public virtual void Post(SendOrPostCallback d, object state);

The key word here is asynchronous. This means that Post will not wait for the execution of the delegate to complete. Post will "Fire and Forget" about the execution code within the delegate. It also means that you can not catch exceptions as we did with the Send method. Suppose an exception is thrown, it will be the UI thread that will get it; unhanding the exception will terminate the UI thread.

However, Post or Send, the execution of the delegate always runs on the correct thread. Just replace the code with Post instead of Send, and you will still get the right thread ID when executing on the UI thread.

So now, I can use SynchronizationContext to sync any thread I want, right? Nope!

At this point, you might try to use SynchronizationContext with any thread. However, you will soon find that your thread does not have a SynchronizationContext when using SynchronizationContext.Current, and it always returns null. No big deal you say, and you simply create a SynchronizationContext if there isn't one. Simple. But, it does not really work.

Let's look at a program similar to the one we used for the UI thread:

class Program
{
private static SynchronizationContext mT1 = null;
static void Main(string[] args)
{
// log the thread id
int id = Thread.CurrentThread.ManagedThreadId;
Console.WriteLine("Main thread is " + id);
// create a sync context for this thread
var context = new SynchronizationContext();
// set this context for this thread.
SynchronizationContext.SetSynchronizationContext(context);
// create a thread, and pass it the main sync context.
Thread t1 = new Thread(new ParameterizedThreadStart(Run1));
t1.Start(SynchronizationContext.Current);
Console.ReadLine();
}
static private void Run1(object state)
{
int id = Thread.CurrentThread.ManagedThreadId;
Console.WriteLine("Run1 Thread ID: " + id);
// grab the sync context that main has set
var context = state as SynchronizationContext;
// call the sync context of main, expecting
// the following code to run on the main thread
// but it will not.
context.Send(DoWork, null);
while (true)
Thread.Sleep(10000000);
}
static void DoWork(object state)
{
int id = Thread.CurrentThread.ManagedThreadId;
Console.WriteLine("DoWork Thread ID:" + id);
}
}

This simple console application is something you should not do at home. This program does not work, and it is done simply to prove a point. Notice I am setting a Sync Context on the main console thread. I am simply creating a new instance of the object. Then, I am setting it to my current thread. This is similar to what the UI thread does when a form is created (not really, but I will explain later). Then, I create a thread Run1, and pass it the context of the main thread. When I try to call Send, based on my trace, I notice Send was called on the Run1 thread and not on the main thread as we may expect. Here is the output:

Main thread is 10
Run1 Thread ID: 11
DoWork Thread ID:11

Notice that DoWork is executed on thread 11, the same thread as Run1. Not much of a SynchronizationContext into the main thread. Why? What's going on? Well... This is the part when you realize that nothing is for free in life. Threads can't just switch contexts between them, they must have an infrastructure built-in into them in order to do so. The UI thread, for example, uses a message pump, and within its SynchronizationContext, it leverages the message pump to sync into the UI thread.

So, the UI thread has it own SynchronizationContext class, but it is a class that derives from SynchronizationContext, and it is called System.Windows.Forms.WindowsFormsSynchronizationContext. Now, this class has a very different implementation from the simple plain vanilla SynchronizationContext. The UI version overrides the Post and Send methods, and provides a "message pump" version of these methods (I tried to get the source code of this class, but I didn't find it). So, what does the plain vanilla SynchronizationContext do?

Somehow, I was able to get the source code of SynchronizationContext, and here it is: found it here.

(I have removed the attributes, and did some minor formatting just to have the code fit in the page.)

namespace System.Threading
{
using Microsoft.Win32.SafeHandles;
using System.Security.Permissions;
using System.Runtime.InteropServices;
using System.Runtime.CompilerServices;
using System.Runtime.ConstrainedExecution;
using System.Reflection;

internal struct SynchronizationContextSwitcher : IDisposable
{
internal SynchronizationContext savedSC;
internal SynchronizationContext currSC;
internal ExecutionContext _ec;
public override bool Equals(Object obj)
{
if (obj == null !(obj is SynchronizationContextSwitcher))
return false;
SynchronizationContextSwitcher sw = (SynchronizationContextSwitcher)obj;
return (this.savedSC == sw.savedSC &&
this.currSC == sw.currSC && this._ec == sw._ec);
}
public override int GetHashCode()
{
return ToString().GetHashCode();
}
public static bool operator ==(SynchronizationContextSwitcher c1,
SynchronizationContextSwitcher c2)
{
return c1.Equals(c2);
}
public static bool operator !=(SynchronizationContextSwitcher c1,
SynchronizationContextSwitcher c2)
{
return !c1.Equals(c2);
}
void IDisposable.Dispose()
{
Undo();
}
internal bool UndoNoThrow()
{
if (_ec == null)
{
return true;
}
try
{
Undo();
}
catch
{
return false;
}
return true;
}
public void Undo()
{
if (_ec == null)
{
return;
}
ExecutionContext executionContext =
Thread.CurrentThread.GetExecutionContextNoCreate();
if (_ec != executionContext)
{
throw new InvalidOperationException(Environment.GetResourceString(
"InvalidOperation_SwitcherCtxMismatch"));
}
if (currSC != _ec.SynchronizationContext)
{
throw new InvalidOperationException(Environment.GetResourceString(
"InvalidOperation_SwitcherCtxMismatch"));
}
BCLDebug.Assert(executionContext != null, " ExecutionContext can't be null");
// restore the Saved Sync context as current
executionContext.SynchronizationContext = savedSC;
// can't reuse this anymore
_ec = null;
}
}

public delegate void SendOrPostCallback(Object state);
[Flags]
enum SynchronizationContextProperties
{
None = 0,
RequireWaitNotification = 0x1
};
public class SynchronizationContext
{
SynchronizationContextProperties _props = SynchronizationContextProperties.None;
public SynchronizationContext()
{
}

// protected so that only the derived sync
// context class can enable these flags
protected void SetWaitNotificationRequired()
{
// Prepare the method so that it can be called
// in a reliable fashion when a wait is needed.
// This will obviously only make the Wait reliable
// if the Wait method is itself reliable. The only thing
// preparing the method here does is to ensure there
// is no failure point before the method execution begins.
RuntimeHelpers.PrepareDelegate(new WaitDelegate(this.Wait));
_props = SynchronizationContextProperties.RequireWaitNotification;
}
public bool IsWaitNotificationRequired()
{
return ((_props &
SynchronizationContextProperties.RequireWaitNotification) != 0);
}
public virtual void Send(SendOrPostCallback d, Object state)
{
d(state);
}
public virtual void Post(SendOrPostCallback d, Object state)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(d), state);
}
public virtual void OperationStarted()
{
}
public virtual void OperationCompleted()
{
}
// Method called when the CLR does a wait operation
public virtual int Wait(IntPtr[] waitHandles,
bool waitAll, int millisecondsTimeout)
{
return WaitHelper(waitHandles, waitAll, millisecondsTimeout);
}
// Static helper to which the above method
// can delegate to in order to get the default
// COM behavior.
protected static extern int WaitHelper(IntPtr[] waitHandles,
bool waitAll, int millisecondsTimeout);
// set SynchronizationContext on the current thread
public static void SetSynchronizationContext(SynchronizationContext syncContext)
{
SetSynchronizationContext(syncContext,
Thread.CurrentThread.ExecutionContext.SynchronizationContext);
}
internal static SynchronizationContextSwitcher
SetSynchronizationContext(SynchronizationContext syncContext,
SynchronizationContext prevSyncContext)
{
// get current execution context
ExecutionContext ec = Thread.CurrentThread.ExecutionContext;
// create a swticher
SynchronizationContextSwitcher scsw = new SynchronizationContextSwitcher();
RuntimeHelpers.PrepareConstrainedRegions();
try
{
// attach the switcher to the exec context
scsw._ec = ec;
// save the current sync context using the passed in value
scsw.savedSC = prevSyncContext;
// save the new sync context also
scsw.currSC = syncContext;
// update the current sync context to the new context
ec.SynchronizationContext = syncContext;
}
catch
{
// Any exception means we just restore the old SyncCtx
scsw.UndoNoThrow(); //No exception will be thrown in this Undo()
throw;
}
// return switcher
return scsw;
}
// Get the current SynchronizationContext on the current thread
public static SynchronizationContext Current
{
get
{
ExecutionContext ec = Thread.CurrentThread.GetExecutionContextNoCreate();
if (ec != null)
return ec.SynchronizationContext;
return null;
}
}
// helper to Clone this SynchronizationContext,
public virtual SynchronizationContext CreateCopy()
{
// the CLR dummy has an empty clone function - no member data
return new SynchronizationContext();
}
private static int InvokeWaitMethodHelper(SynchronizationContext syncContext,
IntPtr[] waitHandles,
bool waitAll,
int millisecondsTimeout)
{
return syncContext.Wait(waitHandles, waitAll, millisecondsTimeout);
}
}
}

Look at the implementation of Send and Post...

public virtual void Send(SendOrPostCallback d, Object state)
{
d(state);
}
public virtual void Post(SendOrPostCallback d, Object state)
{
ThreadPool.QueueUserWorkItem(new WaitCallback(d), state);
}

Send simply calls the delegate on the calling thread (no thread switching of any kind), and Post does the same thing, but simply uses the ThreadPool to do it in an async fashion. In my opinion, this class should be abstract. The default implementation of this class is confusing and useless. It is one of two reasons I decided to write this article.

Conclusion

I hope you know more about this class now, and you understand how to use it. Within .NET, I found two classes that provide a custom synchronization. One for the WinForms thread context and one for WPF thread context. I am sure there are more, but these are the ones I found so far. The default implementation of the class, as I showed you, does nothing to switch code from one thread to another. This is simply because threads, by default, do not have this type of a mechanism. UI threads, on the other hand, have a message pump and an OS mechanism via Windows APIs such as SendMessage and PostMessage to communicate with this message pump. I am sure System.Windows.Forms.WindowsFormsSynchronizationContext is leveraging these windows API to perform marshalling into the UI thread.

However, this should not be the end of the road for this class. You can make your own SynchronizationContext, it is really simple. In fact, I had to write one. At my work, we needed to have all COM based calls executed on an STA thread. However, our application is using the thread pool and WCF, and it was not simple to just marshal code into an STA thread. Therefore, I decided to code my own version of SynchronizationContext called StaSynchronizationContext. I will show how I did it in part II of this article.

Happy .NETting.

Testing Concurrency with Nunit

2008-06-07T09:19:00.000-07:00

Nunit is really nice for unit testing. One thing I wanted to do in my unit test is simulate multiple users using the system. Normally it would be nice to have a set of tests for single user scenario. Once those tests pass, it is nice to be able to run them in a "multi-user" environment. I didn't really want to re-code my tests to simulate a multi-user environment, and I didn't really want to create complex threading system to do it.

So to solve the problem I used the .NET built-in thread pool, and I leverage the existing tests I have. Here is an example

Suppose we have 2 simple unit tests, one to test a customer request, and the other to test updating a customer record. The implementation is not needed for this sample.

      [TestFixture]

      public class TestCustmoerUserCase

      {

         [Test]

         public void TestProcessCustmerRequest()

         {

            // processing to handle a custmer request

         }



         [Test]

         public void TestUpdateCustomer()

         {

            // processing to update a custmer

         }

      }

Suppose I would like to test these two scenarios in a multi-user environment. Here is one possible solution:

      [TestFixture]

      public class TestCustmerUserCaseAsync

      {

         private delegate void AsyncDelegate();



         [Test]

         public void TestAsync()

         {

            TestCustmoerUserCase custTest = new TestCustmoerUserCase();



            // you can also run initalization code here, before starting the threads...



            AsyncDelegate asyncOperation = delegate

            {

               custTest.TestProcessCustmerRequest();

               custTest.TestUpdateCustomer();

            };



            Console.WriteLine("Running thread 1");

            IAsyncResult r1 = asyncOperation.BeginInvoke(null, null);

            Console.WriteLine("Running thread 2");

            IAsyncResult r2 = asyncOperation.BeginInvoke(null, null);

            Console.WriteLine("Running thread 3");

            IAsyncResult r3 = asyncOperation.BeginInvoke(null, null);



            Console.WriteLine("Waiting for threads to finish");



            asyncOperation.EndInvoke(r1);

            Console.WriteLine("Finished thread 1");

            asyncOperation.EndInvoke(r2);

            Console.WriteLine("Finished thread 2");

            asyncOperation.EndInvoke(r3);

            Console.WriteLine("Finished thread 3");

         }

      }

   }

Lets make a few notes about the example above

I have created a delegate using .NET C# 2.0 anonymous methods. This allows me to place a method within a method and give it a delegate name. In this case my delegate is called
asyncOperation.

Within the body of asyncOperation are the unit tests calls (which we normally call from a single thread). Note that declaring the delegate does not execute it.

Right after declaring my delegate I ask .NET to invoke it 3 times on the thread pool. I do this with the BeginInvoke method, which each .NET delegate support.

I pass null for callback, and null for state. That's because in this case I don't need them

Each time a BeginInvoke is called, I get a "token" for the threaded execution called IAsyncResult. Its important to keep all 3 references I get from BeginInvoke. (in this example they are saved as r1, r2 and r3

After launching the 3 threads. I need to wait for them to finish. Calling EndInvoke waits for the execution to finish, but which one? this is where the IAsyncResult plays an important role.

EndInvoke(r1) will wait for the first thread to finish, EndInvoke(r2) waits for the second thread ... as so on.
I could of used a loop and an array to store the IAsyncResults, but that would of made the example more complex. For production use, you should use a loop and array for running the threads.

So there you have it. You ran a set of unit tests that you already have without too much work. But, remember multi-threading requires a few things:

Your unit tests need to be thread safe! its best that they don't share memory, or the small amount of memory they do share is protected between threads.
For more on Nunit go see http://www.nunit.org/

Happy .Netting everyone.

Using Friends with C#, or should I say Bully

2008-05-17T06:55:00.000-07:00

One feature that is missing in C# is the use of Friends, something you can do with C++. There are valid reasons why C# doesn't really support friends, mostly because it breaks OO design. However it would be nice to have something similar. .NET offers the use of internal keyword, which does provide some features similar to friend but it is not the same.

I wanted to do something simple, having a class that can set the private data of another class. Without the use of Reflection, I noticed this was not possible, so I tried to do the next best thing. Having a class able to set the value of a protected item within another class, but without directly inherting from it. To solve the issue, I decided to use a combination of inheritance and nested private classes. Below is an example:


    public class Bob

    {  

        private string mMyBestFriend;



        public string Friend

        {

            get { return mMyBestFriend; }

            protected set { mMyBestFriend = value; }

        }

    }



    public class Mike

    {

        public Mike()

        {

      

        }



        public void MakeMeAFriendOfBob(Bob bob)

        {

            // use the inner class to access the name field.

            new SetFriend().SetFriendName(bob, "Mike");

        }



        private class SetFriend : Bob

        {

            public SetFriend()

            {

          

            }



            public void SetFriendName(Bob bob, string name)

            {          

                bob.Friend = name;

            }



        }

    }

Notice in the example above, that the class Mike is able to set a protected field within the class Bob. Mike is now a friend of Bob in a way. I used an inner private class to handle the inheritance so the class Mike does not need to inherit from Bob directly. There is a reason I said this is like Mike is a Bully, because Bob never really specified who are its friends, as you can do in C++, using simple inheritance I forced Mike to bully its way into Bob.

The main program can do somthing like this:


            Mike me = new Mike();

            Bob bob = new Bob();



            me.MakeMeAFriendOfBob(bob);

Below is another example, allowing one class to set the value of a static field within another class. The static field however is not public, so only certain classes can set it. Same concept as above.


    public class Registry

    {

        private static string mValue;

   

        // only certain classes can set the value

        protected string RegisterValue

        {

            set

            {

                mValue = value;

            }

        }



        // other classes can read the vlaue

        public static string RegisteredValue

        {

            get { return mValue; }

        }

    }





    // notice that FriendOfRegistry does not inhert directly from Registry

    public class FriendOfRegistry

    {



        public FriendOfRegistry()

        {

            // at this point I would like to register my value

            new RegisterValueSetter("SpecialCode");

        }





        private class RegisterValueSetter : Registry

        {

            public RegisterValueSetter(string value)

            {

                base.RegisterValue = value;

            }

        }  

    }

A few notes

This is not a perfect solution, we can always set values to protected items, we just need to use inheritance, so we are not really forcing who can be friends with who, we are just making it a little harder, so the general population can see someone's privates :), sorry I mean protected data.

Using reflection you can always set a private field, but that just evil.

I used this concept when I wanted to register a value within a class, and make sure only a certain class can do it. the idea is that if someone notices a field to be protected, they know they should not really mess with it, unless they have a good reason.

Overall, this is not really how to make "Friend work", and that's why I consider this method more like "Bully".

If you can think of other ideas to solve the Friend feature within C#, I would like to hear from you.

Happy .Netting.

MVP pattern with Windows Workflow

2008-03-30T17:16:00.000-07:00

I am currently looking into interaction of MVP pattern with Windows Workflow. Allowing WF assist the Service layer. I am planning to use state machine workflow to do this. If anyone has done this before, or has good ideas, please send me a note or a link that I can look up for reference. I will post an example of the code once I am done.

Spring.net with forms - Bug!

2008-01-24T14:57:00.000-08:00

I have been trying to have an aspect around a windows form and displaying it using Application.Run method. The problem is that Application.Run wants a form object, and not an interface - this forced me to use ProxyTargetType to true with my form proxy. But doing that made Spring.net crash. It appears this is a bug with their framework and currently they are working on fixing it. I wonder if there are better ways to put aspects on forms, please post them here if you worked with Spring and windows Forms.

Here is a link to the bug
http://forum.springframework.net/showthread.php?t=4252

Click here to go to Spring.net home web site

MVP Article on Code Project

2008-01-10T07:14:00.001-08:00

I have posted the MVP article on the code project. Feel free to reivew it and comment on it there as well. You can go there by clicking here.

MVP (Model View Presenter or Supervising Controller) with DI (Spring.Net) and Threading support

2008-01-01T07:55:00.000-08:00

Introduction

In this article I will show how to use the Model View Presenter pattern to remove logic from the UI and move it to a controller class. Furthermore, I will show an easy way to enable threading within the application and follow the rule of "no business work should be done in the UI thread". By applying threading correctly you should never have a situation where the UI is blocked while processing some business work.

Logon Example

To show the MVP pattern and all its glory I decided to use the logon screen example. We are all familiar with logon: a screen shows up asking for the user name and password. When the user presses the "Logon" button, work is initiated to validate if the user is authenticated on the system. Normally, logon is quick, however in complex systems, logging-on can take significant amount of time, I am going to show how to handle long operations with MVP, using a tiny framework which is based on the thread pool. But, first thing first, lets define our screen.

Creating the View

Views are really our UI layer. Normally these would be web pages or win forms, in this example I will use winforms. Using MVP, the view should really expose no business logic what's so ever. In fact, if you need to add an if statement you should ask yourself if it belongs in the view or the controller, unless your if statement relates with UI work, it probably belongs in the controller. The way I see views in MVP, are classes that at the core expose only properties and events - nothing else. There could be exceptions to this rule, but the goal is to make the view very simple. The view knows how to get data, and how to set data, but it doesn't know in which sequence or why. It is like a dummy puppet that provides all the ropes but without knowing the actual act.

Suppose our logon screen will have a user name field, password field, a status field (indicating if there is an error) and a button for performing the actual log-on. We can define the interface for the view without too much trouble.


   public interface ILogonView

   {

      event EventHandler LogonEvent;

      void Notify(string notification);

      string Password { get; }

      string UserName { get; }

   }

Notice the interface contains a property with setter and getter for each field, and an event for pressing the log-on button. I have also added the Notify method, so I can notify my view from the outside, this method is used to setup the status field indicating if the logon is successful or not. I will talk about this method later. Using the ILogonView interface we get the extra benefit of having a view implemented in different ways, it can be a web page, or it can be a winform. It can even be a regular class - just used for testing.


   public partial class LogonForm : Form, ILogonView

   {

      public event EventHandler LogonEvent;

      public LogonForm()

      {

         InitializeComponent();

      }



      /// 

      /// Get the User Name from the username text box

      /// Trim the user name, and always return lower case

      /// 


      public string UserName

      {

         get { return mTextBoxUserName.Text.Trim().ToLower(); }

      }



      /// 

      /// Get the password from the password textbox

      /// 


      public string Password

      {

         get

         {

            return mTextBoxPassword.Text;

         }

      }



      /// 

      /// Update the screen with a message

      /// 


      /// Message to show on the status bar

      public void Notify(string notification)

      {

         mToolStripStatusLabelStatus.Text = notification;

      }



      private void mButtonLogon_Click(object sender, EventArgs e)

      {

         // fire the event that the button was clicked.

         if (LogonEvent != null)

            LogonEvent(this, EventArgs.Empty);

      }

   }

The Controller

The job of the controller (or the presenter) is to handle the events coming from the view, and use the view getters and setters properties to define the behavior of the view. Think of the view as a data source, just like a data layer, you can query the view for information and you set information to the view. The controller is the only component that knows exactly how to manipulate the view, and how to call the setters and getters in the right sequence.


   public class LogonController

   {

      private ILogonView mView;

      public LogonController(ILogonView view)

      {

         // register the view

         mView = view;



         // listen to the view logon event

         mView.LogonEvent += new EventHandler(mView_LogonEvent);

      }



      void mView_LogonEvent(object sender, EventArgs e)

      {

         string userName = mView.UserName;

         string password = mView.Password;



         if ((userName == "mike") && (password == "aop"))

         {

            mView.Notify("User Logged On");

         }

         else

         {

            mView.Notify("Invlid user name or password");

         }

      }

   }

The controller is listening to the logon event that the view fires. When a logon event handler is triggered, the controller queries the user name and user password and validats if the user name and password are correct. If there is an error message, the controller sets the status message on the view with a message. However there are a few problems... First, I don't know if you noticed, when I first showed the code of the view, it does not contain a reference to the controller. Therefore I need to modify my Form to include knowledge of the controller


   public partial class LogonForm : Form, ILogonView

   {

      public event EventHandler LogonEvent;

      private LogonController mController;

      public LogonForm()

      {

         InitializeComponent();

         mController = new LogonController(this);

      }



   // rest of the class unchanged

So far we are classic MVP, if you understand everything to this point, you have just understood MVP. Anything above this point is just little things that bug me.

The controller is doing all the work, normally the logon work should not be done directly by the controller but delegated to a business layer class to handle the logon, ideally, a logon service.

What if the logon takes 10 minutes to process, we can not keep the view frozen.

What if we would like to send status back to the view during a business operation outside of the controller. how do we handle that?

To be honest with you, I still feel the view should be beyond stupid and not know anything. But, as you can see the view knows about its controller, and how to create it.

Using a service Layer

OK. one problem at a time. The first task would be to remove the logon processing from the controller and move it to a service layer. Let's create a LogonService class, which accepts a user name and a password, and validates if the user is valid. Now we will use our service layer from the controller to perform the logon operation. Same idea, the controller handles the logon event handler and delegates the work to the service layer. The service layer actually does the work of logging and updates the status message on the screen with the outcome of the operation.

We can create a simple service that looks like this:


   public class LogonService

   {

      public bool Logon(string userName, string password)

      {

         bool rc;

         if ((userName == "mike") && (password == "aop"))

         {

            rc = true;      

         }

         else

         {

            rc = false;

         }

      }

   }

But, here again, we have some problems. What if our service is a long running service, and maybe executes many steps to log a user. This example is simple, but let's face it is never that simple in production code. We normally have to go to the database to validate a user, I would like to provide the service some way to report status back to the view. After all, our controller can do this, so should the service... An idea would be to introduce an interface to allow the service report status something like INotify


   public interface INotify

   {

      void Notify(string notification);

   }

Now this should look familiar, our View has this method... (take a look)




   public interface ILogonView

   {

      event EventHandler LogonEvent;

      void Notify(string notification);

      string Password { get; }

      string UserName { get; }

   }

So, lets break this into 2 interfaces...


   public interface INotify

   {

      void Notify(string notification);

   }



   public interface ILogonView : INotify

   {

      event EventHandler LogonEvent;

      string Password { get; }

      string UserName { get; }

   }

Notice that ILogonView inherits from INotify. Now we need to pass this INotify to the service, so lets modify our service. Other then that little change there nothing new with our View. Lets look at the controller using the

LogonService class.


   public class LogonController

   {

      private ILogonView mView;

      public LogonController(ILogonView view)

      {

         // register the view

         mView = view;



         // listen to the view logon event

         mView.LogonEvent += new EventHandler(mView_LogonEvent);

      }



      void mView_LogonEvent(object sender, EventArgs e)

      {

         string userName = mView.UserName;

         string password = mView.Password;



         LogonService logonService = new LogonService(mView);

         logonService.Logon(userName, password);

      }

   }





   public class LogonService

   {

      private INotify mNotifier;

      public LogonService(INotify notifier)

      {

         mNotifier = notifier;

      }

      public bool Logon(string userName, string password)

      {

         bool rc;

         if ((userName == "mike") && (password == "aop"))

         {

            mNotifier.Notify("Logon Successful");

            rc = true;      

         }

         else

         {

            mNotifier.Notify("Invliad User or Password");

            rc = false;

         }



         return rc;

      }

   }

Notice a few things:

The service is created as a local variable to the event handler, it might be better to create the service once and keep it during the lifetime of the controller, but then we have the problem of who creates the service? It could be passed to the controller on the constructor or created directly in the Controller, but then it might not be re-used by other controllers. Best approach is to pass the service to the constructor, but I am not willing to have the view create it and pass it. I will deal with this issue soon.

The service is passing the view as an INotify, there is really nothing wrong with that, but if you think about it allows the service direct access to the UI. A better way would be to have the service talk to the Controller via INotify. Then we are respecting the role of the controller... (so I am going to make this change by allowing the controller to implement INotify

The goal was to provide the service a channel to communicate to the view, so now it is possible for a long running service to report status. But, what if we don't want to report anything, and would like to run the service without a view and without a UI, notice that you can't create the service without INotify. So here is another problem, which I will deal with later. At least we can say the logic of the logon is now outside of the controller, and our service is a little more powerful with its capabilities

A note about DDD (Domain Driven Design), notice my service is not very domain driven, it is normally at the service level that we should see classes such as User, and Authentication, For example Autentication.Autenticate(User user), but I am leaving the domain model out of this article, because already I have a lot of problems to solve and DDD deserve an article on its own.

Lets do a bit of re-factoring, first step, lets create the service as a member variable of the controller class. Lets also have the ability to pass the service to the constructor


      public LogonController(ILogonView view)

      {

         // register the view

         mView = view;



         // listen to the view logon event

         mView.LogonEvent += new EventHandler(mView_LogonEvent);



         mLogonService = new LogonService(this);

      }



      // set the serivce by the client (but not used for now).

      public LogonController(ILogonView view, LogonService logonService)

      {

         // register the view

         mView = view;



         // listen to the view logon event

         mView.LogonEvent += new EventHandler(mView_LogonEvent);



         mLogonService = logonService;

      }



      void mView_LogonEvent(object sender, EventArgs e)

      {

         string userName = mView.UserName;

         string password = mView.Password;

         mLogonService.Logon(userName, password);

      }



      // used to implemnt INotify

      public void Notify(string notification)

      {

         mView.Notify(notification);

      }

   }

The controller implements INotify

The service can be passed to the controller, it's more flexible. But I am not changing the view, so this constructor will not be used

I created the service as a member variable if it is not passed.

OK. Lets step back a little, most of you might be happy with this implementation of MVP, and it is kind of by the book. But, I am still not happy with it. First of all, who is going to create the LogonService, it should really be set outside of the controller, or supplied to the controller (but I hate having the view create the service. Same problem with the Controller being created by the view. The view should have no knowledge of how to create a controller, it would be nice if the controller can be supplied to the view. The solution is to have a factory pattern to create the controller, service and even the view! The solution to all these problems can be addressed with Dependency Injection (DI).

The View depends on a Controller, and my Controller depends on a service. I can create a Factory that will create my view, addressing all the dependencies, and what do you know, there is a framework out there just for that - Spring.Net.

Using Spring.NET for Dependency Injection

To tell you all the truth, I am new to Dependency Injection, however it was not complicated to learn, and it solves the issues of object creation and dependecies. I chose to resolve all dependecies using setters properites. I have also created interfaces to all the classes that require depndecy injection

The controller interface:


   public interface ILogonController : INotify

   {

      ILogonView LogonView { get; set; }

   }

Setting the view to the controller, rather then passing the view as parameter into the constructure. Now the controller can have a empty default constructure.

Lets see the newly modified controller


   public class LogonController : INotify, ILogonController

   {

      private ILogonView mView;

      private ILogonService mLogonService;



      public LogonController()

      {



      }



      public LogonController(ILogonView view)

      {

         // register the view

         mView = view;



         // listen to the view logon event

         mView.LogonEvent += new EventHandler(mView_LogonEvent);



         mLogonService = new LogonService(this);

      }



      // set the serivce by the client (but not used for now).

      public LogonController(ILogonView view, LogonService logonService)

      {

         // register the view

         mView = view;



         // listen to the view logon event

         mView.LogonEvent += new EventHandler(mView_LogonEvent);



         mLogonService = logonService;

      }



      void mView_LogonEvent(object sender, EventArgs e)

      {

         // make sure the view is attached

         Debug.Assert(mView != null, "view not attached");



         string userName = mView.UserName;

         string password = mView.Password;



         mLogonService.Logon(userName, password);

      }



      // used to implemnt INotify

      public void Notify(string notification)

      {

         mView.Notify(notification);

      }



      public ILogonService LogonService

      {

         set

         {

            mLogonService = value;

            mLogonService.Notifier = this;

         }

         get

         {

            return mLogonService;

         }

      }



      public ILogonView LogonView

      {

         set

         {

            mView = value;

            mView.LogonEvent += new EventHandler(mView_LogonEvent);

         }

         get

         {

            return mView;

         }

      }

   }

Notes:

Now when setting the LogonView property, the view is attached to the controller. Spring.Net will handle this for us.

Because this controller can be created using an empty constructure, I added an Assert, to make sure the view is attached when handling the logon event handler

Notice there is a setter property for the LogonService, After setting the service, the controller sets the Notify property of the service.

In order to inject the service into the controller, I needed to first make an interface to the service. Lets take a look at the service interface and the service class:


   public interface ILogonService

   {

      bool Logon(string userName, string password);

      INotify Notifier { get; set; }

   }



   public class LogonService : ILogonService

   {

      private INotify mNotifier;

      public LogonService()

      {

         // instead of having it as null

         mNotifier = new EmptyNotify();

      }

      public LogonService(INotify notifier)

      {

         mNotifier = notifier;

      }

      public bool Logon(string userName, string password)

      {

         bool rc;

         if ((userName == "mike") && (password == "aop"))

         {

            mNotifier.Notify("Logon Successful");

            rc = true;      

         }

         else

         {

            mNotifier.Notify("Invliad User or Password");

            rc = false;

         }



         return rc;

      }

      public INotify Notifier

      {

         set { mNotifier = value; }

         get { return mNotifier; }

      }

   }

Notes:

The logon service interface now allows an INotify to be specified as a setter (so if I wanted, it could of been initialized using DI as well, but I am not doing it in this example

I provide an empty constructor, so now I don't need to have a notify object for creating or running the service. However, in case the INotify is not passed to the constructor or not set by the setter, I provide an EmptyNotify which is similar to having the mNofity set to null. However, because this empty class implements the interface, I don't need to check in my code if the INotify object is null, or if is passed.

Here a quick look at the EmptyNotify (which is like a Null)


  public class EmptyNotify : INotify

   {

      public void Notify(string notification)

      {

         return; // do nothing.

      }

   }

Lets see how the view is changed

The nice thing about the new version of the view is that it is now simpler, the goal was always to keep the view unaware of business work and even something simple as creating the controller is now outside of the view. Like anything in MVP, there is a property to set the controller.


      public ILogonController LogonController

      {

         set

         {

            mController = value;

            mController.LogonView = this;

         }

      }

Notice that right after the controller is set, I assign the view to the controller LogonView property. Here is the full source code of the view after the modification.


   public partial class LogonForm : Form, ILogonView

   {

      public event EventHandler LogonEvent;

      private ILogonController mController;

      public LogonForm()

      {

         InitializeComponent();

      }



      /// 

      /// Get the User Name from the username text box

      /// Trim the user name, and always return lower case

      /// 


      public string UserName

      {

         get { return mTextBoxUserName.Text.Trim().ToLower(); }

      }



      /// 

      /// Get the password from the password textbox

      /// 


      public string Password

      {

         get

         {

            return mTextBoxPassword.Text;

         }

      }



      public ILogonController LogonController

      {

         set

         {

            mController = value;

            mController.LogonView = this;

         }

      }



      /// 

      /// Update the screen with a message

      /// 


      /// Message to show on the status bar

      public void Notify(string notification)

      {

         mToolStripStatusLabelStatus.Text = notification;

      }







      private void mButtonLogon_Click(object sender, EventArgs e)

      {

         // fire the event that the button was clicked.

         if (LogonEvent != null)

            LogonEvent(this, EventArgs.Empty);

      }

   }

Setting Spring.Net

So far I have tried to avoid talking about Spring.Net, but at this point we are ready to deal with
Dependency Injection. First step is to get Spring.Net and install it. Don't worry it is safe, I have done it many times it will not break anything on your computer. You can download Spring.Net from http://www.springframework.net/

This example is using version 1.1 of Spring.Net

Next step is adding a file reference to Spring.Core.dll into the .NET project.

Now, that we have Spring.net, all that is left is to specify the dependencies for creating the objects (view, controller and service). To do this I have used the app.config to specify the dependencies in XML. The XML is simple to understand here is a copy of my App.Config for the Logon MVP example:


<?xml version="1.0" encoding="utf-8" ?>

<configuration>

   <configSections>

      <sectionGroup name="spring">

         <section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>

         <section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />

      </sectionGroup>

   </configSections>


   <spring>


      <context>

         <resource uri="config://spring/objects"/>

      </context>


      <objects xmlns="http://www.springframework.net/">


         <object id ="LogonService" type="MvpExample.LogonService, MvpExample"/>



         <object id="LogonController" type="MvpExample.LogonController, MvpExample">

            <property name="LogonService" ref="LogonService"/>

         </object>



         <object id="LogonView" type="MvpExample.LogonForm, MvpExample">

            <property name="LogonController" ref="LogonController"/>

         </object>                                       

      </objects>

   </spring>

</configuration>

Notes:

The Object ID tag is just a logical name

I have setup the LogonView, to have its property LogonController set to the object definition of "LogonController"

Similar case with the setting the LogonService logical name into the LogonController property "LogonService"

All that is left, is just to create the root object, the view within my application. Notice the changes to Program.cs


   static class Program

   {

      /// 

      /// The main entry point for the application.

      /// 


      [STAThread]

      static void Main()

      {

         Application.EnableVisualStyles();

         Application.SetCompatibleTextRenderingDefault(false);





         IApplicationContext ctx = ContextRegistry.GetContext();

         Form logonForm = ctx.GetObject("LogonView") as Form;

         Application.Run(logonForm);

      }

   }

The most important part are the Spring.net application context:

IApplicationContext ctx = ContextRegistry.GetContext();

         Form logonForm = ctx.GetObject("LogonView") as Form;

Here we are asking Spring.Net to create our View object, by specifying its Logical Name LogonView, the name must match the name in the app.config


<object id="LogonView" type="MvpExample.LogonForm, MvpExample">

      <property name="LogonController" ref="LogonController"/>

</object>

All the other dependencies are taken care of by using Spring.Net. At this point our Logon application is initialized with the correct version of a view, controller and service. Notice that this allows us to "switch" the implementation of a dependency, just by providing a new implementation of an interface and configuration change. For example, to provide another version of the LogonService that willcontain
additional work, we just need to tell Spring.Net which version to "inject". At this point I wanted to finish my article, but I noticed that there is one more issue with this MVP
pattern. The case of having a long running service, and the risk of freezing the UI while processing the service. To solve this problem I have introduced a simple but yet powerful little threading framework.

The UI should never freeze

The main problem with UI and threads, is that the UI is not allowed to accessible from any other the thread then the thread it was created. This means that if our application starts to create threads, and performs processing in threads, it is not legal to have these threads update the UI (via an interface or not). In fact, trying to update the UI from another thread will cause a runtime exception in .NET 2.0, and unpredictable results in version 1.1

So, our first goal is to make sure the UI is able to update correctly no matter from which thread it is called on. To do this, I have added a base class to my LogonForm called View. My base class contains only one method, UpdateUI, this method accepts a delegate of type MethodInvoker and makes sure this delegate is executed on the UI thread.


   public class View : Form

   {

      protected void UpdateUI(MethodInvoker uiDelegate)

      {

         if (InvokeRequired)

            this.Invoke(uiDelegate);

         else

            uiDelegate();

      }

   }

I am planning to use the same delegate for all my UI activities. This should make you wonder, how a delegate that takes no arguments and no return values is able to satisfy all UI operations.

Here is a trick... I use Anonymous methods to wrap all UI operations... lets look at a simple example:

Getting the user name from the UI should be done on the UI thread, so I would like to wrap the code that gets the user name from the textbox into a MethodInvoker delegate

Before:


      public string UserName

      {

         get

         {

            return mTextBoxUserName.Text.Trim().ToLower();

         }

      }

After:


      public string UserName

      {

         get

         {

            string value = null;

            MethodInvoker uiDelegate = delegate

            {

               value = mTextBoxUserName.Text.Trim().ToLower();

            };

            UpdateUI(uiDelegate);

            return value;

         }

      }

Notice: for the getters, I needed to store the return value outside of my anonymous method. This is because my delegate does not accept a return value. This is an issue I plan to resolved in a second part of the article... (using AOP to handle UI thread safely). Now, we have to surround all our View public methods with this uiDelegate. To make the job simpler I made a C# Snippet that allows you to select the code within the property, and then apply the "view thread safe"

snippet. Here is the snippet, if you want to use it.

<?xml version="1.0" encoding="utf-8" ?>

<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">

 <CodeSnippet Format="1.0.0">

  <Header>

   <Title>View Thread Safe</Title>

   <Shortcut>view</Shortcut>

   <Description>Code snippet for creating thread safe view code</Description>

   <Author>Atrion Corporation</Author>

   <SnippetTypes>

    <SnippetType>Expansion</SnippetType>

    <SnippetType>SurroundsWith</SnippetType>

   </SnippetTypes>

  </Header>

  <Snippet>

   <Declarations>

    <Literal>

     <ID>delegate</ID>

     <ToolTip>Delegate to call</ToolTip>

     <Default>uiDelegate</Default>

    </Literal>

    <Literal>

     <ID>method</ID>

     <ToolTip>Function to handle the threading</ToolTip>

     <Default>UpdateUI</Default>

    </Literal>

     

   </Declarations>

   <Code Language="csharp"><![CDATA[

        MethodInvoker $delegate$ = delegate

        {

         $selected$ $end$

        };

        $method$($delegate$);

 $end$]]>

   </Code>

  </Snippet>

 </CodeSnippet>

</CodeSnippets>

Lets look at our new View method:


   public partial class LogonForm : View, ILogonView

   {

      public event EventHandler LogonEvent;

      private ILogonController mController;

      public LogonForm()

      {

         InitializeComponent();

         //mController = new LogonController(this);

      }



      /// 

      /// Get the User Name from the username text box

      /// Trim the user name, and always return lower case

      /// 


      public string UserName

      {

         get

         {

            string value = null;

            MethodInvoker uiDelegate = delegate

            {

               value = mTextBoxUserName.Text.Trim().ToLower();

            };

            UpdateUI(uiDelegate);

            return value;

         }

      }



      /// 

      /// Get the password from the password textbox

      /// 


      public string Password

      {

         get

         {

            string value = null;

            MethodInvoker uiDelegate = delegate

            {

                value = mTextBoxPassword.Text;

            };

            UpdateUI(uiDelegate);

            return value;

         }

      }



      public ILogonController LogonController

      {

          set

          {

            mController = value;

            mController.LogonView = this;

          }

      }



      /// 

      /// Update the screen with a message

     /// 


     /// Message to show on the status bar

      public void Notify(string notification)

      {

         MethodInvoker uiDelegate = delegate

         {

            mToolStripStatusLabelStatus.Text = notification;

         };

         UpdateUI(uiDelegate);

      }

      private void mButtonLogon_Click(object sender, EventArgs e)

      {

         // fire the event that the button was clicked.

         if (LogonEvent != null)

            LogonEvent(this, EventArgs.Empty);

      }

   }

Now our view is able to update itself, no matter from which thread it is being called from. Next step is to actually use threads within the controller. Suppose the logon takes 5 seconds to logon. To enable threading at the controller level I can use the same approach I used for the view. Using delegates... Notice the new base controller class.


   public class AsyncController

   {

      public delegate void AsyncDelegate();



      // must call end invoke to clean up resources by the .net runtime.

      // if there is an exception, call the OnExcption which may be overridden by

      // children.

      protected void EndAsync(IAsyncResult ar)

      {

         // clean up only.

         AsyncDelegate del = (AsyncDelegate)ar.AsyncState;

         try

         {

            del.EndInvoke(ar);

         }

         catch (Exception ex)

         {

            OnException(ex);

         }

      }



      protected void BeginInvoke(AsyncDelegate del)

      {

         // thread the delegate, as a fire and forget.

         del.BeginInvoke(EndAsync, del);

      }



      protected virtual void OnException(Exception ex)

      {

       // override by childern

      }

   }

Notes:

By calling BeginInvoke on a delegate I am using the thread-pool

I don't really care for output values or return code and this is mostly due to the MVP pattern, when I implement my controller function I can know when to set values to the view.

Notice that I still make sure EndInvoke is called; this is for 2 reasons, first to make sure I get exceptions and second making sure there is no resource leak. Calling BeginInvoke without EndInvoke may cause resources to leak.

If there is an exception, I let the child controller to take care of it.

I modified the logon service to simulate a long running operation, by Sleeping for 5 seconds


      public bool Logon(string userName, string password)

      {

         // simulate a long operation, wait 5 seconds.

         System.Threading.Thread.Sleep(TimeSpan.FromSeconds(5));



         bool rc;

         if ((userName == "mike") && (password == "aop"))

         {

            mNotifier.Notify("Logon Successful");

            rc = true;      

         }

         else

         {

            mNotifier.Notify("Invliad User or Password");

            rc = false;

         }



         return rc;

      }

Lets, see the new logon event handler using threads:


      void mView_LogonEvent(object sender, EventArgs e)

      {

         // make sure the view is attached

         Debug.Assert(mView != null, "view not attached");



         AsyncDelegate asyncOperation = delegate

         {

            mView.Notify("About to perform logon");

            string userName = mView.UserName;

            string password = mView.Password;



            mLogonService.Logon(userName, password);



         };

         base.BeginInvoke(asyncOperation);

      }

Just one note:
Now when you execute the program, the UI will not freeze when pressing logon (the way it should be). However that doesn't stop the user from keep pressing on the logon button. It is important to add to the view additional functions to enable and disable the button. I didn't do it in this example, however it works well with MVP, but providing a setter method to enable or disable the Logon Button.

Conclusion

We went a long way from our simple Logon application. We have removed most of the logic from the view, keeping the view very simple. We have used DI to allow the application to inject the controller and service into our view. Finally, I have showed a way to enable threading without making major changes. The idea is to wrap UI functions with thread safe code, allowing all UI code to be marshalled to the UI thread. The only last re-factoring left to do is to remove the thread safety wrappers, and find a way to have them done with an Advice using Spring.Net. That way we can keep the view simple, not even knowing about the threading work.

However, I think this will be done in my next article. I hope you enjoyed this article - Happy .netting.

Dowload sample code: http://mike.peretz.googlepages.com/MvpProject.zip

Attaching strings to enums

2007-12-31T10:47:00.000-08:00

I Found this little cool way to attach strings to enums. Using .NET 3.5 you can do something cool and simple like this


   public static class EnumExtension
   {
      public static string GetDescription(this Enum enumObj)
      {
         FieldInfo fieldInfo =
         enumObj.GetType().GetField(enumObj.ToString());
         object[] attribArray = fieldInfo.GetCustomAttributes(false);
         if (attribArray.Length == 0)
            return String.Empty;
         else
         {
            DescriptionAttribute attrib =
                attribArray[0] as DescriptionAttribute;
            return attrib.Description;
         }
      }
   }

   class Program
   {
      public enum EmployeeType
      {
         [Description("Regular Employee")]
         RegularEmploye,
         [Description("Store Manager")]
         StoreManager,
         [Description("Chain Store Manager")]
         ChainStoreManager,
         [Description("Department Manager")]
         DepartmentManager,
         [Description("On Floor Supervisor")]
         Supervisor
      }

      static void Main(string[] args)
      {        
         string str = EmployeeType.ChainStoreManager.GetDescription();       
      }
   }

Basically I have added an extension to the enum class to extract the value of the Description Attribute. Now, every Enum class will have a GetDescription method attached to it. This is a nice and clean way to string values out of your enums....

only supported in VS2008 using .NET 3.5

MVP Article coming soon...

2007-12-28T19:28:00.000-08:00

I am currently working on an article for the code project showing MVP using AOP and DI (Dependency Injection). I hope to be done before the holidays...

The article will cover the following:

- How to make the view unaware of the controller (using DI)
- How to handle long running processes at the controller level
- How to move logic outside of the controller and place it in the business layer
- How to handle threading within the view, using AOP.

Keep checking, I hope to be done within a few days...

Using internal within the domain layer

2007-11-20T16:46:00.001-08:00

There is a very nice trick you can do with the internal key word that I think is worth writing about. If you want to implement an Active Record class, such as customer.Save(), sometimes we might not want the presentation layer to have access to this method directly and pass via an application layer.

so the presentation layer code will call something like this:

customerService.SaveCustomer(customer) instead of customer.Save()

The reason is that within the application layer we might want to handle error handling and logging, work that normally does not belong in the domain. With internal it is very possible. First you have to place your Customer in its own assembly. Company.Domain.dll and your presentation would be in its own assembly as well Company.Presentation.dll

Now the methods and even properties you don't want the UI to access directly are marked as internal


// Customer class
internal Save()
{
   // save the information within customer
}

The application layer needs to be within the same assembly as the domain, so its has access to internal members. Now our application layer can do something like this:


public CustomerService
{
     public SaveCustomer(Customer cust)
     {
        try
        {
            //delegate the work to domain, 
            //the Save method is visible to the application layer
            cust.Save();    
        }
        catch(Exception e)
        {
             Logger.LogException(e); // perform logging 
        }
     }
}

You can even take the idea further by marking certain properties as internal, so the presentation layer will not see them at all.

This is just one way of limiting the visibility of members and properties of a class, and I believe it is an elegant and nice solution when you want to control member visibility between the presentation layer and Active Record domain classes.

One last note...

I am not a big fan of active record and believe more in repositories, however active record has its place in DDD, it works well when the class maps well to the persistence layer.

So... remember, not everything should be public, some data should be kept "internal" to the domain.

A note about EndInvoke()

2007-11-15T17:47:00.000-08:00

I think it is important to mention something about the EndInvoke. You should know that calling EndInoke is not optional, if you don't call it there will be some sort of memory leak. Even if you don't need to know when you method finished executing, and even if there are no output parameters and return value parameters you need analyse, its a good idea to call Endinvoke. Don't forget that you will not know about exceptions if you don't call EndInvoke... so just call it...

I know my fire and forget example may seem like its optional, but its not.

I will also update my article to include this information.

More information http://www.interact-sw.co.uk/iangblog/2005/05/16/endinvokerequired

Coming soon...

2007-11-13T18:55:00.000-08:00

Locking objects at the application layer

How to implement pessimistic locking without using a database or a data access layer. Providing the management to "check-out", "check-in" objects at the application layer.

Plug-ins

How to build a dynamic winform application using plug-in design

Model View Presenter with Async method invocation

How to use Model View Presenter design pattern, with async method invocation to never freeze the UI and create a flexible user interface.

As soon as I have a little time (between changing diapers)... I will write down all these juicy articles.

.NET Links

2007-11-13T18:40:00.000-08:00

My .NET Links Collection

Web casts and videos
.NET Rocks
Channel 9
NetFX
Windows Workflow
Windows Presentation Foundation

Logging Using the Composite Pattern

2007-11-12T15:48:00.000-08:00

Download source code - 48.4 Kb

Introduction

In this article, I will explain how I solved a common problem I used to have regarding logging within my business layer. Normally, I would have a function call from my presentation layer to my business layer; however, once in the business layer, I had no access to the presentation layer anymore. There are many ways to solve this problem. In the MFC days, a Doc / View approach based on the Observer pattern was used. In .NET, we can use custom events to notify the presentation layer that something happened. But, in this article, I will show the Composite pattern in action, and some of its nice advantages.

The Requirements

Suppose we had a function in our business layer that performs a lot of updates. It would be nice that during all these updates, we log the exact action taking place. We want to easily log a string describing the activity to one of, all of, or some of the following loggers: TextBox, ListBox, text file and/or the EventLog.

Creating the ILogger Interface

To keep the example simple, I will implement a simple ILogger interface that only requires a logger class to implement its own way of logging an activity.

public interface ILogger
{
    void LogMessage(string strMessage);
}

Creating Logger Classes

Create the following logger classes:

Text box logger - logs a message into a text box
List box logger - adds a message to the list
File logger - logs a message into a file
EventLog logger - logs a message into the system event log

ListBox Logger

Notice that the ListBox and TextBox loggers are thread safe, by using the InvokeRequired method.

class ListBoxLogger : ILogger
{
    ListBox m_listBox;
    public ListBoxLogger(ListBox listBox)
    {
        m_listBox = listBox;
    }

    public void LogMessage(string strMessage)
    {
        MethodInvoker logDelegate = delegate 
        {
            m_listBox.Items.Add(strMessage);
        };

        if (m_listBox.InvokeRequired)
            m_listBox.Invoke(logDelegate);
        else
            logDelegate();
    }
}

TextBox Logger

class TextBoxLogger : ILogger
{
    private TextBox m_textBox;
    public TextBoxLogger(TextBox txtBox)
    {
        m_textBox = txtBox;
    }

    public void LogMessage(string strLogMessage)
    {
        MethodInvoker logDelegate = delegate { m_textBox.Text = strLogMessage; };
        if (m_textBox.InvokeRequired)
            m_textBox.Invoke(logDelegate);
        else
            logDelegate();
    }
}

File Logger

class FileLogger : ILogger
{
    private string m_strFileName;
    private object m_sync = new object();
    public FileLogger(string strFileName)
    {
        m_strFileName = strFileName;
    }

    public void LogMessage(string strMessage)
    {
        lock (m_sync)
        {
            using (StreamWriter writer = new StreamWriter(m_strFileName))
            {
                writer.WriteLine(strMessage);
            }
        }
    }
}

Notice that the FileLogger is thread-safe, and that it opens and closes the file before writing to it. This guarantees that the message is flushed after each call to LogMessage.

EventLog Logger

class EventLogger : ILogger
{
    public EventLogger()
    {

    }

    public void LogMessage(string strMessage)
    {
        EventLog.WriteEntry("Logger", strMessage);
    }
}

Using the ILogger Object

So far, there is nothing special here; we can have a function that takes a ILogger object and allow us to log messages. For example:

private void DoSomthing(ILogger logger)
{
    for(int i=0; i < 10; i++)
    {
        logger.LogMessage("Logging a message " + i.ToString());
     
    }
}

The client code looks like this:

// pass the File Logger
DoSomthing(new FileLogger("C://LogMessage.txt")); 
// txtBox is a text box control on the form
DoSomthing(new TextBoxLogger(textBox));

Introducing the CompositeLogger

But what if I want to log to all my loggers at the same time, or what if I want to log to only some of my loggers? To solve this requirement, I create a new logger called a Composite Logger.

// Logger of composite of loggers
class CompositeLogger : ILogger
{
    private ILogger[] m_loggerArray;
    
    // pass a ILoggers that are part of this composite logger
    public CompositeLogger(params ILogger[] loggers)
    {
        m_loggerArray = loggers;
    }

    public void LogMessage(string strMessage)
    {
        // loop around all the loggers, and log the message.
        foreach (ILogger logger in m_loggerArray)
            logger.LogMessage(strMessage);
    }
}

Let's Use Our Composite Logger to "Configure" Which Loggers to Use

Using all the loggers:

CompositeLogger compositeLogger =   
        new CompositeLogger(new TextBoxLogger(textBox),
                            new ListBoxLogger(listBox),
                            new FileLogger("C:\\LogPattern.txt"),
                            new EventLogger() );

Creating a composite logger with only TextBoxLogger and ListBoxLogger:

CompositeLogger compositeLogger =   
        new CompositeLogger(new TextBoxLogger(textBox),
                            new ListBoxLogger(listBox));

Because our composite logger implements ILogger like all the other loggers, we can pass it to a function that expects an ILogger object type.

DoSomthing(compositeLogger);

Testing the Composite Logger in a Thread

Let’s test our composite logger in a separate thread, just to make sure we can update the UI from a thread other than the UI-thread.

// create a composite logger with all the loggers
CompositeLogger compositeLogger =
    new CompositeLogger(
            new TextBoxLogger(textBox),
            new ListBoxLogger(listBox),
            new FileLogger("C:\\LogPattern.txt"),
            new EventLogger());

// create a anonymous function to call DoSomthing
ParameterizedThreadStart threadDelegate = delegate(object obj)
{
    ILogger logger = (ILogger)obj;
    DoSomthing(logger);
};

// Do Somthing in a thread
Thread t = new Thread(threadDelegate);
t.Start(compositeLogger);

Conclusion

Notice that I am now able to pass an ILogger object to a method within the business layer or to the data layer, and provide an easy way to log a message. This is done by using the ILogger interface, and therefore, your business layer or data layer requires no extra references to File.Io, or Windows.Forms, it only needs to have a reference to ILogger. It is also nice that you can easily add and remove loggers by using your composite Logger. Thank you for reading, have a good day!

.NET Enum The Next Level

2007-11-12T15:41:00.000-08:00

Introduction

In this article, I am going to explore enums a little further. I am not going to cover the basic information about enums (you can always refer to MSDN for details). My biggest beef with enum is that it only represents numeric data. It is flexible to represent different integral types, but it can not hold a string. Enums do support the ToString() function, however with limitation (I will go into it in more details, later in the article). Basically, I want to be able to make my enumeration element be associated to more than just an integer value, to achieve this I will use Reflection and Attributes and try to keep my example as simple as possible.

Using ToString() with enums

Let's create a simple enumeration...

    public enum EmployeeType
    {
        RegularEmployee,
        StoreManager,
        ChainStoreManager,
        DepartmentManager,
        Supervisor
    }

Based on this simple plain vanilla enumeration, we can get the following information: a String representation using ToString().

   EmployeeType employee = EmployeeType.ChainStoreManager;
   Console.WriteLine(employee.ToString());
   Console.WriteLine(EmployeeType.ChainStoreManager.ToString());

The output is the same for both lines of code:

ChainStoreManager
ChainStoreManager

But what if I wanted to get "Chain Store Manager" with spaces? You can not create an enum type that contains spaces, your code wouldn't compile. There are a lot of solutions to this problem.

Create a mapping between enums and strings (using arrays, or hashtables).
Using the enum ToString() as a key for a language resource file.
Use a litte bit of reflection... I will explore option 3...

Using attributes with enums

In order to associate a string with an enumeration, I used Attributes. I will start with a simple exmaple that will assocate my enumeration with a string.

    public class EnumDescriptionAttribute : Attribute
    {
        private string m_strDescription;
        public EnumDescriptionAttribute(string strPrinterName)
        {
            m_strDescription = strPrinterName;
        }

        public string Description
        {
            get { return m_strDescription; }
        }
    }

EnumDescriptionAttribute is a simple attribute that holds a string. The attribute has a single property to return the description. For now, I am going to keep it as simple as possible. Now that I have my description attribute, I will assocate it with each enum element.

public enum EmployeeType
{
    [EnumDescription("Regular Employee")]
    RegularEmploye,
    [EnumDescription("Store Manager")]
    StoreManager,
    [EnumDescription("Chain Store Manager")]
    ChainStoreManager,
    [EnumDescription("Department Manager")]
    DepartmentManager,
    [EnumDescription("On Floor Supervisor")]
    Supervisor
}

Getting the attribute value from an enum

In order to get the attribute value from an enumeration, I have to use Reflection. Here is an example:

// setup the enum
EmployeeType employee = EmployeeType.ChainStoreManager;

// get the field informaiton
FieldInfo fieldInfo = employee.GetType().GetField("ChainStoreManager");

// get the attributes for the enum field
object[] attribArray = fieldInfo.GetCustomAttributes(false);

// cast the one and only attribute to EnumDescriptionAttribute
EnumDescriptionAttribute attrib =
    (EnumDescriptionAttribute)attribArray[0];

// write the description
console.WriteLine("Description: {0}", attrib.Description);

Output: Chain Store Manager

The most important line of code is: FieldInfo fieldInfo = employee.GetType().GetField("ChainStoreManager");. Notice that I hardcoded the enum element name ChainStoreManager, but if you go back and look at the ToString() function, you can see that I could have used ToString() instead.

A Generic function to get the description

Notice I used ToString() on the Enum...

public static string GetEnumDescription(Enum enumObj)
{
    FieldInfo fieldInfo =
        enumObj.GetType().GetField(enumObj.ToString());

    object[] attribArray = fieldInfo.GetCustomAttributes(false);
    if (attribArray.Length == 0)
        return String.Empty;
    else
    {
        EnumDescriptionAttribute attrib =
            attribArray[0] as EnumDescriptionAttribute;

        return attrib.Description;
    }
}

Let's associate more than just a string to our enum elements

So far, we only associated a description to our enumeration element. However, it is fully possible to associate any type of data to our enum. To show this, I am going to create a new enumeration (similar to the first one).

public enum ManagerType
{
    StoreManager,
    ChainManager,
    Superivor
}

I am also creating a new attribute class, ManagerAttribute, that inherits from EnumDescription, and provides two additional pieces of information (Min Salary and Max Salary).

public class ManagerAttribute : EnumDescriptionAttribute
{
    private int m_intMinSalary;
    private int m_intMaxSalary;
    public ManagerAttribute(string strDescription,
        int intMinSalary,
        int intMaxSalary) : base(strDescription)
    {
        m_intMinSalary = intMinSalary;
        m_intMaxSalary = intMaxSalary;
    }

    public ManagerAttribute(string strDescription)
        : base(strDescription)
    {

    }

    public int MinSalary
    {
        get {return m_intMinSalary;}
        set { m_intMinSalary = value; }
    }
    public int MaxSalary
    {
        get { return m_intMaxSalary;}
        set { m_intMaxSalary = value; }
    }
}

Now, I am going to associate a ManagerAttribute to each enum element. Notice that I am using the set properties within my ManagerAttributes, so the code is more readable

public enum ManagerType
{
    [Manager("Store Manager", MinSalary=40000, MaxSalary=100000)]
    StoreManager,
    [Manager("Chain Manager", MinSalary=50000, MaxSalary=110000)]
    ChainManager,
    [Manager("Store Supervisor", MinSalary=30000, MaxSalary=50000)]
    Superivor
}

Next step is improving our generic function to allow us to get any type of EnumDescriptionAttribute; using Generics this is easily done!

public static T GetAttribute<T>(Enum enumObj) where T : EnumDescriptionAttribute
{
    // get field informaiton for our enum element
    FieldInfo fieldInfo = enumObj.GetType().GetField(enumObj.ToString());

    // get all the attributes associated with our enum
    object[] attribArray = fieldInfo.GetCustomAttributes(false);

    if (attribArray.Length == 0)
        return default(T);
    else
    {
        // cast the attribute and return it
        T attrib = (T)attribArray[0];
        if (attrib != null)
            return attrib;
        else
            return default(T);
    }
}

Helper functions

So far we have got two helper functions, one to obtain a simple string description of an enum, and the other function, a more generic function to obtain any attribute that inherits from EnumDescriptionAttribute. You can add these helper functions to a class like EnumHelper; but in this example, I decided to simply add them to the existing EnumDescriptionAttribute.

public class EnumDescriptionAttribute : Attribute
{
    private string m_strDescription;
    public EnumDescriptionAttribute(string strEnumDescription)
    {
        m_strDescription = strEnumDescription;
    }

    public string Description { get { return m_strDescription; } }

    public static string GetEnumDescription(Enum enumObj)
    {
        FieldInfo fieldInfo = enumObj.GetType().GetField(enumObj.ToString());
        object[] attribArray = fieldInfo.GetCustomAttributes(false);
        if (attribArray.Length == 0)
            return String.Empty;
        else
        {
            EnumDescriptionAttribute attrib = attribArray[0]
                as EnumDescriptionAttribute;

            return attrib.Description;
        }
    }
    public static T GetAttribute<T>(Enum enumObj)
        where T : EnumDescriptionAttribute
    {
        FieldInfo fieldInfo = enumObj.GetType().GetField(enumObj.ToString());
        object[] attribArray = fieldInfo.GetCustomAttributes(false);
        if (attribArray.Length == 0)
            return default(T);
        else
        {
            T attrib = (T)attribArray[0];
            if (attrib != null)
                return attrib;
            else
                return default(T);
        }
    }
}

Finally... Let's see it all together

To get a string description, we can simple code this:

string desc =
    EnumDescriptionAttribute.GetEnumDescription(EmployeeType.DepartmentManager);

To get a ManagerAttribute, we can code this:

ManagerAttribute manager =
    EnumDescriptionAttribute.GetAttribute<ManagerAttribute>(
    EmployeeType.DepartmentManager);

Console.WriteLine("Manager: {0}, Min Salary: {1}, Max Salary {2}",
    attrib.Description,
    manager.MinSalary,
    manager.MaxSalary);

Now you can see that you can use attributes to associate addtional information to an element of an enum.

Conclusion

Okay, so you can see that it is not hard to associate additional information to your enumeration element by simply using some attributes and reflection. However, it is important to note that I do not believe attributes should replace common business objects. I simply wanted to show that an enum does not have to only represent an integral value. As you read in this article, you can associate your enum to a string or any other class. One of the nice advantages of using attributes is that it is easy to implement and it makes the code readable. You can see how readable the ManagerType enumeration is with the implementation of the ManagerAttribute. It is easy to know exactly what each enumeration item contains. I hope you enjoyed reading this article, and I welcome all comments or questions about it.

Asynchronous Method Invocation

2007-11-12T09:55:00.000-08:00

Introduction

In this article, I am going to explain asynchronous method calls and how to use them. After playing with delegates, threads, and asynchronous invocation for so long, it would be a sin not to share some of my wisdom and knowledge on the subject, so hopefully, you won’t be looking at an MSDN article at 1 AM wondering why you decided to go into computers. I will try to use baby steps and lots of examples… Overall, I will cover how to call methods asynchronously, how to pass parameters to such methods, and how to find out when a method completes execution. Finally, I will show the Command Pattern in use for simplifying some of the code. The big advantage with .NET asynchronous method invocation is that you can take any method you have in your project, and you can call it asynchronously without touching the code of your method. Although most of the magic is within the .NET framework, it is important to see what is going on in the back, and that’s what we are going to study here.

Synchronous vs. Asynchronous

Let me try to explain synchronous and asynchronous method invocations with an example, because I know people on The Code Project like to see code and not read War and Peace (not that I have anything against this book).

Synchronous method invocation

Suppose we have a function Foo() that takes 10 seconds to execute.

private void Foo()
{
    // sleep for 10 seconds.
    Thread.Sleep(10000);
}

Normally, when your application calls the function Foo(), it will need to wait 10 seconds until Foo() is finished and control is returned to the calling thread. Now, suppose you want to call Foo() 100 times, then we know that it would take 1000 seconds for the control to return to the calling thread. This type of a method invocation is Synchronous.

Call Foo()
Foo() is executed
Control goes back to the calling thread

Let's now call Foo() using delegates because most of the work we will do here is based on delegates. Luckily for us, there is already a delegate within the .NET framework that allows us to call a function that takes no parameter and has no return value. The delegate is called MethodeInvoker. Let's play with it a little.

// create a delegate of MethodInvoker poiting
// to our Foo() function.
MethodInvoker simpleDelegate = new MethodInvoker(Foo);

// Calling Foo
simpleDelegate.Invoke();

Even with the example above, we are still calling Foo() synchronously. The calling thread still needs to wait for the Invoke() function to complete until the control is returned to the calling thread.

Asynchronous method invocation

But what if I wanted to call Foo() and not wait for it to finish executing? In fact, to make things interesting, what if I didn’t care when it is finished? Let’s say, I just wanted to call Foo 100 times without waiting for any of the function calls to complete. Basically, doing something called Fire and Forget. You call the function, you don’t wait for it, and you just forget about it. And… let’s not forget! I am not willing to change a line of code in my super complicated fancy Foo() function.

// create a delegate of MethodInvoker poiting to
// our Foo function.
MethodInvoker simpleDelegate = new MethodInvoker(Foo);

// Calling Foo Async
for(int i=0; i<100; i++)
    simpleDelegate.BeginInvoke(null, null);

Let me make a few comments about the code above.

Notice that BeginInvoke() is the line of code that executes the Foo() function. However, the control is returned to the caller right away, without waiting for Foo() to complete.
The code above does not know when a call to Foo() completes, I will cover that later.
BeginInvoke() is used instead of Invoke(). For now, don’t worry about the parameters this function takes; I will cover that in more detail later.

What is the magic that .NET is doing in the background

Once you ask the framework to call something asynchronously, it needs a thread to do the work. It can not be the current thread, because that would make the invocation synchronous (blocking). Instead, the runtime queues a request to execute the function on a thread from the .NET Thread Pool. You don’t really need to code anything for it, all of it happens in the background. But, just because it is all transparent doesn’t mean you should care about it. There are a few things to remember:

Foo() is executed on a separate thread, a thread that belongs to the .NET Thread Pool.
A .NET Thread Pool normally has 25 threads in it (you can change that limit), and each time Foo() is called, it is going to be executed on one of these threads. You can't control which one.
The Thread Pool has its limits! Once all the threads are used, an async method invocation is queued until one of the threads from the pool is freed. This is called Thread Pool Starvation, and normally when it comes to that, performance is compromised.

Don’t dive too deep into the thread pool, you might run out of oxygen!

So, let's see an example of when the Thread Pool is starved. Let's modify our Foo function to wait for 30 seconds, and also let it report the following:

Number of avaible threads on the pool
If the thread is on the thread pool
The thread ID.

We know that initially the thread pool contains 25 threads, so I am going to call my Foo function asynchronously 30 times (to see what happens after the 25^th call).

private void CallFoo30AsyncTimes()
{
    // create a delegate of MethodInvoker
    // poiting to our Foo function.
    MethodInvoker simpleDelegate =
        new MethodInvoker(Foo);

    // Calling Foo Async 30 times.
    for (int i = 0; i < 30; i++)
    {
         // call Foo()
        simpleDelegate.BeginInvoke(null, null);
    }
}

private void Foo()
{
    int intAvailableThreads, intAvailableIoAsynThreds;

    // ask the number of avaialbe threads on the pool,
    //we really only care about the first parameter.
    ThreadPool.GetAvailableThreads(out intAvailableThreads,
            out intAvailableIoAsynThreds);

    // build a message to log
    string strMessage =
        String.Format(@"Is Thread Pool: {1},
            Thread Id: {2} Free Threads {3}",
            Thread.CurrentThread.IsThreadPoolThread.ToString(),
            Thread.CurrentThread.GetHashCode(),
            intAvailableThreads);

    // check if the thread is on the thread pool.
    Trace.WriteLine(strMessage);

    // create a delay...
    Thread.Sleep(30000);

    return;
}

Output window:

Is Thread Pool: True, Thread Id: 7 Free Threads 24
Is Thread Pool: True, Thread Id: 12 Free Threads 23
Is Thread Pool: True, Thread Id: 13 Free Threads 22
Is Thread Pool: True, Thread Id: 14 Free Threads 21
Is Thread Pool: True, Thread Id: 15 Free Threads 20
Is Thread Pool: True, Thread Id: 16 Free Threads 19
Is Thread Pool: True, Thread Id: 17 Free Threads 18
Is Thread Pool: True, Thread Id: 18 Free Threads 17
Is Thread Pool: True, Thread Id: 19 Free Threads 16
Is Thread Pool: True, Thread Id: 20 Free Threads 15
Is Thread Pool: True, Thread Id: 21 Free Threads 14
Is Thread Pool: True, Thread Id: 22 Free Threads 13
Is Thread Pool: True, Thread Id: 23 Free Threads 12
Is Thread Pool: True, Thread Id: 24 Free Threads 11
Is Thread Pool: True, Thread Id: 25 Free Threads 10
Is Thread Pool: True, Thread Id: 26 Free Threads 9
Is Thread Pool: True, Thread Id: 27 Free Threads 8
Is Thread Pool: True, Thread Id: 28 Free Threads 7
Is Thread Pool: True, Thread Id: 29 Free Threads 6
Is Thread Pool: True, Thread Id: 30 Free Threads 5
Is Thread Pool: True, Thread Id: 31 Free Threads 4
Is Thread Pool: True, Thread Id: 32 Free Threads 3
Is Thread Pool: True, Thread Id: 33 Free Threads 2
Is Thread Pool: True, Thread Id: 34 Free Threads 1
Is Thread Pool: True, Thread Id: 35 Free Threads 0
Is Thread Pool: True, Thread Id: 7 Free Threads 0
Is Thread Pool: True, Thread Id: 12 Free Threads 0
Is Thread Pool: True, Thread Id: 13 Free Threads 0
Is Thread Pool: True, Thread Id: 14 Free Threads 0
Is Thread Pool: True, Thread Id: 15 Free Threads 0

Let’s make a few notes about the output:

Notice, first of all, that all the threads are on the thread pool.
Notice that each time Foo is called, another thread ID is assigned. However, you can see that some of the threads are recycled.
After calling Foo() 25 times, you can see that there are no more free threads on the pool. At this point, the application “waits” for a free thread.
Once a thread is freed, the program grabs it right away, calling Foo(), and still there are 0 free threads on the pool. This continues to happen until Foo() is called 30 times.

So right away, not doing anything too fancy, we can make a few comments about calling methods asynchronously.

Know that your code will run in a separate thread, so some thread safety issues may apply. This is a topic on its own, and I will not cover it here.
Remember that the pool has its limits. If you plan to call many functions asynchronously and if they take a long time to execute, Thread Pool Starvation might occur.

BeginInvoke() and EndInvoke()

So far we saw how to invoke a method without really knowing when it is finished. But with EndInvoke(), it is possible to do a few more things. First of all, EndInvoke will block until your function completes execution; so, calling BeginInvoke followed by EndInvoke is really almost like calling the function in a blocking mode (because the EndInvoke will wait until the function completes). But, how does the .NET runtime know how to bind a BeginInvoke with an EndInvoke? Well, that’s where IAsyncResult comes in. When calling BegineInvoke, the return object is an object of type IAsyncResult; it is the glue that allows the framework to track your function execution. Think of it like a little tag to let you know what is going on with your function. With this little powerful super tag, you can find out when your function completes execution, and you can also use this tag to attach any state object you might want to pass to your function. Okay! Let’s see some examples so this doesn't become too confusing... Let's create a new Foo function.

private void FooOneSecond()
{
    // sleep for one second!
    Thread.Sleep(1000);
}

private void UsingEndInvoke()
{
    // create a delegate of MethodInvoker poiting to our Foo function.
    MethodInvoker simpleDelegate = new MethodInvoker(FooOneSecond);

    // start FooOneSecond, but pass it some data this time!
    // look at the second parameter
    IAsyncResult tag =
        simpleDelegate.BeginInvoke(null, "passing some state");

    // program will block until FooOneSecond is complete!
    simpleDelegate.EndInvoke(tag);

    // once EndInvoke is complete, get the state object
    string strState = (string)tag.AsyncState;

    // write the state object
    Trace.WriteLine("State When Calling EndInvoke: "
        + tag.AsyncState.ToString());
}

What about Exceptions, how do I catch them?

Now, let's make it a little more complicated. Let me modify the FooOneSecond function and make it throw an exception. Now, you should be wondering how you will catch this exception. In the BeginInvoke, or in the EndInvoke? Or is it even possible to catch this exception? Well, it is not in the BeginInvoke. The job of BeginInvoke is to simply start the function on the ThreadPool. It is really the job of the EndInvoke to report all the information about the completion of the function, and this includes exceptions. Notice the next snippet of code:

private void FooOneSecond()
{
    // sleep for one second!
    Thread.Sleep(1000);
    // throw an exception
    throw new Exception("Exception from FooOneSecond");
}

Now, let's call FooOneSecond and see if we can catch the exception.

private void UsingEndInvoke()
{
    // create a delegate of MethodInvoker poiting
    // to our Foo function.
    MethodInvoker simpleDelegate =
        new MethodInvoker(FooOneSecond);

    // start FooOneSecond, but pass it some data this time!
    // look at the second parameter
    IAsyncResult tag = simpleDelegate.BeginInvoke(null, "passing some state");

    try
    {
        // program will block until FooOneSecond is complete!
        simpleDelegate.EndInvoke(tag);
    }
    catch (Exception e)
    {
        // it is here we can catch the exception
        Trace.WriteLine(e.Message);
    }

    // once EndInvoke is complete, get the state object
    string strState = (string)tag.AsyncState;

    // write the state object
    Trace.WriteLine("State When Calling EndInvoke: "
        + tag.AsyncState.ToString());
}

By running the code, you will see that the exception is only thrown and caught when calling EndInvoke. If you decide to never call EndInvoke, then you will not get the exception. However, when running this code within the debugger, depending on your exception settings, your debugger might stop when throwing the exception. But that is the debugger. Using a release version, if you don’t call EndInvoke, you will never get the exception.

Passing parameters to your method

Okay, so calling functions without parameters is not going to take us very far, so I am going to modify my super fancy and sophisticated Foo function to take a few parameters.

private string FooWithParameters(string param1,
               int param2, ArrayList list)
{
    // lets modify the data!
    param1 = "Modify Value for param1";
    param2 = 200;
    list = new ArrayList();

    return "Thank you for reading this article";
}

Let's call FooWithParameters using BeginInvoke and EndInvoke. First of all, before we do anything, we must have a delegate that matches the signature of this method.

public delegate string DelegateWithParameters(string param1,
                       int param2, ArrayList list);

Think of BeginInvoke and EndInvoke as cutting our function into two separate methods. The BeginInvoke is responsible for accepting all the input parameters followed by two additional parameters every BeginInvoke has (callback delegate, and a state object). The EndInvoke is responsible for returning all output parameters (parameters marked with ref or out) and a return value, if there is one. Let's go back into our example to find out what are considered input parameters and what are output parameters. param1, param2, and list are all considered input parameters, and therefore, they will be accepted as arguments to the BeginInvoke method. The return value of type string is considered an output parameter, and therefore, it will be the return type for EndInvoke. The cool thing is that the compiler is able to generate the correct signature for BeginInvoke and EndInvoke based on the declaration of your delegate. Notice that I decided to modify the values of my input parameters just to examine if the behaviour is as I expect it to be without calling BeginInvoke and EndInvoke. I also re-allocate the ArrayList that is passed to a new ArrayList. So, try to guess what the output is going to be...

private void CallFooWithParameters()
{
    // create the paramets to pass to the function
    string strParam1 = "Param1";
    int intValue = 100;
    ArrayList list = new ArrayList();
    list.Add("Item1");

    // create the delegate
    DelegateWithParameters delFoo =
        new DelegateWithParameters(FooWithParameters);

    // call the BeginInvoke function!
    IAsyncResult tag =
        delFoo.BeginInvoke(strParam1, intValue, list, null, null);

    // normally control is returned right away,
    // so you can do other work here...

    // calling end invoke to get the return value
    string strResult = delFoo.EndInvoke(tag);

    // write down the parameters:
    Trace.WriteLine("param1: " + strParam1);
    Trace.WriteLine("param2: " + intValue);
    Trace.WriteLine("ArrayList count: " + list.Count);
}

Let's see our FooWithParameters again, just so you don't need to scroll up.

private string FooWithParameters(string param1,
        int param2, ArrayList list)
{
    // lets modify the data!
    param1 = "Modify Value for param1";
    param2 = 200;
    list = new ArrayList();

    return "Thank you for reading this article";
}

Let me give you the three lines from the output window after calling EndInvoke():

param1: Param1
param2: 100
ArrayList count: 1

Okay, let’s analyze all this. Even when my function modifies the values of the input parameters, we don’t get to see those changes after calling EndInvoke. The string is a mutable type, therefore, a copy of the string is created, and the change is not passed back to the caller. Integers are value types, and they create a copy when passed by value. Finally, re-creating the ArrayList is not returned to the caller because the reference to the ArrayList is passed by value, and in fact, re-creating the ArrayList is simply creating a new allocation for ArrayList assigning the "copied" reference that was passed. In fact, that reference is lost, and normally considered as a memory leak; but luckily for us, the .NET garbage collector will eventually grab it. So, what if we wanted to get back our new allocated ArrayList and the rest of the changes we did to our parameters? What do we need to do? Well, it is simple; we simply have to tag the ArrayList as a ref parameter. Just for fun, let’s also add output parameters just to show how EndInvoke is changed.

private string FooWithOutAndRefParameters(string param1,
        out int param2, ref ArrayList list)
{
    // lets modify the data!
    param1 = "Modify Value for param1";
    param2 = 200;
    list = new ArrayList();

    return "Thank you for reading this article";
}

Let us see what is considered an output parameter and what is considered an input parameter…

Param1 is an input parameter, it will only be accepted within BeginInvoke.
Param2 is input and output; therefore, it will be passed to both BeginInvoke and EndInvoke (EndInvoke will give us the updated value).
list is passed by reference, and therefore, it is too going to be passed to both BeginInvoke and EndInvoke.

Let’s see how our delegate looks like now:

public delegate string DelegateWithOutAndRefParameters(string param1,
                out int param2, ref ArrayList list);

and finally, let's look at the function that calls FooWithOutAndRefParameters:

private void CallFooWithOutAndRefParameters()
{
    // create the paramets to pass to the function
    string strParam1 = "Param1";
    int intValue = 100;
    ArrayList list = new ArrayList();
    list.Add("Item1");

    // create the delegate
    DelegateWithOutAndRefParameters delFoo =
      new DelegateWithOutAndRefParameters(FooWithOutAndRefParameters);

    // call the beginInvoke function!
    IAsyncResult tag =
        delFoo.BeginInvoke(strParam1,
            out intValue,
            ref list,
            null, null);

    // normally control is returned right away,
    // so you can do other work here...

    // calling end invoke notice that intValue and list are passed
    // as arguments because they might be updated within the function.
    string strResult =
        delFoo.EndInvoke(out intValue, ref list, tag);

    // write down the parameters:
    Trace.WriteLine("param1: " + strParam1);
    Trace.WriteLine("param2: " + intValue);
    Trace.WriteLine("ArrayList count: " + list.Count);
    Trace.WriteLine("return value: " + strResult);
}

Here is the output:

param1: Param1
param2: 200
ArrayList count: 0
return value: Thank you for reading this article

Notice that param1 does not change. It is an input parameter, and param2 was passed as an output parameter and was updated to 200. The array list has been reallocated, and now we see that it is pointing to a new reference of zero elements (the original reference is lost). I hope that now you understand how parameters are passed with BeginInvoke and EndInvoke. Let’s move on to looking at how to be notified if a non-blocking function is completed.

What they don’t want you to know about IAsyncResult

You should be wondering how EndInvoke is able to give us the output parameters and the updated ref parameters. Or, better yet, how EndInvoke is able to throw that exception we threw in our function. For example, say we called BegineInvoke on Foo, and then Foo finished executing, and now, we normally would call EndInvoke, but what if we decide to call EndInvoke 20 minutes after Foo is finished? Notice that EndInvoke will still give you those output or ref parameters, and it would still throw that exception (if one was thrown). So, where is all that information stored? How come EndInvoke is able to get all that data long after the function is completed? Well… the key is with the IAsyncResult object! I decided to explore this object a little more, and as I suspected, it is this object that keeps all the information regarding your function call. Notice that EndInvoke takes one parameter, it is an object of type IAsyncResult. This object contains information such as:

Is the function completed?
A reference to the delegate used for BeginInvoke
All output parameters and their values
All ref parameters and their updated values
Return value
An Exception if one was thrown
And more…

IAsyncResult may seem very innocent, because it is just an interface to a few little properties, but in fact, it is an object of type System.Runtime.Remoting.Messaging.AsyncResult.

Now, if we dig a little deeper, we will find that AsyncResult contains an object called _replyMsg of type System.Runtime.Remoting.Messaging.ReturnMessage, and what do you know… the holy grail has been found!

I had to shrink the above image so you won’t need to scroll to the right to read it, you can simply click on the image to view it

We can clearly see our return value, our output parameter, and our ref parameters. There is even an exception property to hold the exception. Notice that I expanded, in the debug window for OutArgs to show, the value 200 and a reference to the newly allocated ArrayList. You can also see in the property ReturnValue, the string “Thank you for reading this article”. If we had an exception, then the EndInvoke would throw it for us to catch it. I think this is proof enough to conclude that all the information regarding your function call is saved with that little IAsyncResult object you get back from BeginInvoke, it is like a key to your data. If we lose this object, we will never know our output parameters, ref parameters, and return value. It will also not be possible to catch an exception without this object. It’s the key! You lose it, and the info is lost forever in the maze of the .NET runtime… OK, getting a little carried away here. I think I made my point.

Using the Callback delegate, Hollywood style "Don’t call me I will call you!"

At this point, you should understand how parameters can be passed, how to pass state, and understand the fact that your method is executed on a thread within the ThreadPool. The only thing I didn’t really cover is the idea of being notified when the method is finished executing. After all, blocking and waiting for the method to finish does not accomplish much. In order to be notified when a method is complete, you must supply a callback delegate on the BeginInvoke. OK, example! Look at the following two functions:

private void CallFooWithOutAndRefParametersWithCallback()
{
    // create the paramets to pass to the function
    string strParam1 = "Param1";
    int intValue = 100;
    ArrayList list = new ArrayList();
    list.Add("Item1");

    // create the delegate
    DelegateWithOutAndRefParameters delFoo =
        new DelegateWithOutAndRefParameters(FooWithOutAndRefParameters);

    delFoo.BeginInvoke(strParam1,
        out intValue,
        ref list,
        new AsyncCallback(CallBack), // callback delegate!
        null);
}

private void CallBack(IAsyncResult ar)
{
    // define the output parameter
    int intOutputValue;
    ArrayList list = null;

    // first case IAsyncResult to an AsyncResult object, so we can get the
    // delegate that was used to call the function.
    AsyncResult result = (AsyncResult)ar;

    // grab the delegate
    DelegateWithOutAndRefParameters del =
        (DelegateWithOutAndRefParameters) result.AsyncDelegate;

    // now that we have the delegate,
    // we must call EndInvoke on it, so we can get all
    // the information about our method call.

    string strReturnValue = del.EndInvoke(out intOutputValue,
        ref list, ar);
}

In here, you can see that we passed a delegate to the function CallBack when calling BeginInvoke. .NET will call us when the method FooWithOutAndRefParameters completes execution. As before, we all know that we must call EndInvoke if we want to get our output parameters. Notice that in order to call EndInvoke, I needed to do some gymnastics to get the delegate.

AsyncResult result = (AsyncResult)ar;
// grab the delegate
DelegateWithOutAndRefParameters del =
    (DelegateWithOutAndRefParameters) result.AsyncDelegate;

Wait a minute! On which thread is the call-back executed on?

After all, the callback is invoked by .NET using your delegate, but still it is .NET that calls this delegate. It is your right and duty to know on which thread your code is executed on. To give a clear picture of what is going on, I decided to yet again modify my Foo function to include thread information and add a delay of 4 seconds.

private string FooWithOutAndRefParameters(string param1,
        out int param2, ref ArrayList list)
{
    // log thread information
    Trace.WriteLine("In FooWithOutAndRefParameters: Thread Pool? "
        + Thread.CurrentThread.IsThreadPoolThread.ToString() +
        " Thread Id: " + Thread.CurrentThread.GetHashCode());

    // wait for 4 seconds as if this functions takes a while to run.
    Thread.Sleep(4000);

    // lets modify the data!
    param1 = "Modify Value for param1";
    param2 = 200;
    list = new ArrayList();

    return "Thank you for reading this article";
}

I also added thread information to the callback function:

private void CallBack(IAsyncResult ar)
{
    // which thread are we on?
    Trace.WriteLine("In Callback: Thread Pool? "
        + Thread.CurrentThread.IsThreadPoolThread.ToString() +
        " Thread Id: " + Thread.CurrentThread.GetHashCode());

    // define the output parameter
    int intOutputValue;
    ArrayList list = null;

    // first case IAsyncResult to an AsyncResult object,
    // so we can get the delegate that was used to call the function.
    AsyncResult result = (AsyncResult)ar;

    // grab the delegate
    DelegateWithOutAndRefParameters del =
        (DelegateWithOutAndRefParameters) result.AsyncDelegate;

    // now that we have the delegate, we must call EndInvoke on it, so we
    // can get all the information about our method call.
    string strReturnValue = del.EndInvoke(out intOutputValue, ref list, ar);
}

I decided to execute FooWithOutAndRefParameters multiple times, using a button on my form.

private void button4_Click(object sender, EventArgs e)
{
    CallFooWithOutAndRefParametersWithCallback();
}

Let’s see the output after pressing my button thrice (calling the function thrice):

In FooWithOutAndRefParameters: Thread Pool? True Thread Id: 7
In FooWithOutAndRefParameters: Thread Pool? True Thread Id: 12
In FooWithOutAndRefParameters: Thread Pool? True Thread Id: 13
In Callback: Thread Pool? True Thread Id: 7
In Callback: Thread Pool? True Thread Id: 12
In Callback: Thread Pool? True Thread Id: 13

Notice that my Foo function is executed thrice, one after the other, on three separate threads. All the threads are on the thread pool. Notice also that the callback is also executed thrice, respectively, and they are all on the thread pool too. What makes this interesting is that, the callback seems to be executed on the same thread ID as Foo. Thread 7 executes Foo; 4 seconds later, the callback is also executed on thread 7. The same with thread 12 and 13. It is like the callback is a continuation of my Foo function. I pressed my button many times, trying to see if the callback will ever be called on a thread Id other then the one Foo is executed on, I was not able to achieve that. If you think about it, it makes total sense. Imagine, .NET would grab a thread to call Foo and then grab another thread to call the callback, that would be a waste! Not to mention that if your thread pool is starved, you will end up waiting for a free thread just to call the callback! That would have been a disaster.

Using the Command Pattern to clean things up!

Okay! Let's face it, things are getting a little messy. We have a BeginInvoke, EndInvoke, a callback, and they are all over the place! Let's try to use the Command Pattern to clean up the method invocation. Using the Command Pattern is simple and easy. Basically, you create a Command object that implements a simple interface like:

public interface ICommand
{
    void Execute();
}

It it time that we stop using our useless Foo function everywhere, and try to do something more real! So, let's create a scenario that is more realistic. Say, we have the following:

We have a user Form that contains a grid that displays customer rows.
The Grid is updated with rows based on a search criteria of customer ID. However, the database is far, far away, and it takes 5 seconds to get the customer dataset; we do not wish to block the UI while we are waiting.
We have a nice business object that is responsible to get our customer dataset based on a customer ID.

Suppose this was our Business Layer. To keep the example simple, I hard-coded what would normally come from a data layer.

public class BoCustomer
{
    public DataSet GetCustomer(int intCustomerId)
    {
        // call data layer and get customer information
        DataSet ds = new DataSet();
        DataTable dt = new DataTable("Customer");
        dt.Columns.Add("Id", typeof(int));
        dt.Columns.Add("FirstName", typeof(string));
        dt.Columns.Add("LastName", typeof(string));

        dt.Rows.Add(intCustomerId, "Mike", "Peretz");
        ds.Tables.Add(dt);

        // lets make this take some time...
        System.Threading.Thread.Sleep(2000);
        return ds;
    }
}

Now, let's create our Command, which is responsible to update the grid based on the customer ID.

public class GetCustomerByIdCommand : ICommand
{
    private GetCustomerByIdDelegate m_invokeMe;
    private DataGridView m_grid;
    private int m_intCustmerId;

    // notice that the delegate is private,
    // only the command can use it.
    private delegate DataSet GetCustomerByIdDelegate(int intCustId);

    public GetCustomerByIdCommand(BoCustomer boCustomer,
        DataGridView grid,
        int intCustId)
    {
        m_grid = grid;
        m_intCustmerId = intCustId;

        // setup the delegate to call
        m_invokeMe =
            new GetCustomerByIdDelegate(boCustomer.GetCustomer);
    }

    public void Execute()
    {
        // call the method on the thread pool
        m_invokeMe.BeginInvoke(m_intCustmerId,
            this.CallBack, // callback!
            null);
    }

    private void CallBack(IAsyncResult ar)
    {
        // get the dataset as output
        DataSet ds = m_invokeMe.EndInvoke(ar);

        // update the grid a thread safe fasion!
        MethodInvoker updateGrid = delegate
        {
            m_grid.DataSource = ds.Tables[0];
        };

        if (m_grid.InvokeRequired)
            m_grid.Invoke(updateGrid);
        else
            updateGrid();
    }
}

Notice that the GetCustomerByIdCommand takes all the information it needs to execute the command.

The grid to update.
The customer ID to search.
A reference to the business layer.

Also notice that the delegate is hidden within the Command object, so the client doesn’t need to know the inner working of the Command. All the client needs to do is build the Command and call Execute on it. We all know by now that asynchronous methods invocation is done on the ThreadPool, and we should all know by now that it is not healthy to update the UI from the ThreadPool or any other thread other then the UI thread! So, to fix this problem, we hide this implementation within the Command, and check based on the Grid if InvokeRequired() is true. If it is true, we use Control.Invoke to make sure the call is marshaled to the UI thread. (Notice, I am using the .NET 2.0 features of creating anonymous methods.) Let's see how the form is creating the command and executing it!

private ICommand m_cmdGetCustById;
private void button1_Click(object sender, EventArgs e)
{
    // get the custmer id from the screen
    int intCustId = Convert.ToInt32(m_txtCustId.Text);

    // use the buisness layer to get the data
    BoCustomer bo = new BoCustomer();

    // create a command that has all the tools to update the grid
    m_cmdGetCustById = new GetCustomerByIdCommand(
        bo, m_grid, intCustId);

    // call the command in a non blocking mode.
    m_cmdGetCustById.Execute();
}

Notice, that Execute is non-blocking. But before you go nuts and create a million command classes, keep these in mind:

The Command Pattern may cause class explosion, so choose your weapon wisely.
In my case, it would have been easy to create a base class to my command that has the logic to update a grid in a thread-safe manner, but I kept my example simple.
It would also be acceptable to pass the TextBox into the command object so it can grab the input in a more dynamic way and allow the command to be called anytime without re-creating it.
Notice that the delegate, BeginInvoke, EndInvoke, callback, and our crazy code to make sure the UI is updated in a thread safe manner is all encapsulated in my Command, which is a good thing!

Conclusion

Phew! It took me almost a week to write this fun article. I tried to cover all the important aspects of calling a method in a non-blocking mode. Here are a few things to remember:

Delegates will contain the correct signature for BeginInvoke and EndInvoke, you should expect all output parameters and exceptions to come out when calling EndInvoke.
Don’t forget you take juice from the ThreadPool when using BeginInvoke, so don’t overdue it!
If you plan to use a callback, it might be a good idea to use the Command Pattern to hide all the nasty code that goes with it.
Personally, the UI should only be blocked when doing UI stuff, so now you have no excuse!

Thank you for reading, have a wonderful day, and happy .NET coding everyone!