Yesterday, I gave an overview of the problems that async solves, and how it actually solves them. As we saw in that post, async is remarkably cunning, and can become remarkably tricky to follow when applied in a real application, which naturally makes any decompilation a bit of a challenge. If you haven’t read the previous post on how async works already, I recommend you at least skim through it so that you know what examples we’ll be working with, and so that we’re all working with the same understanding of state machines.
Now, with that introduction done, we should have a look at some real code.
C# 5 has finally arrived, and the biggest new feature in the language is async, and its associated Await (contextual) keyword. Naturally, there’s been a lot of discussion from a lot of different points of view, and we’ve been working hard to make sure .NET Reflector can accurately decompile asynchronous code so that you can start investigating C#5 code right away. Just understanding how async actually works at the front end is no mean feat, and when you bear in mind that we’re juggling up to 3 different compilers, it’s been a fascinating challenge.
Before we dive into how we’re handing async code in Reflector, it’s worth grounding ourselves first. Let’s start with a quick look at what async is designed for, and then we’ll take a deeper dive into the nuts and bolts, and how they apply to us.
Given that .NET 4.5 is available as part of the beta for Dev11, we have added some new support functionality to .NET Reflector (this is already available in our EAP releases).
First, Reflector will now notice if you have .NET 4.5 installed on the machine. As 4.5 is an in-place installation, we notice the presence of certain files to trigger this.
I’m as excited as you by the Windows 8 beta which is being released today. I think it is exciting that the whole API surface of the new WinRT platform is exposed via .NET metadata in the form of .winmd files. We fixed up Reflector some time ago to handle these files, so you can load them individually into Reflector. Yesterday I added the code to 184.108.40.206 to automatically detect the winmd directory (or at least where it was in the //Build preview) and load the set of contained winmd files into the assembly list. So, if you start with an empty assembly list, when you select it you are offered the choice to populate it with all of the winmd files on the machine.
Last month I was fortunate enough to attend Microsoft’s //BUILD/ conference in Anaheim, CA. Those of you who follow my blog on Simple Talk will have noticed that I’ve started to post up my notes in bitesized (ish) chunks.
These are exciting times to be a .NET developer and its easy to see that the .NET platform, along with related technologies such as WinRT and Metro UI, make this arguably the most compelling software development platform available for any form factor or OS. Even the Silverlight developers amongst you shouldn’t be downhearted because although Silverlight may be entering the twilight of its existence (sorry) you’re all in a great position to use your existing skills to develop for Metro and Windows 8 – in fact you probably already have a leg up on the rest of us.
So what does this all mean for Reflector?