What’s new in C# 5.0 and VB.Net?

As always, Anders Hejlberg’s session at Microsoft’s Build conference was a must-see. He’s a great presenter, and he had some great things to show off.

Anders started off by laying out what’s new in C# 5.0 and VB.Net. Bear in mind that Microsoft now have a policy of language parity for C# and VB.Net. So both languages get Windows Runtime support, Asynchronous programming and a brand new feature, Caller info attributes. VB.Net plays catch-up, and finally gets support for Iterators.

Asynchronous Methods

The first demo in Anders talk was about asynchronous programming. He introduced it by reminding us how vital responsiveness is in touch applications. This was something Jensen Harris mentioned in his talk. Touch User Interfaces are visceral. If an application doesn’t respond immediately when you touch it, it feels dead, whereas using a mouse or keyboard introduces a kind of disconnect between you and the computer which makes delays feel more acceptable.

In the Windows Runtime, the designers took the decision that if an operation was going to take more than 50 milliseconds to complete, it must be implemented asynchronously. There will be no synchronous equivalent – it would make it too easy for developers to do the lazy thing. So, all of a sudden it becomes really important to be able to do asynchronous programming easily.

This is where C# shines in comparison to C++ or Javascript for writing Metro style apps. In those languages, doing asynchronous programming means callbacks, and that means turning your programming inside out. The Asynchronous Methods feature in C# allows you to do async programming in the usual, straightforward, do-this-then-that fashion.

I won’t say any more on that here. Go watch Anders demo if you haven’t groked async yet. Your future as a Windows developer depends on it!

Windows Runtime integration

In the next section of his talk (starting at 26:00), Anders demonstrated more of the deep integration that C# and .Net now has with the Windows Runtime. He showed how it is possible to take a C# “compute engine” and expose it to a HTML/Javascript meto-style app (it works just as well with C++). You can take a C# project, compile to a WinMD file, then reference it from your HTML/Javascript project. This gives you intellisense for your C# objects when you access them from your Javascript code. As Anders said, “In Javascript, you sometimes get lucky. [Beat]. Of course, in C# you get lucky always! … I’m Just saying!”

Caller Info Attributes

The aforementioned Caller info attributes came up next (see video at 32:00). Not a big feature, just a palate cleanser between demos, according to Anders.

Apparently the C# team often get asked when they’re going to introduce support for __FILE__ and __LINE__ macros, which, C++ developers will know, expand when compiled to produce a string containing the name of the current source file, and the current line, respectively. Of course, C# will only introduce support for macros over Ander’s dead body, so the team had to find another way.

Anders related that back in the days of C# 1.0 they had a design that implemented this feature using attributes, but it involved optional parameters on methods which weren’t supported at the time. Well, now C# 4.0 supports optional parameters on methods, so the team revisited the design, and, lo and behold, C# 5.0 now has the CallerFilePath, CallerLineNumber and CallerMemberName attributes.

You can write a Trace.WriteLine method like this:

public static class Trace
{
    public static void WriteLine(string message,
        [CallerFilePath] string file = "",
        [CallerLineNumber] in line = 0,
        [CallerMemberName] string member = "")
    {
        var s = string.Format("{0}:{1} - {2}: {3}", file, line, member, message);
        Console.WriteLine(s);
    }
}

Then, if you were to call Trace.WriteLine(“Something just happened”) the compiler would automatically fill out the optional parameters in the WriteLine method with details of where you made the call from.

This isn’t in the current developer preview, but will be in the final release. As Anders said, not a big feature, but no doubt somebody will put it to good use.

The Roslyn (Compiler APIs) Project

The last half of the talk (starting at 35:26) dealt with what comes after C# 5.0, which is what project “Roslyn” in all about (named apparently after a cute little mining town, an hours drive from Seattle). Roslyn is “the compiler re-imagined”. Anders introduced Roslyn by noting that we are increasingly addicted to IDE productivity tools which provide features like “Find Reference”, “Go to Symbol”, “Rename”,  and “Extract Method”. All these need knowledge about code that is traditionally locked inside the compiler.

Roslyn is all about building compiler APIs that expose what the compiler knows about code to the IDE and to developers. It will include Syntax Tree APIs, Symbol APIs, Binding and Flow Analysis APIs and Emit APIs. The APIs are designed using modern principles. So, for example, the SyntaxTree objects are completely immutable (though you can create new ones by combing bits from old ones) and this means that they are concurrency safe. All the language services in the IDE (syntax colouring, intellisense, etc.) are going to be using Roslyn.

