Tuesday, 5 June 2012

Living with async

I was watching once again The zen of async: Best practices for best performance talk of Stephen Toub’s on //Build and I decided I should blog about how easy is to end up with a deadlock while writing asynchronous code with new C# 5.0 language features (AKA async/await). Here is the quick background first which I was aware of before I watch this talk. The talk that Toub has given was mostly about how you create better reusable libraries with asynchronous language features but there are lots of great information concerning application level code.

When you are awaiting on a method with await keyword, compile generates bunch of code in behalf you. One of the purposes of this is to handle synchronization with the UI thread. The key component of this feature is the SynchronizationContext.Current which gets the synchronization context for the current thread. SynchronizationContext.Current is populated depending on the environment you are in. For example, if you are on a WPF application, SynchronizationContext.Current will be a type of DispatcherSynchronizationContext. In an ASP.NET application, this will be an instance of AspNetSynchronizationContext which is not publicly available and not meant for external consumption. SynchronizationContext has virtual Post method which dispatches an asynchronous message to a synchronization context when overridden in a derived class. When you give this method a delegate, this delegate will be marshaled back to the UI thread and invoked on that UI thread.

The GetAwaiter method (yes, "waiter" joke is proper here) of Task looks up for SynchronizationContext.Current. If current synchronization context is not null, the continuation that gets passed to that awaiter will get posted back to that synchronization context. This feature is a great feature when we are writing application level code but it turns out that if we are not careful enough, we might end up with a deadlock because of this. Here is how:

This is a part of the slide from that talk and shows how we can end up with a deadlock. Task has a method named Wait which hangs on the task till it completes. This method is an evil method in my opinion but I am sure that there is a good reason why it is provided. You never ever want to use this method. But, assume that you did use it on a method which returns a Task or Task<T> for some T and uses await inside it to await another task, you will end up with a deadlock if you are not careful. The picture explains how that can happen but let’s recap with an example.

class HomeController : Controller
    public ActionResult Index() 
        return View();

    private async Task doWorkAsync() 
        await Task.Delay(500);

The above code has an ASP.NET MVC 4 asynchronous action method (I am using .NET 4.5 here) which consumes the private doWorkAsync method. I used ASP.NET MVC here but everything applies for ASP.NET Web API asynchronous action methods as well. Inside the doWorkAsync method, we used Delay method of Task to demonstrate but this could be any method which returns a Task or Task<T>. inside the Index action method, we invoke the Wait method on the task which we got from doWorkAsync method to ensure that we won’t go further unless the operation completes and the interesting part happens right here. At that point we block the UI thread at the same time. When eventually the Task.Delay method completes in the threadpool, it is going to invoke the continuation to post back to the UI thread because SynchronizationContext.Current is available and captured. But there is a problem here: the UI thread is blocked. Say hello to our deadlock!
When you run the application, you will see that the web page will never come back. Solution to this problem is so simple: don’t use the Wait method. The code you should be writing should be as follows:
class HomeController : Controller 

   public async Task<ActionResult> Index() 
      await doWorkAsync();
      return View();

   private async Task doWorkAsync() 
      var task = Task.Delay(500);

But if you have to use it for some weird reasons, there is another method named ConfigureAwait on Task which you can configure not to use the captured context.

class HomeController : Controller 

   public ActionResult Index() 
      return View();

    private async Task doWorkAsync() 
      var task = Task.Delay(500);
      await task.ConfigureAwait(continueOnCapturedContext: false);

Very nice little and tricky information but a lifesaver.

Wednesday, 21 March 2012

WCF or ASP .NET 4.5 Web API

A couple of weeks ago (around Feb. 16) the WCF WebAPIs - a framework for building RESTful/Hypermedia/HTTP services, which was in development over the past 1.5 years as a side-project on CodePlex, has been formally integrated into ASP.NET and its name changed to the ASP.NET Web API.
These past two weeks, there has been a lot of questions among WCF developers: What does it mean that the Web APIs are no longer a part of WCF – is WCF dead? Has SOAP gone bankrupted? is HTTP the new way to go for interoperability?
To get a better understanding of what happened and what is the way to go, we need to answer a couple of questions:
  1. What is the purpose of the WebAPIs?
  2. Why do we need HTTP services? What’s wrong with SOAP-over-HTTP?
  3. Why did the WebAPIs move from WCF to ASP.NET MVC?
  4. Is there still a use for WCF? When should I choose Web APIs over WCF?
