So, the entryway to my house has eight light switches along the wall. Two of them control the porch lights, and another two work the same entryway light (despite the switches being only a couple of feet apart). I haven’t the foggiest idea what the rest of the switches do. I’ve been scared to try them out, actually. (I worry that one day I’ll accidentally throw one of them and find out later that my couch is missing or something odd like that.)

However, I am pleased to announce that we’ve turned on quite a different switch here on the Managed Languages team, with very successful results! As many of you know, we’ve been diligently working on a replacement for our VB & C# compilers (and certain IDE pieces that leverage them) which is code-named “Roslyn.” Roslyn introduces a far more open model for compilation, which will allow developers to reach inside the compiler itself and see the world (or, at least, solutions and projects) as it does; this, in turn, will lead to far richer IDE and diagnostics being able to be developed at considerably reduced effort and cost.

And now, we’ve turned on The Big Switch in the Visual Studio organization and turned on Roslyn!

The Big Leap Forward

Specifically, I’m pleased to announce that everyone in the Visual Studio organization is using Roslyn in their daily work now. In fact, the daily builds of VS are now compiled using Roslyn, all as part of a process that we refer to in the biz as “dogfooding.”

Now, this change wasn’t trivial and, as with the mysterious light switches in my entryway, there was a lot of caution involved before we got to the point where Anders ceremoniously turned on the switch and enabled Roslyn for the division. Although we are part of the Visual Studio org, in many ways the rest of the VS org is like a customer to us as well, and so we had to be really careful not to derail any teams in our enthusiasm to reach this milestone. (For some reason, the other teams feel that their work is important, too… go figure.)

So, earlier this year, we engaged the toughest bunch of critics we could find (that is, the other VS test teams), and asked them to do several weeks of hard-core tests against their code – essentially, every test that they already had plus new ones specifically designed for this situation. At the same time, we ran and re-ran all sorts of performance tests to ensure that we wouldn’t be slowing down either developers or our build lab. We did a walking tour of the rest of the org and got them educated on the changes that Roslyn would bring. We compiled & assessed over60,000 projects, large and small, both internal and external to Microsoft (including flagship Microsoft products). We fixed whatever blocking bugs we found as a result of all of that and then, at the end of October, we switched the entire division to using Roslyn bits. I’m happy to say that all that prep work set up us well – since The Big Switch, we’ve run into no major issues!

So… you’re done?

Not quite. “Dogfooding” is a prelude to being done, but there’s still a bit of polish to put on before the new code is truly complete. Nevertheless, we are at the state where Roslyn is highly usable for daily work. It’s a huge milestone and essentially says that we’ve turned the corner. There’s no going back now!

So, then, when can we see it?

As you may know, our last generally-available preview for Roslyn was September 2012. No, that year is not a typo. Yeah, we do feel a bit embarrassed about that. Yes, we’ve been a little quiet. No, there was nothing wrong going on here, things were actually going extremely well, it’s just that we’ve just been really heads’ down and focused on The Big Switch and…

Oh, to heck with the excuses, and let me just tell you what we’re doing.

Now, of course, I can’t ever reveal shipping plans in a casual blog post like this, because I want to keep my job that’s someone else’s story to tell. However, if you can keep a secret, I’ll tell you this much: we’re now actively working through the details on starting up regular previews again. The code is in a really nice state these days, and we can hardly wait to show you what we’ve been up to as we’ve been solidifying Roslyn! (But don’t tell anyone that I told you. This is just between you and me.)

Onward!

We wish you all the best for the New Year – 2014 is going to be an exciting year for us all vis-à-vis Roslyn. We’re delighted to have you along with us on the journey!

We'll get a more specific on everything that will be in Roslyn as time goes on — once the next preview comes out (and I regret that I can't be specific about dates yet — not even hints, alas), the feature questions will more or less answer themselves. I know that's a lame answer, but the wait will be worth it.

Thinking realistically about Roslyn, I see bright lights and dark lights…

bright ligfhts:

– evaluators, code refactoring, etc

dark lights:

– limited use, to source code only. For compiled code Roslyn is useless, while there are needs for altering IL-ized code. Look at postsharp success, driven by huge and real needs. We need sililar tools in VS/Roslyn.

– danger that VB/C# become pseudo-languages. Refactoring change meaning of source code. We may see dirty semantic like comments with encoded commands or calls to empty functions, to guide code transformers

@Tristan STW: Thanks for the comments. The IL point is sort of orthogonal to Roslyn itself (the intent of the new compilers is to, well, compile source code), and I can't discuss SKUs or what they might hypothetically contain. However, I'm intrigued by your comment on pseudo-languages… it's given me an idea for a future blog post. I shall have to go off & think about it.

To all: Note that much of the team is heading into some well-needed holidays now, and so further responses may slow down for a bit (which is admittedly a funny thing to say after a having posted a blog intended to start up communication again, but there it is :-)).