Month: October 2014

In this short code snippet, I want to show a simple technique for ensuring only one instance of your .NET application can run at a time.

The technique is below :

    using System.Threading;
    using System.Windows;

    namespace MyApplication
    {
	    public partial class App : Application
	    {
	        private Mutex _mutex;

	        public App()
	        {
	            bool aIsNewInstance;

	            _mutex = new Mutex(true, @"Global\" + "MyUniqueWPFApplicationName", out aIsNewInstance);

	            GC.KeepAlive(_mutex);

	            if (aIsNewInstance) return;

	            MessageBox.Show("There is already an instance running.",
	                "Instance already running.",
	                MessageBoxButton.OK, MessageBoxImage.Information);

	            Current.Shutdown();
	        }
	    }
    }

What happens is that a Mutex is created when the application starts up and it is given a unique name, in this case, “MyUniqueWPFApplicationName“. If another instance of the application is started up and the Mutex is already created with that name, the application will shut down. You will also notice that there is a prefix to the name (Global\) that makes the unique name global to a sever running terminal services. If you leave off this prefix, then the mutex is considered local.

In a previous article on async and await, I showed a very simple example of how to run some code asynchronously. Then in the 2nd article I showed an example of updating the user interface in the main thread from an async method.

The code below (from the previous article) would execute a long running task which in this case counts to 5,000,000. As the task was running, on a set interval, the UI would be updated. This effectively decoupled the running of the task from the updating of the UI. You could have the task update the UI every 10ms, or you could update every 5 seconds. It really depends on what you are trying to do.

using System;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace WindowsFormsAsync
{
    public partial class Form1 : Form
    {
        private readonly SynchronizationContext synchronizationContext;
        private DateTime previousTime = DateTime.Now;

        public Form1()
        {
            InitializeComponent();
            synchronizationContext = SynchronizationContext.Current;
        }

        private async void ButtonClickHandlerAsync(object sender, EventArgs e)
        {
            button1.Enabled = false;
            var count = 0;

            await Task.Run(() =>
            {
                for (var i = 0; i <= 5000000; i++)
                {
                    UpdateUI(i);
                    count = i;
                }
            });

            label1.Text = @"Counter " + count;
            button1.Enabled = true;
        }

        public void UpdateUI(int value)
        {
            var timeNow = DateTime.Now;

            if ((DateTime.Now - previousTime).Milliseconds <= 50) return;

            synchronizationContext.Post(new SendOrPostCallback(o =>
            {
                label1.Text = @"Counter " + (int)o;
            }), value);             

            previousTime = timeNow;
        }
    }
}

A reader on Reddit suggested that you can write this code in a much more succinct way as shown below. The code is much simpler to see what’s going on, but the behaviour is slightly different. In this example, the code similarly counts upto 5,000,000 and updates the UI label. The await statement here will correctly restore the synchronisation context to update the UI thread which means you don’t have to deal with it manually (I didn’t realise that at the time). To enable the asynchrony of the task in this example we need to have a Task.Delay(1) as we are not using any other asynchronous objects in .NET for file or DB access for example.

In a previous article on async and await, I showed a very simple example of how to run some code asynchronously. In this article, I want to take this a little further with another example.

I have recently had to go and maintain an old c# Winforms application (yes I know winforms is a little old and considered the new vb6 but the application works and still provides value) that needed some new features adding. The problem with this application is that is feels a little sluggish for the user and constantly locks up, or gives the impression that it has crashed which means users have been trying to kill the application when really, it is processing a lot of work and the UI has become unresponsive.

Whilst I was in the code base, I wanted to try and improve some of this unresponsiveness by moving code out into tasks and asynchronously updating the UI. In this article I will cover how to do this.

Example of Unresponsive Application

First lets start with a small example. Below is a screen shot of a very simple winforms app. It doesn’t really do much. When you load it up, you press the button and the application counts to 5,000,000. I want this count to be displayed on the screen.

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }

    private void ButtonClickHandler(object sender, EventArgs e)
    {
        for (var i = 0; i <= 5000000; i++)
        {
            label1.Text = @"Counter = " + i;
        }
    }
}

In the code above, when you click the button in the application it calls the ButtonClickHandler which starts a count to 5,000,000. Inside the for loop we also try to update the text on the label to tell the user how far the count has got.

In this article I want to give a simple example for how to use the async await keywords in C# to create asynchronous background tasks.

Writing multi-threaded or asynchronous code has traditionally always been very hard to get right but is something that is needed to help keep our applications responsive and to avoid performance bottlenecks. C# 5 introduced a simplified model for doing asynchronous programming with the introduction of 2 new keywords, async and await.

If you specify that a method is an asynchronous method by using an async modifier, you enable the following two capabilities.

• The marked async method can use the await keyword to designate suspension points. The await operator tells the compiler that the async method can’t continue past that point until the awaited asynchronous process is complete. In the meantime, control returns to the caller of the async method. The suspension of an async method at an await expression doesn’t constitute an exit from the method, and finally blocks don’t run.

• The marked async method can itself be awaited by methods that call it.

An async method typically contains one or more occurrences of an await operator, but the absence of await expressions doesn’t cause a compiler error. If an async method doesn’t use an await operator to mark a suspension point, the method executes as a synchronous method does, despite the async modifier. The compiler issues a warning for such methods.

Asynchrony is essential for activities that are potentially blocking, such as when your application accesses the web or a file system. Access to a web resource, for example, is sometimes slow or delayed. If such an activity is blocked within a synchronous process, the entire application must wait. In an asynchronous process, the application can continue with other work that doesn’t depend on the web resource until the potentially blocking task finishes.