But before we dive into the actual content, I want to point out two things. Was anybody here in the last talk with Troy Hunt? Was that pretty good? Maybe you can explain why I have a little red note on my podium that says, I'm going to hack you first.

So if any demos fail from this point on, we're just going to blame him. Secondly, I'd like to take a moment and thank NDC sponsors, especially JetBrains. Is anybody from JetBrains here? You know not to raise your hands. OK, cool. I have a good relationship with them.

And if I try to talk to them, we just get in an argument about ReSharper, Roslyn, and this big debate. So I just wanted to throw a special shout out to them for paying for me to be here to talk about a competing product. So how many of you have actually heard of Roslyn

before? Cool. How many of you played with Roslyn? Whoa, OK. That was a different number. How many of you developed Visual Studio add-ons? Only three in the crowd, but I'm pretty sure most of the overflow raised their hands.

So Roslyn is a really interesting project. It's a really challenging project, and it fascinates me. I've been doing C Sharp for about five or six years now, which is about as long as Microsoft has spent developing Roslyn. And I'm primarily ASP.NET developer.

I do web stuff. So the compiler is like the furthest thing from my mind when I'm writing my code. All that I care about is that people are able to add things to shopping carts. But I think that goes to show just kind of how cool and intriguing this idea is. And I hope that by the end of this talk, you'll kind of

catch on to that and hopefully share in my passion about why it's cool. So what is it? To understand what it is, we need to start with what we have now and understand why this new project is going to change everything. So what we have now, when you compile your application in

Visual Studio, it doesn't matter what kind of application it is, web, class library, console application. All your code gets fed to an executable, a single executable written in C or C++, maybe a little bit of managed code as well. And nobody knows what happens aside from the compiler team

during this execution. You stick code in, and an assembly comes out on the other end. That makes things extremely challenging for a long-term programming language, especially for a company the

size of Microsoft, because you have different teams that are interested in these details of what's going on inside this. You have Visual Studio. You have ASP.net tools like the ASP compiler. So what's happened over these years is that different compilers are being written with essentially the same logic in between. All of this business logic is just redundant.

Hopefully you're not a developer who likes redundant business logic. So Microsoft, several years ago, like I said five or six years ago, realized that one, this thing's going to be unmaintainable very quickly. Two, it's silly to have different teams maintaining their

own versions. If you add a new feature to the C-sharp compiler, then you have to have somebody else add it to the VB side of things, and that's difficult. And you have to have the other teams, like ASP.net, update their compiler or separate ASP.net compiler. You have to have the Visual Studio team update their lexer to understand what these new

keywords or features mean. And it's a huge time sink, and it's a huge waste of money for Microsoft. So they began rewriting the whole thing in primarily C-sharp, but also in the languages that they're compiling. So Roslyn itself shares as much logic as possible between

the VB side of the compiler and the C-sharp side. Any logic that's specific to either language is written in its own language. So the VB side of the compiler, where they diverge, is written in VB. And the C-sharp side is written in C-sharp, and the shared code is written in C-sharp as well.

So it was kind of a good challenge for them to take one so that they could use the languages that they're writing to build the languages that they're writing. And it's the epitome of dog fooding something.

So it was a great experience for them, and they decided, this is worth the investment. Like I said, the current compiler also provides nothing. And the big thing that they were trying to do is reduce the redundant logic, so they also expose an API throughout the entire process. You no longer have to compile all the way to an assembly and

write that assembly to disk in order to find out information about the code that's been produced in that or the IL that's been produced in that assembly. So you'll see in the next slide, we'll go through the stages and kind of see how that's beneficial. Additionally, the Roslyn project itself is not simply

a rewrite of the compiler. It's also a rewrite of all the Visual Studio integration. We have these new APIs. Now we can actually make use of them. So it's much more expansive than simply rewriting the compilers. It's actually rewriting how the Visual Studio interacts with the compiler. I'm sure a lot of code was deleted that maintained a