All this is going to be available to us starting mid October, when a CTP of Visual Studio Roslyn will be released. APIs will be available for both C# and VB.

The demos Anders gave of Roslyn are pretty impressive (starting 43:00). First up was the ScriptEngine API that allows you to parse and execute code from a string, or even get a delegate back for executing it at some later point. This led in to the demo of the C# interactive window, which will be part of Visual Studio in the future. You can select code in the editor, press Alt-Enter and have it immediately executed in the interactive window. If you then go and edit it there, you get intellisense, even for methods that you have just interactively defined.

Another demo,roundly applauded, was “Paste as VB” and “Paste as C#” which uses the Roslyn APIs to parse and translate code from the Clipboard buffer. The source code for this will be made available in the CTP.

None of this was big news, of course, because Anders first started talking about it when I was at PDC in 2008. But it’s nice to know that it’s moving on steadily, and that we’ll soon be able to have a play with it.

C# 5.0 – Other News

Compiler as a Service

In the last 10 minutes of his talk on the future of C# 5.0, Anders Hejlsberg gave an update on a project that he first mentioned back at PDC 2008 – Compiler as a Service [watch]. Anders confirmed that what was a prototype back in 2008 is now being worked on in earnest. It has a codename – “Roslyn” (he didn’t actually say this, but you’ll see it appear as a namespace in the code samples, and in one of the Visual Studio tabs), but no ship dates as yet.

As Anders put it, during the compilation process, the compiler builds up a huge amount of knowledge about what your code actually means – and then throws it all away. The idea of Compiler as a Service is give you a Language Object Model encapsulating exactly the same knowledge about your code as the compiler has - right down to the finest semantic details like what an identifier means in a particular context, or precisely how a method call will bind at run time.

It seems that this Language Object Model will be available in a number of different ways, including to Visual Studio Extensions, which will be able to use it for things like performing Refactorings, or formatting code intelligently.

Anders showed one example of a Visual Studio Extension that could add outline regions to if/else blocks [watch]. Sadly, the extension failed to run in Anders demo, but it still conveyed the simplicity and power of the Language Object Model.In another example he showed how the Language Object Models for VB.Net and C# could be used together to create a Visual Studio extension allowing you to copy C# code and paste it as VB.Net [watch]. “I’m not saying this is super-trivial”, remarked Anders, “I mean, there is a couple of thousand lines of code here. But it’s not a complete compiler at all – it’s relatively modest.”

There is more to come

In answer to a question at the end of the session [watch], Anders confirmed that there will be other features added to C# 5.0 that they’re not ready to talk about yet. He did hint that the kind of areas they are exploring were Immutability, Isolated State and Pure Functions – all features associated with ensuring that programs continue to work correctly when parallelism is introduced. Check out the Programming Languages Panel session if you want to hear Anders talk in a little more detail about this.

C# 5.0: The Asynchronous Revolution

In his usual quiet and unpretentious way, Anders Hejlsberg stepped up on stage at Microsoft PDC yesterday – and proceeded to launch a revolution. Two new keywords added to the C# and VB.Net languages was all it took, but the impact of those changes will be felt by programmers for years to come. And not just programmers: unlike other changes made to the .Net languages across the versions, these new additions will produce tangible benefits for users.

The Status Quo

Anders started his presentation by noting a current trend in applications [watch]: they are becoming increasingly connected. We’ve had client-server applications for decades, but we’re now seeing more and more applications that have to call out to a number of different services and co-ordinate their responses. This brings a number of problems. First there’s the latency - the application having to wait as the requests and responses pass back and forth over the network. Then, if we’re not careful, the application appears to hang, unable to repaint the user-interface because it’s too busy waiting for the server to respond. Meanwhile, on the other side of the network, all the server’s threads are tied up, waiting for responses to come back from other servers, so it stops responding to incoming requests – and scalability plummets.

Now we all know what the answer is: asynchronous programming. Rather than tying up our main thread waiting for a response to come back, launch the request on another thread and set up some kind of event handler so that you can be notified when the response comes back, and then finish the work.

We have the answer, but it’s not a pretty one, as anybody who has programmed a serious client-server application in Silverlight will tell you. In Silverlight there is no way of calling the server synchronously: Silverlight forces you to call asynchronously so that the browser hosting your application can remain responsive. In fact, there’s no way of doing something as simple as showing a dialog synchronously: if the way your application continues is dependant on the users’ response, you have to move the continuation logic into an event handler attached to the dialog so that it can be executed once the user clicks their choice of button.