What is the purpose of the WebAPIs?
When WCF was conceived back in its Indigo and .NET 3 days, the main goal was to support SOAP + WS-* over a wide variety of transports. However, over time it became clear that although SOAP is wide spread and supported on many platforms, it is not the only way to go when creating services. There is also a need to also support non-SOAP services, especially over HTTP, where you can harness the power of the HTTP protocol to create HTTP services: services that are activated by simple GET requests, or by passing plain XML over POST, and respond with non-SOAP content such as plain XML, a JSON string, or any other content that can be used by the consumer. Support for non-SOAP services was very much needed in WCF back then, mostly because some clients, such as web browsers, were not that suitable to handle SOAP messages (plenty of XML parsing and DOM manipulation).
So in WCF 3.5 we got the WebHttpBinding – a new binding that helped us create this kind of non-SOAP service over HTTP, better known as a RESTful service.
The WebHttpBinding was not enough, and after WCF 3.5 was released, a new set of tools was created – the WCF REST Starter Kit. The REST starter kit was an attempt to enrich the support of WCF 3.5 for HTTP services – add better client-side support for .NET apps, extend the server side support for other content types, enable response and request caching, inspection of messages and so forth. Unfortunately, this great toolkit was never officially released and ended its product cycle as “Preview 2”, although it’s still being used today in some of Microsoft’s products that are built with .NET 3.5.
Although not released, some of the service-side features of the REST starter kit were integrated into WCF 4 – we didn’t get any of the client-side libraries, but we did get most of the service-side features (excluding the new inspectors). Some were well-integrated into WCF while others required the use of ASP.NET (by turning on the ASP.NET compatibility mode).
So with WCF 4 we had some support for “Web” HTTP services, but it wasn’t that perfect – to get some of the features you needed IIS hosting and ASP.NET, not all types of requests were supported easily (ever tried posting HTML form data to a WCF HTTP service?), the overuse of CLR attributes to define the POST/GET/PUT/DELETE was tedious, not to mention the configuration required to create this type of services with all of the endpoint behavior. And even after all of that we didn’t actually get full control over the HTTP messages.
That was the main goal of the Web APIs, known back then as the WCF Web APIs: to stop looking at HTTP through the eyes of WCF - as just a transport protocol to pass requests. Rather, it allows us to look at it as the real application-level protocol it is – a rich, interoperable, resource-oriented protocol. The purpose of the Web APIs was to properly use URIs, HTTP headers, and body to create HTTP services for the web, and for everyone else that wished to embrace HTTP as its protocol and lifelong friend.
Why do we need REST HTTP services? What’s wrong with SOAP-over-HTTP?
The world of SOAP and the world of HTTP services are very different. SOAP allows us to place all the knowledge required by our service in the message itself, disregarding its transport protocol, whether it is TCP, HTTP, UDP, PGM, Named Pipes… But unlike TCP, UDP and the other level 4-5 protocols, HTTP is an application-level protocol, and as such it offers a wide variety of features:
  • It supports verbs that define the action - query information using GET, place new information and update existing using POST or PUT, remove information using DELETE etc.
  • It contains message headers that are very meaningful and descriptive - headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
  • It contains a body that can be used for any type of content, not just XML content as SOAP enforces (and if you want something else – encode it to base64 strings and place it in the SOAP’s XML content). The body of HTTP messages can be anything you want – HTML, plain XML, JSON, binary files (images, videos, documents…) …
  • It uses URIs for identifying both information paths (resources) and actions – the URI templates initiative is catching on and is rapidly becoming the standard way of representing requests for resources and hypermediaURIs.