separate parsing logic and lexer logic within Visual Studio. Finally, it's open source, which is great. No, that sucks. OK. Is it great? Yeah, awesome. Cool. And I think that's amazing.

I met with the compiler team several times over the past year or so. And I kept saying, you guys got to open source this. You got to open source this. And then the day that they open sourced it at Build, I just took my lunch break because it was some Azure talk. And they just pulled Anders out while I'm on my lunch break away from everything. And he presses the button to publish it to CodePlex, which

is the little negative side about open sourcing it. I'm not going to complain. That was a huge step for Microsoft. It shows how they've evolved towards the community over the past few years. And I'm just thankful that they managed to do that. So who benefits from this? And how?

We have three main consumers of the compiler. We have the managed compiler team, which is now previously, when maintaining the old compiler, there were two separate teams. There was a VB team, a C Sharp team, maybe a Visual Studio team off somewhere. Everybody remembers the picture of Microsoft with

different sections holding guns to other sections? Yeah? OK. I should have put that in my slide, I guess. But they've been combined. So now it's a much more tight loop of communication. And it makes it much more easy for them to add new language features. Like I said earlier, previously, when you added a new language feature, multiple teams within the

company would need to update their own version of the compiler, including if the C Sharp team added a feature, VB team would have to add a feature, Visual Studio team would have to recognize the feature, et cetera, et cetera. Now, since they're all combined, it makes it really, really easy for them to just add a feature, and boom,

it suddenly exists in both sites. So that was one great side effect of doing it this way. Then you have the clients of the compiler, which are the Visual Studio team primarily, and maybe you, if you develop an add-on or an extension that actually relies on some information about the code that was typed in.

Do any of you write Visual Studio extensions? No? OK. That's not surprising. So they're the second biggest benefitter. Thirdly, you have the consumers of the compiler, which is us, people who don't write Visual Studio extensions and people who are just trying to compiler the code.

And we benefit because all the other teams have already benefited. We benefit because the compiler team is able to add features quicker, so when we submit a user voice issue requesting a new feature, we get to see actual results much more quickly. The managed compiler team does read user voice, contrary

to how it appears, if you check user voice, and would love to implement most of the features that we have. But the previous compiler has grown so complex and so difficult to maintain that it's just not feasible to add really simple things to the language. When I spoke with the compiler team, they expressed

that when they added async await, it was like the final thing that they could get in there. They can't imagine how they could add one more even simple feature into the compiler without massive, massive amounts of work. So we benefit because of that, and we benefit because now people who do build Visual Studio extensions are able to build a much more rich experience for us because

so much more information is provided to them. Without the APIs provided by the Roslyn compiler or the next version of the compiler, it's just simply too much work to pull information out about our code. There are companies that can invest hundreds of thousands of dollars into products like ReSharper and Code Rush, and

I think there's a third one. But most people who write Visual Studio extensions, it's just too much work to understand what we're trying to do with our code. So let's take a look at what the compiler does now.

The compiler pipeline is quite simple. You can actually cut it off into these four little sections. You have a parser, which verifies that your syntax, what you've typed, the code you've typed, is syntactically correct. You have symbols, which represent classes, variables, methods, and things in separate scopes, defined by the

syntax. You have a binder, which puts those together. Sure, you're accessing a class named foo, but does foo really exist? Are you allowed to access foo? Is it at the right visibility? And finally, once you verify the program, bound the symbols to the syntax, you emit the compiled IL to an

assembly. Right now, there's so much additional baggage kind of thrown in there. Specifically, when you emit an application with csc.exe as it stands today, you must emit a DLL. That's it. Something must come out the other end.

And as I said, you have no view into the other portions. With Roslyn, we now have these separate APIs over each. This seems pretty logical, but consequently, we're now able to do actual partial compilations of code.

We don't need to run it the whole way through. We can actually stop after we parse the syntax tree and just work with whatever we got there. We don't have to go all the way down to emitting IL, especially to disk. Additionally, we don't have to emit IL to disk at all. We simply emit it to a memory stream if we so choose. So you've just eliminated an entire IO bottleneck from the