Inside-out Thinking

Programming like this requires you to turn your thinking inside out, because you have to prepare your response (in an event-handler or whatever) before you even make the request. And if in your response you’re going to make another asynchronous call, you have to prepare your response for that even before your first response. Anders gave a small example of that [watch]. Here’s a small method that queries the NetFlix web service. Nice straight-forward code:

Make that asynchronous and see what happens:

See how it’s turned inside out: in line 4 we prepare our what-happens-next by attaching a lambda to the DownloadStringCompleted event, and the call to download the string is the very last thing we do. Then notice that we can no longer return a value from the method: it isn’t available when the method returns. Instead we have to get the user to pass in an Action that we can call back when the result is ready. So we’re forced into changing all the places where we call the QueryMovies method too: the effects of this change ripple out through the code. As Anders said, “it becomes lambdas all the way down”.

No wonder we only do this stuff when absolutely necessary – and our customers pay a price, getting applications that become unresponsive when busy, and servers that are not as efficient as they could be. All because, for mere mortals at least, asynchronous programming is just too hard.

Not any longer.

Asynchronous Programming for the rest of us

Up on stage, Anders introduced his two new keywords, async and await [watch]. Here’s how the asynchronous version of QueryMovies looks in C# 5.0:

It’s identical to our nice straight-forward but sadly synchronous version, with the exception of four small changes (highlighed in orange). The first is the addition of the async keyword in front of the method definition. This tells the compiler that it’s going to have to work some magic on this method and make it return its result asynchronously. This produces the second change: the method now returns a Task<Movie[]> instead of just Movie[] – but notice how the return statement is unaltered – the compiler is taking care of turning the return value into a Task.

In case you’re wondering, Task is a class that was introduced in .Net 4.0 as part of the Task Parallel Library. It simply encapsulates a value that is going to become available at some point in the future (hence, why in some languages the equivalent concept is called a Future). Importantly, Task provides the ContinueWith that allows you to schedule an event handler to be called when that value is available.

The most significant change is the introduction of the await keyword in line 4, and the change to call DownloadStringTaskAsync. DownloadStringTaskAsync is just a version of DownloadString that, instead of returning string, returns Task<string>. Again, this Task<string> is something that will deliver a string sometime in the future. Adding the await keyword in front of the method call allows us to await that future moment, at which point the string will be popped out of its Task wrapper and the method will continue as normal.

But get this: it is not waiting by blocking the current thread. Under the covers the compiler takes everything in the method that comes after the await keyword, everything that depends on the value we’re waiting for, and packages it up into a lambda function – an event handler. This lambda function it attaches to the Task<string> returned by DownloadStringTaskAsync so that it can be run when the string becomes available.

There are very few restrictions on what the bodies of async methods can look like. All the usual control flow operations, if statements, foreach, while, etc. work. Best of all, exception handling works without needing any changes. The compiler takes care of all the twistedness of the asynchronicity, leaving you to think in straight lines.

All this means that, once C# 5.0 is here, there will be no excuses for applications that suffer white-outs while they do some work. And it means some cheap improvements to scalability on the server side. Anders showed an example of a server application that processes some RSS feeds over which he waved the async wand [watch]. The time needed to process the page dropped from about 1.25 seconds to 0.25 seconds – 5 times faster. Here’s a snippet of the code so you can see again how few changes are needed:

This is big news. There are other languages that can already do this kind of thing, F# being one of them. But I don’t know of any other mainstream language that does it, or does it as neatly as this. Anders and team have created an incredibly powerful feature, but exposed it a way that everybody will be able to use.

You can play with this now. Anders announced a Visual Studio Async CTP which contains new versions of the C# and VB.Net compilers, and the necessary supporting APIs in the framework (including Async versions of lots of the existing APIs). It installs on top of Visual Studio 2010, and I gather that it enables Asynchronous methods in both .Net 4.0 and Silverlight.

Further Reading

• Whitepaper: Asynchrony in .Net: an excellent overview of the new features being added in the languages and framework.
• Eric Lippert’s blog: Eric is a member of the C# compiler team, and he’s running a series of posts on the design and implementation of the async feature.
• Jon Skeet’s blog: Jon has been digging into various details of the async implementation, and (as if Anders hasn’t already given us enough!) also speculating about further additions to C# 5.0 to supplement async support.
• Ian Griffiths has his own summary of the async functionality which digs into the exception handling side of it.
• C# Language Specification for Asynchronous Functions
• The C# team blog has an interesting Silverlight 4 Facebook API example.

