A project I have been working on has required the implementation of asynchronous processing, particularly for long running calls to web services, so I started to investigate the Microsoft Application Block for asynchronous processing, and reading articles on multi-threading and so on. One of the articles I came across was Roy Osherove's blog on implementing the Background Worker process from .NET 2.0 in .NET 1.1. This seemed exactly what I was after, especially once I had read the original article by Joval Löwy, except for three things. There was no mention of how to use this to call a webservice, it was only possible to pass in one argument, so for execution of more complex functions you would have to pass in the arguments as an array, or hashtable, and it was written in C# so I couldn't put it into my code, as the project is in VB.NET. Yes, I know I could reference a C# assembly or project in VB.NET, but it would be cleaner for my solution to port the entire code to VB.NET.
The asynchronous call pattern has been explored many times now in .NET, and is described in detail in such articles as Creating a Simplified Asynchronous Call Pattern for Windows Forms Applications by David Hill.
Whidbey will introduce a component in the
System.ComponentModel namespace called
BackgroundWorker which encapsulates the complexities of asynchronous calls in a simple component which can be invoked from code, or dropped onto Form in the designer. It exposes methods and events for executing the asynchronous function, updating progress, canceling the execution, and completion of the execution.
As mentioned above, Joval Löwy and Roy Osherove have implemented a version of this class in C# for .NET v1.1, which will be sufficient for many people. I have ported in into VB.NET, and added a few tweaks to throw similar exceptions to the Whidbey version, when it is sub-classed. Then I extended it, and demonstrates how to use this to call webservices asynchronously.
Converting to VB.NET
This was not without its quirks.
The best practice for raising events tells us that we should always test that the event is not
null before raising the event. That is to say, the event must have handlers. All the articles then give a code sample something like this:
if(SomeEvent != null)
The C# implementations of
BackgroundWorker both used this standard. But how do I do that in VB.NET? If you try the statement
SomeEvent != Nothing, you get the error: 'Public Event SomeEvent(sender As Object, e As System.EventArgs)' is an event, and cannot be called directly. Use a 'RaiseEvent' statement to raise an event. Not very useful!
It turns out that in VB.NET, to get at the delegate derived object to test if it is
Nothing, you just add "Event" to the end of the event name. Don't go looking for it in intellisense though, because it won't be there! The resulting VB.NET code is:
if Not SomeEventEvent is Nothing Then
Why have I used
SomeEventEvent(Me, args) instead of
RaiseEvent SomeEvent(Me, args)?
The default method of a delegate is the
Invoke method, and
RaiseEvent in VB.NET just calls this method on the delegate, and it makes my code less language specific. Personal preference really.
NB//The source code download includes the VB.NET port and the sub-class I created.
Sub-Classing the BackgroundWorker
This serves two purposes. Firstly, when Whidbey is released, changing over to calling the native
BackgroundWorker will require just eight code changes in the sub-class, and not a swathe of changes across all my application. Secondly, it enables us to add functionality to the
BackgroundWorker, in this case, the ability to pass multiple parameters to the asynchronous function.
Firstly, the three event argument classes,
RunWorkerCompletedEventArgs must all be sub-classed, along with their associated handler delegates. Then the
BackgroundWorker class itself can be sub-classed.
We must handle the underlying events and throw our sub-classed versions.
Public Shadows Event DoWork As DoWorkEventHandler
Public Shadows Event ProgressChanged As ProgressChangedEventHandler
Public Shadows Event RunWorkerCompleted As RunWorkerCompletedEventHandler
DoWork event is the easiest, although you need to be careful to reassign the sub-classed event arguments back to the original event arguments.
Private Sub BackgroundWorker_DoWork(ByVal sender As Object, _
ByVal e As VS2005.DoWorkEventArgs) Handles MyBase.DoWork
If Not DoWorkEvent Is Nothing Then
Dim args As New DoWorkEventArgs(e.Argument)
e.Cancel = args.Cancel
If Not e.Cancel Then
e.Result = args.Result
ProgressChanged event, however, must call a copy of the
ProcessDelegate function from our port of the
Private Sub BackgroundWorker_ProgressChanged(ByVal sender As Object, _
ByVal e As VS2005.ProgressChangedEventArgs) Handles MyBase.ProgressChanged
If Not ProgressChangedEvent Is Nothing Then
Me.ProcessDelegate(ProgressChangedEvent, Me, _
New ProgressChangedEventArgs(e.ProgressPercentage, Nothing))
This is because the Whidbey version does not have this method, so if we call the base class function, then we will lose our ability to upgrade easily.
The worst one however is the
RunWorkerCompleted event. The
RunWorkerCompletedEventArgs class throws an exception if the
Result property is accessed and would return nothing, and we must work around this in order to pass the event arguments into our sub-classed event arguments. Microsoft has changed some of the internal workings of delegates for Whidbey.
In .NET 1.1, the exception causes the callback delegate to be called twice, if we do not handle it. The second time, a new exception is thrown because you cannot call
In Whidbey, the exception will bubble up the call stack until it is handled.
To deal with this, we only read the value of the
Result property if we have not cancelled or erred.
Private Sub BackgroundWorker_RunWorkerCompleted(ByVal sender As Object, _
ByVal e As VS2005.RunWorkerCompletedEventArgs) _
If Not RunWorkerCompletedEvent Is Nothing Then
Dim result As Object = Nothing
If e.Cancelled = False AndAlso e.Error Is Nothing Then
result = e.Result
Me.ProcessDelegate(RunWorkerCompletedEvent, Me, _
New RunWorkerCompletedEventArgs(result, e.Error, e.Cancelled))
Finally, we wanted to extend the class. We do this by simply overloading the
RunWorkerAsync method and passing it a
ParamArray of type
Public Overloads Sub RunWorkerAsync(ByVal ParamArray arguments As Object())
Using the code
Making basic asynchronous calls with this class is a simple matter of hooking up the
RunWorkerCompleted events, then calling the
RunWorkerAsync method as I show in my demo app.
Making asynchronous webservice calls is a little odd however. You hook up the events in the same manner as normal, and in the
DoWork event handler, call the webservice synchronously. This is exactly what happens under the wraps when you call the
EndWebMethod methods produced automatically in the proxy class. It spawns a new thread and makes a normal synchronous call from there.
Of course, the asynchronous thread will be locked up for the duration of the call, so you need to check if there is a cancellation pending when it returns. Your
RunWorkerCompleted handler must ensure that it only does anything if cancelled is
It is impossible to monitor the progress of a webservice call until the data begins to return, at which point you can monitor the progress of receiving the data stream. However, for the purposes of the demo, I just set a timer running which updates the progress bar ten times per second. It's good enough to make users think something is happening, which it is, just not on their machines!