entire process. But how are these specific portions used? Again, you can break it down. It's pretty straightforward. Different parts of Visual Studio are built on different parts of these APIs. So you have the outlining, coloring, formatting. None of that cares about whether or not a class is

acceptable or accessible. But once you get to the binding, OK, now we need to, you know, if we rename a variable, are we renaming variables in multiple assemblies? We rename variables in just this method, et cetera.

So it actually all breaks down this. It's an extremely complex process, but this is what it breaks down to. I want to start with kind of the foundation of this process. And that's the syntax trees. Your code is text. But to the compiler, it means something. It needs to be verifiable. It has members.

It has objects or no instantiations. It could be a static class or whatever. So let's take a look at kind of what a syntax tree looks like to the compiler. A syntax tree consists of a root element, like a compilation unit. This is a chunk of text that you've just now fed to the

compiler and expect something to come out the other side of. And you can break that down very easily to many, many parts. In this case, in this example, we're looking at a single, very simple class with a very simple method inside of it. And it's showing you how you have a simple type declaration, a method declaration, a parameter list, and a simple block of code.

But it goes further than this. Now you have additional things on top of this. You have syntax tokens. And syntax tokens are kind of the things that are syntactically important. They're still important, and they define kind of the structure of your code. But by themselves, you don't really know much.

You can't really get much from the code. So finally, you have syntax trivia. And syntax trivia is all the stuff that doesn't really matter. All the things that you spend hours and hours trying to perfect, like white space and where you put your

braces, whether it's on the same line or the next line. So syntax trivia is really interesting from the Roslin perspective, because they've decided that when they parse your syntax tree, they want to be able to recreate your syntax tree as text exactly as you typed it. So they preserve all of this. If you access the syntax tree via the Roslin APIs, you

can basically two-string the whole object and get back your code exactly as it was formatted. If you think this through, this was an essential decision. Without deciding to do that, then there's no way that this API could have possibly provided any type of

refactoring support. Otherwise, if you try to refactor something using Visual Studio's refactoring tools, you'd end up with something formatted completely different than whatever you put in. So it's actually really great that they added that. So how do you use this? I mean, what can you do with this?

Why does this matter to you? The answer is, quite simply, diagnostics. I think, and I believe what we're going to see with Roslin is that a new ecosystem emerged for Artfuline. This is how it impacts a regular developer.

As I mentioned before, because the other teams were able to move forward and evolve more quickly, this is going to be the end result. What do I mean by diagnostics? I guess I need to switch mirroring. That was probably really boring.

So what do I mean by diagnostics? This is more exciting. This is a command prompt. How many of you maintain a library or something on Nougat, maybe, open source, maybe not, internal, whatever? Come on, you're developers. You just give stuff to people and they, OK.

So if you maintain an open source library, I personally maintain a project called Script CS, which is built on Roslin and enabled by Roslin. But you often end up with users coming back to you saying, I'm trying to access your APIs. I'm not quite sure how. Or they come back with a code sample. This doesn't work. And I'm like, well, yeah, you're doing it completely wrong. As an API author or a library author, I have no way

to tell people how to use my API right now. So Roslin takes us and kind of gives us the ability to make an FXCOP on steroids. I know a lot of people love FXCOP, so I'll keep that part short. But we're now able, using these compiler APIs, to add

our own compiler warnings, our own suggestions. I use a database in my web development career called RavenDB. And the API that's provided for it is extremely opinionated. If you're familiar with the energy framework, you might have heard of the select n plus 1 issue, where you

generate a query and then loop through the results. And by looping, you're now generating additional queries with each iteration. And the author of RavenDB knew that this is bad and knew that this is a common mistake. And so what he does is, by default, throw an exception if

you try to issue more than 25 or 30 queries. This is really terrible to find out once you've deployed a production. The whole application goes down simply because he wants to make sure that you know what you're doing. That's the wrong way to tell consumers of an API that they're doing something wrong.

