The journey towards asynchrony
When we first started working on the current version of Reflector, one of our main objectives was to provide full support for new Microsoft technologies. Since then our team has worked on making Reflector available for Dev11, and compliant with its new visual theming scheme. The async features in the new versions of C# and VB are a major step forward towards asynchrony and its implementation has been made much easier in practice.
With the introduction of the new Async/await keywords and new approach to Task-based programming, we realised that it wouldn’t be long before our users wanted to find out more about what’s happening under the bonnet with the new asynchronous programming model.
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.
We’ve been a bit quiet on the EAP front recently, and there’s a reason for that. The rest of the team and I feel like we’ve spent the last fortnight locked in a meeting room. In hindsight, that’s substantially because we have. All I can see when I close my eyes is post-it notes, but we’re getting a lot closer to scoping out version 8 of Reflector.
V8 is all kinds of exciting, but still very much at the on-paper stage. But somehow, in the midst of all the planning, and sketching, and brainstorming, and well-intentioned bickering, Clive, Nigel, Ruchika, and Nick have shipped a new EAP.
The version 7.6 EAP is the first slice of our support for Visual Studio Dev 11, .NET 4.5, and C# 5
Reflector’s Visual Studio integration is now working in Dev11, so you can decompile code and start to debug it within the new VS beta. You can explore the changes in the .NET 4.5 framework too, and Clive has a blog post coming about this shortly.
Because it’s our first EAP, it’s not all up and running yet. For example, we aren’t currently decompiling the new C# async/await construct, but we’ll be fleshing out the C# 5 support in the coming releases.
To get an idea of what’s planned for Reflector 7.6, take a look at the EAP page
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?