The use of HTTP has evolved over the years. Application-level protocol architectural styles such as REST Hypermedia APIs have emerged on top of HTTP. These, in turn, harness the power of HTTP to create resource-oriented services, and better define the stateless interaction between clients and services.
The Web APIs therefore were intended to allow all of these approaches – you can use it to create HTTP services that only use the standard HTTP concepts (URIs and verbs), and to to create services that use more advanced HTTP features – request/response headers, hypermedia concepts etc.
So HTTP is a lot more than a transport protocol. It is an application-level protocol, and the fact is that although many platforms know how to use SOAP, many more platforms know how to use HTTP! among the HTTP supporting platforms which do not support SOAP that well are the browsers – probably the most important platforms for web developers (and users). And if you don’t believe me that REST and hypermedia are useful, maybe Martin Fowler can convince youbetter than me.
This, of course, does not mean that SOAP is redundant – SOAP is still useful for building messages when you don’t have an alternative application-level protocol at your disposal, or when you want to use SOAP across the board while considering HTTP as no more than another way to pass messages (for example, use HTTP because it can cross firewalls more easily than TCP).
Why did the WebAPIs move from WCF to ASP.NET MVC?
Back to the story of WCF and the WCF Web APIs (we are still before the merger). Another goal of the WCF Web APIs was to incorporate known concepts that would help developers to overcome some of the drawbacks they faced with WCF, such as huge configurations, overuse of attributes, and the WCF infrastructure that did not support testing well. Thus the Web APIs used IoC, enabled convention-over-configuration, and tried to offer simpler configuration environment.
The problem was that at that point in time there were several approaches for constructing HTTP services:
  1. WCF with the WebHttp binding and REST support.
  2. The new WCF Web APIs, soon to be ASP.NET Web APIs.
  3. A not-so-new framework, ASP.NET MVC, which took a break from being HTML-oriented (getting requests from HTML pages and returning HTML/JSON) to being Resource-oriented – people started realizing that they can consider controllers as services and use the MVC infrastructure to define the control requests, responses, and better control the HTTP message.
  4. Open source frameworks such as OpenRasta and ServiceStack.
In addition to that, as time passed, the WCF Web APIs had a lot of trouble adapting WCF to the “native” HTTP world. As WCF was primarily designed for SOAP-based XML messages, and the “open-heart” surgery that was required to make the Web API work as part of WCF was a bit too much (or so I understand from people who were involved in creating the Web APIs). On the other hand, the ASP.NET MVC infrastructure with its elegant handling of HTTP requests and responses, and its support of easy-to-create controllers seemed like the proper way to go for creating this new type of services.
So the fact was we had too many options and therefore too much confusion. What were we to do? We merge teams! (Kind of reminds us of the time of LINQ-to-SQL and Entity Framework, WCF and Ado.Net Data Services and other such examples). So the WCF team and the ASP.NET team joined forces and created a new framework focused on the world of REST/Hypermedia/HTTP services for the web world and thus came out the ASP.NET Web APIs.
I’m still not so sure about the choice of names, as the new Web APIs can also work outside of ASP.NET with the use of WCF, but I guess that the name “WCF ASP.NET Web API” was a bit long. Maybe “WASP Web API”? “WAWAPI” (Wcf Aspnet Web API)? Or maybe simply call it “Hypermedia Web API”?
So this merger is intended to reduce confusion, not induce it. I guess that if it was explained at that time, it might have caused less confusion over time (see the Silverlight is dead slip of PDC 2010). Does Microsoft need a new DevDiv PR team?
Is there still use for WCF? when should I choose Web APIs over WCF?
Recall my points from before - HTTP is a lot more than a transport protocol; use SOAP across the board and consider HTTP as no more than another way to pass messages.
  • If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
  • If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
  • If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
  • If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
I hope this helped you removing some of the confusion over this topic.

Next post I will show how to use Castle Windsor with Web API

Wednesday, 1 February 2012

Small Introduction to NuGet

Not too long ago, Microsoft released, NuGet, an automated package manager for Visual Studio.  NuGet makes it easy to download and install assemblies, and their references, into a Visual Studio project.  These assemblies, which I loosely refer to as packages, are often open source, and include projects such as Nhibernate. In this post, I'll explain how to get started in using NuGet with your projects to include: installng NuGet, installing/uninstalling Nhibernate via console command, and installing/uninstalling Nhibernate via graphical reference menu.

Installing NuGet
The first step you'll need to take is to install NuGet.  Visit the NuGet site, at http://nuget.org/, click on the Install NuGet button, and download the NuGet.Tools.vsix installation file, shown below.

Each browser is different (i.e. FireFox, Chrome, IE, etc), so you might see options to run right away, save to a location, or access to the file through the browser's download manager.  Regardless of how you receive the NuGet installer, execute the downloaded NuGet.Tools.vsix to install Nuget into visual Studio.