So Roslyn gives us now the ability to go ahead and create what's called diagnostics and code fixes. Actually, I'll just start with a new one. Is the text OK for everybody? Kind of. I should open text first. Once you install Roslyn, which you can download from

CodePlex, there are detailed instructions on how to get started with this in CodePlex. You're given these new visual C Sharp or visual basic templates called diagnostics and code refactorings. And so I'm going to go ahead and just create a new diagnostic right now. The team did a really good job of kind of showing you how to set this up and a basic example

of how to use these. What these do are actually generate compiler warnings. They allow you to define new compiler warnings based on your API. Imagine in the future, or imagine a future where, when you download a new library from NuGet, it might include these new diagnostics or these new code fixes.

They might include their own refactorings to suggest to you. So this is a basic code fix. I just did file, new code fix. And to walk you through it a little bit, the most important part is this analyze symbol down here. This particular example generates a compiler warning if

you have any class names with a lower case character in them. Obviously, this is a code smell. It implements a very simple interface called isymbol analyzer.

There's actually a newer version of the interface, which the example has not been updated to include. And you can define your own messages and what have you. You tell the compiler, look, I'm interested in anything that's a named type. If you come across a named type while compiling the code, just let me know. And I'd like to inspect it to make sure

it's following my rules. When it does come across a named type, your analyze symbol method gets called. And you're able to manipulate that. You can inspect that to your will. As I said, this is a very straightforward example. It's simply checking are any of your characters lower case? If so, I'd like to add a new diagnostic that says, draw

a little squiggly here. And tell the user that they shouldn't be doing this. They should use caps locks for everything, for every named type. If you've ever written a Visual Studio extension, you know that doing so is extremely annoying. You have to do a lot of com. You have to deal with building a v6 manifest

and build a v6 package. This project template already comes with these things for you. So once you've created the project, you just can go ahead and hit Start. And actually start debugging another instance of Visual Studio without any additional work.

This is really impressive if you have touched v6 before. Also, if you think that Visual Studio is slow, try debugging it. So I built some awkward silences in while this fires itself up. Please enjoy.

OK, so now I have this new instance of Visual Studio. And it already has my v6, which was created with this code diagnostic installed and ready to go as soon as the instance is actually ready to go. One thing you do see on the side is what's called the Roslyn syntax visualizer.

Compilers are really intimidating. Syntax trees are really intimidating. So the compiler team actually created this extension and distributed it with the Roslyn itself to help people who aren't really familiar with syntax trees and the internals of how they're parsed, help them understand and see what their code looks like to the compiler.

OK, so Visual Studio is now downloading for now. And I'm going to create a new class library, which as most people know, always contains class number one for some reason. So I'll just go ahead and create that. It'll cycle through it a little bit more. But class one, as defined in a new class library,

already violates our rule. They didn't use caps locks when they generated class one. So right away, we should receive a warning for this. So how was your day? Pretty good?

This morning, I spun this VM up in Azure to do these demos. I gave it like eight cores and 16 gigabytes of memory. And it's still clocking. All right, so here we go. So we have this class one right here. It's still kind of loading.

But while it loads, let's take a look at this over here. Let's not do it that way, though. Can you guys see that OK? Is that too small? Too small, yeah. I apologize for that.

I'll just zoom in for the other one. So you see, we've already got a little green squiggle, a little warning that says type name class one contains lowercase characters. So this is the power that this diagnostic provides.

Additionally, I'm going to try to make the text on the side a little bit bigger, because I can't just zoom in for you.

Too big? Oh, come on. Right. Bear with me while I adjust my DPI.

So we're going to kind of get through this. If you get motion sickness, let me know. I've just put my cursor in between the C and the L. So right now, the syntax visualizer has updated to show

me where my cursor is in the syntax tree that is constructed. So I'm going to zoom in here. And you can see at the top, we have this root compilation unit that I mentioned. We have a few using directives, as you do. And you can see exactly where your cursor exists in the syntax tree. So when you're writing these things, they already give you

