BackgroundWorker vs async/await

Asynchronous programming in .NET framework has evolved significantly over the years. What is fascinating is the simplicity at which developers can achieve the same goal with the latest async/await implementation in .NET Framework 4.5.

The usage of BackgroundWorker class was hugely popular among developers to offload most of the I/O heavy operations to the background thread to free up the UI for better responsiveness. Even though BackgroundWorker was built based on Thread, the Thread specific implementation was hidden from you making the code less complex than plain thread based implentation. Here we deal with DoWork and RunWorkerCompleted event handlers.

The BackgroundWorker class is essentially built on top of the Thread class. The Thread part of the BackgroundWorker is sort of hidden from you. You get to work with two very important parts of the BackgroundWorker though, the DoWork and RunWorkerCompleted events. As illustrated below, you invoke RunWorkerAsync(you can pass the parameters) which then executes the DoWork handler on a different thread. On completion it triggers the RunWorkerCompleted event handler. You can pass the results via EventArgs.

Capture

Capture1

Note that the DoWork event is executed on a different thread. And more importantly, the RunWorkerCompleted event handler runs in this new thread. When using this in UI (which runs in the main thread), you should take care to avoid cross thread exceptions. Also note how the result and states from DoWork event handler is passed on to RunWorkerCompleted using

async/await

Gone are the days of writing those complex code for implementing asynchronous behavior. async and await keywords (C# 5.0) let the implementation of asynchronus operations with much simple code which looks like ‘synchronous coding’. The async and await are based on the Task-based Asynchronous Pattern (TAP) which is the current recommended asynchronous design pattern.

Untitled.pngUntitled1.png

You would agree that the above async/await implementation do not require additional effort to describe or understrood beyond the comments placed there. You get the simlicity of the asynchronous programming and compiler handles the job behind the scenes.

Is that all about the syntax, simplicity? No;  Unlike BackgroundWorker,  async/await does not create a dedicated thread. Instead it makes use of the threadpool as required and no cross thread worries. Note that it would be wrong to compare BackgroundWorker and async/await as as similar ones. While the former one is specialized component for executing part of the code in the background thread, the latter is more flexible mechanism for implementing asynchronus operations.

 

Advertisements

ASP.NET on Linux? – Use Mono Framework

Imagine your team’s primary skillset is on .NET development. You  get requirements for a website and your customer wants to stick with low cost linux/apache hosting solutions.  What will you choose when you weigh the options? – (a) Hiring new talent (b) Training the resources on technologies such as J2EE.  While such a decision is dependent on different factors it is important to know that there is a third option too – the open source Mono Framework !  Mono will let you to develop the applications using .NET and host it on Linux which has Mono framework installed in it.

We have used this model for couple of applications and it works pretty fine.  There were glitches initially but the framewrok is being stabilized as the new versions are out. 

Mono is an open source implementation of Microsoft’s .Net Framework based on the ECMA standards for C# and the Common Language Runtime.

Cross Platform? : This framework is not just for Linux.  Mono runs on Linux, Microsoft Windows, Mac OS X, BSD, and Sun Solaris, Nintendo Wii, Sony PlayStation 3, Apple iPhone. It also runs on x86, x86-64, IA64, PowerPC, SPARC (32), ARM, Alpha, s390, s390x (32 and 64 bits) and more. Developing your application with Mono allows you to run on nearly any computer in existance.

Add-in development for Microsoft Office

It is quite likely that many of you get requirements to extend the MS Office applications’ capabilities based  on your business needs.  Well, we are talking about the .NET development and the framework provides you capabilities for developing Office based solutions using Visual Studio Tools for Office.

This portal (Office Development with Visual Studio) provides many resources related to Office Solutions development using .NET framework including Add-In development for MS Office 2003 and Office 2007 

How does Add-Ins work with MS Word, Excel etc?

Add-ins that are created by using Visual Studio Tools for Office consist of an assembly that is loaded into a Microsoft Office application as an add-in. Add-ins that are created by using Visual Studio Tools for Office have access to the Microsoft .NET Framework as well as the application’s object model. When you build an add-in project, Visual Studio compiles the assembly into a .dll file and creates a separate application manifest file. The application manifest points to the assembly, or to the deployment manifest if the solution uses one.

Visual Studio Tools for Office provides a loader for add-ins that are created by using Visual Studio Tools for Office. This loader is named AddinLoader.dll. When a user starts the Microsoft Office application, this loader starts the common language runtime (CLR) and the Visual Studio Tools for Office runtime, and then loads the add-in assembly. The assembly can capture events that are raised in the application.

The CLR enables the use of managed code that is written in a language supported by the Microsoft .NET Framework. In your solution, you can do the following:

  • Respond to events that are raised in the application itself (for instance, when a user clicks a menu item).
  • Write code against the object model to automate the application.

After the assembly has been loaded, the add-in has access to the application’s objects, such as documents or mail. The managed code communicates with the application’s COM components through the primary interop assembly in your add-in project.