The Roslyn Preview Is Now Available

The Roslyn Preview Is Now Available

Rate This
  • Comments 37

I am super excited to announce that the Roslyn project code is now sufficiently coherent that we can start showing it to customers!

But I am getting ahead of myself somewhat. What is this "Roslyn" project?

Here's the deal. We've got these great premiere languages for .NET development, C# and Visual Basic. Obviously the compilers need to do considerable lexical, syntactic and semantic analysis of the code in order to first off, produce IL out the back end of the compiler, and second, produce all of that on-the-fly analysis needed for syntax colourization, IntelliSense, automatic refactorings, and so on. We do all this work to produce an analysis of the code, but we do not let you, the customer, take advantage of that analysis engine directly. Rather, you just get to see how the compiler and IDE teams make use of that analysis engine.

This is unfortunate. When I look around just Microsoft I see a dozen little C# and VB language lexers, parsers and semantic analyzers that different teams have written to meet their own needs. There have got to be many more out there in the wild. This is a problem we can solve once for you, and then let you make use of the analysis engine for your own purposes.

Furthermore, it became clear as we were designing the next versions of C# and VB that the existing compiler infrastructure built in unmanaged C++ was not going to meet our needs without a major overhaul at some point. We want a compiler infrastructure that supports both new interesting language features, and more dynamic ways to interact with your code as you're developing it.

To achieve all those goals we decided to join the C# and VB teams together, and then split the resulting team apart into two subteams: one concentrating on upcoming C# and VB features like async/await, and one concentrating on the long-term future of the compiler and tools infrastructure. The latter team is codenamed "Roslyn", and that's the team I've been working on for some time now.

We are now at the point where the Roslyn codebase is sufficiently fully-featured and coherent that it makes sense to start getting feedback from customers. You can download the Roslyn Community Technology Preview as of right now; it installs as an extension to Visual Studio 2010 SP1. We would love to get as much constructive feedback from you as possible; rather than leaving comments here, please leave comments on the Roslyn Forum. That way we'll be sure that our crack team of program managers sees the feedback and can aggregate it all appropriately. We're making a huge investment here and want to know that we're heading in the right direction to make something insanely great for you guys.

What we're looking for feedback on primarily is the set of code analysis APIs we're exposing to you guys. The APIs themselves as a set of classes with methods and so on, are now reasonably complete; we do not anticipate making major changes to the infrastructure for Symbols, SyntaxNodes and so on unless we hear loud feedback that we have gone with the wrong model. Does this  set of APIs meet your needs? What parts do you like, and what would you like to be different?

I want to make sure that we're setting expectations appropriately here. This is a very early pre-beta-quality release of some extremely complicated software. Keep that in mind as you are using it. The lexical and syntactic analysis engines that underlie those APIs are pretty much complete. The semantic analysis engine that sits behind the semantic analysis APIs is right now nowhere near done; on the C# side we are still missing semantic analysis of major feature areas like query comprehensions, attributes, iterator blocks, optional arguments, dynamic, async/await and unsafe as well as a bunch of control flows; VB is in a similar state. Extension methods, method type inference, lambdas, and generics are working, so LINQ queries in the "method call" syntactic form should work.

Also, the performance of the entire analysis engine is not as high as we would like; we have done some performance tuning but there is more to come.

In short, you're getting the earliest possible build we could reasonably show to people to get good feedback; we are still a long way from being done. We are absolutely not announcing any dates or "ship vehicles" for a final release; even if I knew - which I don't - I couldn't tell you, so don't ask.

We are also as a part of this release shipping a preview of a new "interactive scripting" environment for C# that will allow you to play around with code in a more experimental and free-form way, like you can do in F# and other "Read-Eval-Print Loop" languages. Give it a spin and let us know what you think! (Sorry, no VB version of this feature is available with the CTP.)

Over the next few months I'll do some more posts describing the interesting technology we've built behind-the-scenes to make the C# and VB Roslyn code analysis engines work. For now, you can get more information on Roslyn at the following places:

Some helpful blog posts:

Fun stuff:

 

 

 

  • Quick question: is there issue with installing Roslyn on a system with the async CTP already installed? I would guess not, but it would be nice to be sure before I hose things...

  • This is very nice to hear! It's good to know you're making the progress you were hoping for and it sounds like it's going to be part of .Net v.next (though, of course, you can't promise anything).

    Suppose I'm building my own .Net language. Will the existence of Roslyn help me integrate it better with VS, e.g. ease syntax colouring because I could use some of the same framework C# does? Or will it be pretty much the same as integrating a new language is today?

    Roslyn is about code analysis for C# and VB; it is not a set of APIs for creating new language services. The new C# and VB language services will be built on top of Roslyn. Roslyn will be a consumer of the Visual Studio APIs that allow you to create language services, not a producer of those APIs. -- Eric

  • Jon: it should be fine side-by-side with AsyncCTP. We've tested this configuration.

  • Thanks Eric,

    Sounds exciting.

    Will Roslyn let me "hook in" to the compilation process and implement own cross cutting?  (replace stuff such as PostSharp).

    Nope. Roslyn is about code analysis, not about extending the C# or VB languages. -- Eric

    Where is Rosalyn in relation to Cecil?

    Cecil is, as I understand it, an IL modification tool. Roslyn is a code analysis tool. As far as I know they have nothing to do with each other. -- Eric

     

  • Will be possible to extend the language, with macros and new keywords, like Boo language?

    Nope. Roslyn is about code analysis, not about extending the C# or VB languages. -- Eric

  • Will it be integrated in VS2012?

    What part of 'we are not announcing ship dates or vehicles' was unclear? -- Eric

     

  • This looks fantastic! can't wait to see what great use will come out of it. One question, will there be any (partial) backward compatibility with VS2010 and possibly lower for using this?

    We don't have plans for that at this time. -- Eric

    ?

  • Big thanks for adding an interactive scripting environment !!!

  • Will Roslyn have any effect on the day-to-day programming of your traditional business developer (like System.Linq.Expression did) or will the effects mostly be felt through improved tooling?

  • Congrats on getting it out!

    Just out of curiosity, why do many of Syntax's collections contain an extra property that doesn't seem to add anything?  For example, if I have a MethodDeclarationSyntax (representing a method), and I want its parameters, I have to type  method.ParameterList.Parameters.  It seems like method.Parameters would have sufficed and produced slightly cleaner code, as ParameterList adds nothing.

    I love the use of the "Opt" suffix on things that are optional!  It's the next best thing to non-nullable types.

  • So, is this like LLVM for the CTS/CLR?

    Absolutely not. Low-Level Virtual Machine (LLVM) is a tool that takes code in an intermediate form from the semantic analysis of a compiler, optimizes that intermediate form, and then emits optimized machine code. Roslyn takes in C# and VB source code and produces a lexical, syntactic and semantic analysis of it for you, and then emits the code in an intermediate form. The thing in .NET that most closely resembles LLVM is the jitter. -- Eric

  • Are you aware that Roslyn.Compilers.CSharp.dll is not verifiable due to a compiler bug?

  • @Jason:

    "So, is this like LLVM for the CTS/CLR?" no.

    The number of people asking this in so many different ways suggests a real discontinuity in expectations Eric. I'm pretty sure that's not a good thing, but I'm stumped if I can see how you could possibly have made it any clearer in the previous comments.

  • Can I ask why you didn't reuse the expression-trees from System.Linq.Expressions?

    Good question; complicated answer. First off, expression trees do not solve all of the problems we want to solve in Roslyn; they do not represent lexical or syntactic state. Second, it is hard to see how we would build an expression tree to represent, say, "this expression tree represents the addition operator on a delegate where the left-hand side contains an overload resolution error and the right hand side is a lambda whose types cannot be inferred". We need to consider "broken code" scenarios at a deep level in Roslyn because *most of the code it processes will be broken*. Code processed as you type it is usually incorrect code in some way. Third, we've decided to not expose the "bound trees" directly; rather, we expose the syntax tree and then provide an API through which you can query the semantic analysis engine for facts about that syntax location. Fourth, expression trees are deeply tied to Reflection.

    That then of course raises the question of why we created our own Symbol types rather than using Type, MethodInfo and so on. Again, it is because reflection types were designed for scenarios in which the code is already in an assembly, correct and ready to run. We need to represent error situations like "this type inherits from itself", and so on.

    -- Eric

     

    And in the same vein, what is the compilation mechanism for Roslyn: CodeDom, Lightweight Code Generation, Reflection.Emit or something new?

    We use a slightly hacked-up version of CCI to do metadata emitting and code generation. Naturally we are working with Microsoft Research on better integrating our code analysis and generation efforts. It is unclear at this time exactly what software, if any, will result from this effort so it would be premature to comment on it further. -- Eric

  • Is there any alternative to play with Roslyn if I don't have Visual Studio 2010? Maybe Visual C# Express? Can I get just a set of dlls?

    No, no and no. Sorry! The Roslyn CTP requires Windows 7 or Windows Server 2008 R2 with Visual Studio 2010 SP1 Professional, Premium, or Ultimate. And you also have to have the VS SDK installed. -- Eric

Page 1 of 3 (37 items) 123