Introducing HymnSheet – free, simple song presentation software for Churches and Schools

Our church jumped into the computer age a few years back. We ditched the Overhead Projector that had served us faithfully for many years, and acquired one of its digital brethren, along with a laptop. Ah, OHPs – those were the days – amazing what they could do with just a few lights, lenses, mirrors, and on a good day, no smoke. Anyway, I volunteered to sort out some software to do what the old OHP did for us – display songs on the screen for the Sunday School scholars to sing.

Powerpoint was an obvious first candidate, but rejected after a few moments consideration: our Sunday School leader likes to be able to add choruses to the mix at a moments notice: imagine try to insert slides into a Powerpoint presentation on the fly!

Then I scoured the ‘net for more specialised alternatives – and found plenty.But I noticed two things about all of them: firstly, they cost money; and secondly, all of them did too much – we prefer not to have our attention distracted from worship by snazzy graphics and alpha-blended video, or by nursery notices popping up to inform Mrs Jones that little Johnny needs his nappy changing.

What self-respecting programmer would not see this state of affairs as a challenge? Surely it would only take a few evenings to bash out something that would work exactly the way we wanted it to?

So (a few)^10 evenings later I had a little application ready to use. And we’ve been using it successfully for the last four years. Dragging and dropping song titles into a playlist sure beats sorting through a deck of transparencies.

Ever since I started this blog, I’ve been intending to put the application and source code online in the hope that others will find it useful. Finally I’ve got round to it. It is my birthday gift to you all (28 today – I reckon I’ll start feeling grown up in about two years time!).

What you should know about HymnSheet

So here it is, imaginatively named HymnSheet: simple song presentation software, especially suitable for children’s services, and, I imagine, School assemblies and music lessons. It features:

• Support for dual monitors (or a laptop and a projector). One monitor displays the control screen, the other the song display
• Drag-and-drop interface for putting songs into your play-list and for reordering them on the fly
• Ability for you to highlight the current line of the song, to assist children learning to read
• Easy to use song editor for adding your own songs to the song library
• Whole song displayed at once on screen, with key shortcuts for scrolling between verses and the chorus of the song.

Get started by downloading the installer (note that you’ll need the .Net Framework installed on your computer) and reading the user guide. I’ve also made available some sample hymns and choruses (mostly of the more traditional kind) to get you started.

If you find this useful, you might like to help me persuade my wife that it was worth my while - if you’re sufficiently persuasive, she may allow me the time to add some new features:

Points of interest in the Source Code

For the more technically minded, I’ve made the source code to HymnSheet available – feel free to adapt it and add to it if you want – I’d love to hear from you if you do. Some points of interest in the source code :

• The code is written in VB.Net.  I know, I’m sorry. Reason is, I started working on this in the days before I had broadband. At the time I only had a CD of Visual Basic 2005 Express Beta which I’d picked up at a conference. By the time I had a a proper language installed on my machine, I didn’t fancy the job of rewriting ;-). Maybe one day…
• Songs are stored in xml format. I use an XSL transform to turn this into HTML (with CSS to style it) and then display it in a Webbrowser control (maximised to fill the whole of the display screen). This gives you complete control over the way songs are presented. In particular, you might want to change the fonts or colours – the settings for these are in the songs.css file.
• If you’ve never taken a look at the Webbrowser control, you should – it’s cool. As well as letting you load HTML from memory, it provides a managed DOM view of the HTML document, complete with events; you can also invoke any scripts embedded in the page.
• I use some Javascript to animate the movement between verses. From IE 7 onwards, the default security settings prevent javascript from running in a HTML document that is loaded from memory (as is the case in HymnSheet). If you host the Webbrowser control in an application and want to enable javascript, you need to set a key in the registry: [HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER]\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BLOCK_LMZ_SCRIPT\[You executable name.exe], with value of 0. I do this in the installer, but I’ve also created a class with a method that will enable scripting for the current application: look for it in the source code – it’s called EnableWebBrowserScripting.
• I’ve included the source code for the installer (see HymnSheet.wxs). If you want to build this, you’ll need to install WiX, the Windows Installer XML toolkit; you might also want to try out the excellent WixEdit for editing Wix scripts.