The NuGet Footprint
When you open visual Studio, observe that there is a new menu option on the Tools menu, titled Library Package Manager. This is where you use NuGet.  There are two menu options, from the Library Package Manager Menu that you can use: Package Manager Console and Package Manager Settings

I won't discuss Package Manager Settings in this post, except to give you a general idea that, as one of a set of capabilities, it manages the path to the NuGet server, which is already set for you. Another menu, added by the NuGet installer, is Manage Nuget packages, found by opening the context menu for either a Solution Explorer project or a project's References folder or via the Project menu.  I'll discuss how to use this later in the post. The following discussion is concerned with the other menu option, Package Manager Console, which allows you to manage NuGet packages.

Getting a NuGet Package
Selecting Tools -> Library Package Manager -> Package Manager Console opens the Package Manager Console.  As you can see, below, the Package Manager Console is text-based and you'll need to type in commands to work with packages.

In this post, I'll explain how to use the Package Manager Console to install Nhibernate, but there are many more commands, explained in the NuGet PackageManager Console Commands documentation.  To install Nhibernate, open your current project where you want Nhibernate installed, and type the following at the PM> Install-Package nhibernate If all works well, you'll receive a confirmation message, similar to the following, after a brief pause: Successfully installed ‘nhibernate’. Successfully added ‘nhibernate’  to MyApplication Also, observe that a reference to the Nhibernate.dll assembly was added to your current project. Uninstalling a NuGet Package Type in Uninstall-Package Nhibernate and after brief pause, you'll see a confirmation message similar to the following: Successfully removed 'NHibernate' from MyApplication. Successfully uninstalled 'NHibernate'. The following package elements are also removed:
  • References in the project. In Solution Explorer, you no longer see the library in the References folder or the bin folder. (You might have to build the project to see it removed from the bin folder.
  • Files in the solution folder. The folder for the package you removed is deleted from the packages folder. If it is the only package you had installed, the packages folder is also deleted.)
  • Any changes that were made to your app.config or web.config file are undone.

Graphical Installations
As explained earlier, clicking Manage Nuget packages…, from the context menu for either a Solution Explorer project or a project's References folder or via the Project menu opens the Manage Nuget packages window. This window will allow you to add a reference a NuGet package in your project.

To the left of the window are a few accordian folders to help you find packages that are either on-line or already installed.  Just like the previous section, I'll assume you are installing Nhibernate for the first time, so you would select the Online folder and click All. After waiting for package descriptions to download, you'll notice that there are too many to scroll through in a short period of time.  Therefore, use the search box located at the top right corner of the window and type Nhibernate as I've done in the previous figure. You'll see Nhibernate appear in the list. Click the Install button on the Nhibernate entry. If the installation was successful, you'll see a message box display and disappear quickly (or maybe not if your machine is very fast or you blink at that moment).

Then you'll see a reference to the Nhibernate.dll assembly in your project's references list. If you open the Manage Nuget packages window again, you'll see Nhibernate listed in the Recent packages folder.

You can install NuGet via the on-line home page with a click of a button.  Nuget provides two ways to work with packages, via console or graphical window.  While the graphical window is easiest, the console window is more powerful. You can now quickly add project references to many available packages via the NuGet service.

Monday, 5 December 2011

A wonderful weekend

Believe in the community

Last weekend I had a great time. That's thanks to ITPro|Dev Connections conference that took place in Glifada, Greece. It was my first Greek dev conferece as I have only a year and a half that I am back in my country. I never had the chance so far to take a closer look at the community and have a taste of the level and the experience of the developers. I have to admit that I was quite skeptical before going to the event. That's because of my disappointment from the interviews I have conducted for the company I work. There were people that have never heard the term "Design Patterns"!!!

I won't get any deeper to the situation as there are many parts to blame and that is not the point of this post. Maybe I will write one in the future... What I want to point out though is that I have met some people that made me believe once again in the potential of my country. Because these people are GREAT programmers, great entrepreneurs and great minds! I would like to list them here (in alphabetical order) for the world to learn about them and I would like to say to them a huge THANKS as they made me believe once again that coming back to Greece was not a mistake.

Wednesday, 12 October 2011

Book Read: Clean Coder