the tools not just to do these powerful diagnostics and code fixes, but they also give you the tools to understand how to write them. Compilers are hard. Compilers are complex. Roslyn makes it possible and much easier to work with the compiler, but it's still a compiler.

It's still going to take work. And so at least they give you this little tool to help. So that's just a basic diagnostic. Again, you can customize that message. You have complete control over the squiggles, where it exists, what it does, or what it says. So I'm going to stop debugging that.

I'm going to open another sample that they provided called make const. So simply providing warnings is not really enough as a library maintainer. You're just simply telling them that they're doing it wrong, but you're not telling them how to fix it or how you would suggest that they take care of the issue.

So you have a mirror type of project to the analysis of the diagnostic, actually, called a code fix. And a code fix actually lets you provide a suggestion. It lets you say, don't do it that way. Actually, do it this way.

And all you need to do to do it my way is press Control, comma. So this code fix provider right here is written to identify situations in which a local variable could be declared as a constant, or a variable or member in general. So I'm going to go ahead and try to start debugging this one.

And once Visual Studio loads, I'll show you that you can not only say do it this way, you can show the user actually how their code would look if you did it that way. So let's wait for Visual Studio to load again. This is awkward silence number two. You can definitely get the different vibe from number one.

I promise not to beat that joke too hard. How many of you use Resharper? How many of you use Code Rush? How many of you, whoa, nobody.

How many of you use nothing? Cool, all right, some purists in the crowd. So I'm going to open this class library back up. Now I'm going to make a variable that could be a constant, but isn't.

This is eight cores hard at work.

So simply doing var x equals zero, I should get a warning that says, you know, why would you do that? Why would you not make this a constant value?

So inside here, I get a blue squiggly. You're responsive, there we go. So on this side, I can click here, and it says absolutely nothing about making a constant. So this is the power, really.

OK, so let's try putting it in. Yeah, that's what I was thinking. Next?

Really? That's the real power of Roslyn. That's actually actually probably Resharper. So the Resharper guys knew what I'm talking about.

And the guys who don't use Resharper probably knew what I'm talking about. OK, so you see here, if I mouse over to x now, we get that convert to constant warning. If I do control comma, Resharper tells me, hey, I

want to be your friend. Control dot. Let's just click on the light bulb, how about that?

We get a two constant update. And I'm actually lying to you this whole time because I have Resharper on, and it's telling me to convert to constant. So I'm just going to turn that off real quick. And I'll actually show you Roslyn. This was not meant to be a sales pitch.

So now we should get a legitimate warning, and we do not.

If you do try to write these, like I said, what you are building is a v6 file. So if you run into this problem, you can take a look at what extensions are installed and verify that the one that you're running is actually there.

I'll just tell you as soon as I get solution explorer back up. There it is. So make constant, let's see us. Who asked? Somebody over there, OK. So that should definitely be installed over here.

And there it is, actually. There it was. There you go, so make constant was too sharp. So that is actually there. I wonder if I just need to make it a local, maybe. OK, there we go. So now we have this highlighting.

Can be made constant. This is not Resharper. This is actually the fix. I can show you the message. It's different. So there you go. So now if I do control dot, I get the code fix.

This is where the code fix kicks in. It gives you this option to reformat the user's code. And additionally, it shows you a nice little window that previews for your user what it's going to look like when you're done, if they accept your suggestion. And this is really nice. And this is a good side effect of being able to run

partial compilations, because there would be no way to do this with the current compiler. There's no way to feasibly and efficiently tell the user what it's going to look like. You'll also see an example of this preview feature if you try to rename something. So if I take this and just do a, I should no longer get the

constant, maybe I will, if I would like to rename this then, this is another example of kind of what the compiler is able to do for you.

If I just try to make this named x, in the top right corner, you can see this little new rename variable box. This doesn't exist in current Visual Studio because, like I said, not possible. It tells you that not only can you rename this y to x, but there's also a conflict that you're going to create if you do so.

