Anders Hejlsberg on C# 5.0, Project Roslyn and MEF/Rx Support

If I were to use my Twitterstream as a measuring stick, then by far the most important news coming out of today's Microsoft Build Conference was that in 4 weeks time there's going to be a CTP of Visual Studio (aka 'the Roslyn project') that in its final form will allow you to copy C# code and paste it as VB (or vice-versa) in Visual Studio 2012.

The Twitter storm of excitement around this (why? Has anyone ever wanted or needed to do this? Really?!!!) arose as the result of what was supposed to be just a fun demo of the possibilities that the Roslyn project will enable, and was given in a talk by legendary Microsoft C# language architect Anders Heljsberg.

With the video for the talk not likely to be available for a day or two, I quickly switched to Channel 9's live interview with Anders immediately after the talk to find out more about the stuff that was appearing from attendees in my Twitter stream and sounded a lot more interesting than the cut C#/paste VB nonsense - the new language features coming in C# 5.0 (aka .NET 4.5 - Microsoft numbering strikes yet again!) primarily around support for Windows RT and the new async command.

I'll move onto the interesting 'sound bites' on what's coming with C# 5.0 and Roslyn in a moment, but the real surprise for me came when Anders answered a couple of live questions concerning Silverlight -related technologies MEF and Rx. If I'd have been quicker on the keyboard and known he'd dive in I'd have got a similar question in about PRISM too. After all, these Silverlight-related technologies are very much 'the elephant in the room' that everyone at Build seems to be determined to avoid and here was an expert to help us through the fog of confusion and rumour.

Anders is normally very direct and straight, but when MEF and Rx came up, the interview seemed to turn into a seeming replay of yesterday's interview with Somasegar. At best he seemed vague (not his area of expertise?), at worst distracted (don't put your foot in it by going public?) with regard to specifics.

How easy is it to port code like Silverlight to Windows RT if it includes MEF? was the opening question.

Anders was initially dismissive by saying it "should be easy", as evidenced by the keynote demo.

At the risk of sounding like a broken record, the keynote demo took a simple Silverlight 2 tutorial application and changed some namespaces to make it run. That is not a real world app. It doesn't use MEF, or PRISM or Rx. It's a very simple 'Hello world'-like demo app.

Luckily the interviewer pressed the question home. What about MEF? Does that run under Windows RT?

A pause, and then the bombshell.

"I'm not sure it does."

Another pause, before

"Probably not"

Oops! Given that MEF has definitely been enhanced for .NET 4.5 this was a bit of a surprise.

In a comment on his blog Jeremy Likness tells me that "MEF is exposed through Windows RT" (Jeremy has put together an excellent video course on MEF that's well worth checking out) so I'm rather confused by Anders' reply. Is it really now considered a server-side only technology not a client one, as his answer implies? If so, it will produce some interesting challenges when converting Silverlight applications that use it across to become true Metro Style applications. Or is Jeremy right in that MEF is there in Windows RT and conversion will be relatively trivial? My 16GB USB key (needed to install Windows 8 for myself) has today been despatched from Amazon so hopefully I'll get a chance to try out some of this stuff for myself over the next week and get a definitive answer. Watch for a future blog post!

Next up was another great question of interest to Silverlight developers

Will the Reactive eXtensions framework be included in future versions of .NET

"Possibly. I don't know if we've decided one way or the other."

This time there was more detail, and an explanation as to why it might be excluded. After explaining that Rx is a way of writing event-based screen logic using LINQ-like syntax that operates over streams of events, Anders went on to say "Personally I've found the stuff we've done with async allows you to do a lot more. When you write stuff with Rx you don't write a 'for' loop. You have to understand a mapping. You don't get the normal flow of logic that you always use for programming. With the async stuff you get to program the same way, but in an asynchronous manner. With a lambda where it's all upside-down you can't see the forest for the trees."

I'll take that as a 'No' then!

Async is, of course, one of the big two new features in C# 5.0 (the other being Windows RT support). Anders said that any operations that 'could' take more than 15ms were written to be asynchronous. This all fits in with the 'Fast and fluid' promise of Metro style apps. He also revealed that 10-15% of all methods in Windows RT are asynchronous, which seems a high figure if most of those methods are simple property setter or getter wrappers. Task<T> was introduced in .NET 4 for ongoing asynchronous operations that take a callback for completion. Windows RT doesn't have this but has IAsyncOperation<T> instead. However, Anders explained, these two are bridged by the await command which is able to effect the bridge because both use the same basic pattern for what he called "a seamless asynchronous experience". So seamless that you can apparently write an asynchronous method in C# and have it called from Javascript!

One new feature that sounded particularly interesting was the CallerInfo attribute which gives you current information (similar to macro processor facilities) by allowing a new attribute on optional parameters. For example you can have a 'string filename' optional parameter with a CallerInfo attribute. If you omit the parameter the compiler adds current member, filename or whatever. This will be great for debugging utilities, especially with conditional compilation. I recently worked on some client-side trace logic where this was a real problem. Looking at the source code for Log4net/Log4J I realised that the way Log4net was able to pull this sort of information in was by making every log call throw an exception and then using the resulting call stack trace to grab the required information!

Project Roslyn is apparently all about using the compiler as a service. It's the semantic understanding of the compiler that gives us intellisense, refactorings etc. in Visual Studio. Roslyn surfaces this as APIs that programmers can use to do their own interactive stuff. The Build crowd seemed very excited about the possibilities that this will open up, and the video of the talk covering Roslyn's features will be essential viewing when it becomes available over the next few days.