Being professional coder is harder than you think...

I have again three books that I am hoping to finish this month,  I will start here with one I just finished. It's the Clean Coder from the famous Uncle Bob. I add it on the Software Engineering Books and in my Highly Recommended list. It is a brilliant read. It is not the technical book one might be looking for. For a more technical approach on how to write clean code please read Clean Code (Robert C. Martin) for which I also have a review.
This books is about what a professional coder is about. What behaviors should he follow on his everyday life as a coder on a big or a small firm. A lot of the content sounds obvious when you read it, but it's put together extremely well and will almost certainly relate to issues that you've had to deal with in your career, be it difficult colleagues or untrusting managers. It's easy to read and will probably open your eyes to becoming a more professional software developer who is better able to take responsibility for their work.

I really wish some of the colleagues I had some time ago have read this brilliant book.

Thursday, 15 September 2011

Install Windows 8 Preview in Virtual Machine

Install Windows 8 in VirtualBox


  1. Oracle VM VirtualBox
  2. Windows 8 Developer Preview ISO file (32-bit or 64-bit)
  3. Windows Live ID* (for best testing experience, sign up here if you doesn’t have one)
  4. Internet Connection*
*Nice to have, for best experience
Besides that, also make sure that your computer have the Virtualization Technology (VT-x/AMD-V) activated in the BIOS. Proceed to the installation if you are ready with everything.


1. Get the Oracle VM VirtualBox installed in your PC. (VMWare player is not working but you can use VMWare Workstation 8, released two days ago just for Windows 8.)
2. For setting up the Virtual Machine, use the following settings:
Summary of Virtual Machine
3. Below screenshots show all the settings I used for that Virtual Machine:
It is important to have the chipset to PIIX3 and to check the Enable IO APIC as the installation will fail.
This part is easy. The .vdi will be mount as an IDE Controller and all you need to do is to right click on the IDE Controller and "Add CD/DVD Device". There you should select the iso file you have for the Windows 8 Developer Preview. Note that the type of the IDE Controller has to be PIIX4.

4. Once everything is set, start installing Windows 8! The installation process is pretty much similar to the one in Windows 7, so nothing much there. When Windows 8 started up, you will need to enter your Windows Live ID and password.
5. Finally if you have large screen as I do then in order to support your native resolution you will have to type the following on a command prompt window:

First, enter the below text to change the directory:
 cd C:\Program Files\Oracle\VirtualBox
Then, enter the line: 
VBoxManage setextradata global GUI/MaxGuestResolution any
Lastly, manually enter this line (don’t copy and paste since it can have issue with quotation mark):
 VBoxManage setextradata “VM name” “CustomVideoMode1″ “WidthxHeightxDepth
VM name have to be replaced with your virtual machine name. If your virtual machine is named Windows 8, then it should be “Windows 8″.
WidthxHeightxDepth have to be replaced with your desired resolution. Say if you want to have it running at your monitor native resolution at 1920x1080x32, then it should be “1920x1080x32″.
Now you can start your virtual machine, click on the "Windows Explorer" icon and then right click -> Screen Resolution and on the "Resolution" drop-down you will see the newly create resolution which will work just fine!
Now you are ready to enjoy the new Microsoft beast and try your coding skills in Javascript!
Good luck!

Monday, 12 September 2011

New Page, Recommended Books!

After getting some proper rest during my summer holidays and reading quite a few books (once again) I decided that I should publish my list of all time favorite books which I will continuously update from now on. I am a big fan of physical books and I try to buy my favorite books in physical form so that I can have them all in my room's shelves. The last years though I try to also read e-books as they are cheaper and easier to have with me. I am a big fan of apple books and kindle on iPhone although I have to admit that I would be more happy with a bigger screen. I might give a shot to the real Kindle in the future although I am not sure it's worth the money against an iPad. On the other hand, reading pdfs on my pc get's me soooooooo sleepy, I have never managed to finish a single book like that.

I have two simple rules that i try to follow when reading books:
  1. read at most two books per month and 
  2. read them from start to end. Read ALL of them! 
The last one is an old rule that a friend of mine taught me from my university years. I have followed it since then and I recommend it to anyone seriously interested in learning new technologies and keeping up with computer science.

Enough said... You can find the first edition of my reviews here!