And it takes the liberty of saying, maybe if you declared it this way and specified explicitly that x is the member variable and that your new x is just a local variable, then it's going to work. So it's this intelligent refactoring that Roslyn is going to be able to provide us as developers and hopefully

put the last nail in Richard's coffin. Thanks for sponsoring JetBrains. So I hope that you can see kind of why this is beneficial. I did have two demos prepared for you that actually blew up this morning. And so I'm kind of really short on what I can show you.

I wanted to remove regions from the language for you. I know that everybody would appreciate this. Wait, who said? But unfortunately, my Visual Studio corrupted this morning. So I spent it all rebuilding an Azure VM. So to close, I guess, I want to take a look at kind of

where we're going. There are a lot of developers. And the reason I give this talk is because a lot of developers feel like Roslyn and the C Sharp 6 features that were announced are really insignificant. They're really boring compared to what we've had in the past.

We've gotten generics in two. We got implicitly typed and extension methods and anonymous types in three. Et cetera, et cetera. And all of a sudden, in six, after so many years of just silence and development by the Microsoft team, we get nothing major. But the feature that we're getting in six isn't a C Sharp feature.

It's the compiler itself. It's this new capability to interact with the compiler and also the open-sourcedness of it so we have the opportunity to actually drive the compiler forward. You should see C Sharp 6 and the Roslyn project as Microsoft's call to action. If you ask anybody on the team, they're going to say,

we're not quite sure where to push this. C Sharp is very mature. It's very stable. And we want to now see what the community can do with it, where the community can take it through forks and pull requests, and what kind of new tools and development experiences the community can build around it. So again, I apologize for not having those two demos for

you, but this is pretty much wrapping up my session. Does anybody have any questions about this? Back in the corner? So the question is, what's the story with F Sharp? F Sharp has this. They have their own compiler written in F Sharp.

And they also have, I think, recently released, actually, a cool API around that compiler. There are no plans to add additional languages or functionality to this. This is not going to be a universal compiler framework. It's simply a rewrite of the C Sharp and VB compilers. Does that answer your question?

Cool. Down here in front. Yes. OK, so the question is, what is the compiler performance and is able to multi-thread? That's a great question. Yes, absolutely.

It is at least on par with the current compiler in terms of overall performance. The part about multi-core is actually a great point to make. The current compiler, the only idea of parallel builds that you have with it, since it is a single executable that does need to be spun up each time, is building multiple

projects in parallel. That's as parallel as you can get with a current compiler. With Roslyn, they've designed it with an immutable data structure. The syntax trees are completely unchangeable. The F Sharp guys probably know what I'm talking about. And as a result, as a consequence and byproduct of this, they can parallelize the actual build process, the

actual compilation, down to the IL emission level. So you can emit multiple IL instructions in parallel. Unrelated IL instructions, not like, hey, race condition just screwed up my method. So it's much, much, much more scalable than the existing compiler.

Yes, sir? Sure, yeah. Instead of maybe an obsolete attribute that simply has a magic string that says, hey, use that method instead, you could provide a refactoring or a code fix that says, I've seen you trying to call this method, but I'd

prefer you do that one. So just hit Control-dot, and we'll update it for you. Absolutely. And in fact, that's actually great, because you no longer have to require your user to figure out the new argument, or parameter ordering, or anything of that nature. You might even be able to just say, you want to call this method, and you wanted to call it this way, based on what you've provided me so far.

So yes, absolutely. Any other questions? Yes? OK, so I think the question was, is there any way to

provide these code fixes automatically? And there is no way to do it with the current Nougat infrastructure. This capability would require a change. And by this capability, I mean distributing your code fixes and diagnostics without additional requirements from the user. You could easily publish a v6 to the Visual Studio

extension gallery, and say, when you publish an update to your library, also suggest that the user go grab that v6. But there's no seamless way to get the user both in only one step, which would be ideal. So any others?

Cool. OK, so that was my talk. I hope you enjoyed it. If Rosslyn's open source, go check out the discussions. Go get involved, and follow me on Twitter. Thanks.