Dustin Campbell gave yet another session about the .NET Compiler Platform (“Roslyn”), this time at the dotnetConf 2016 and about live code analyzers:
“Two years ago we open sourced the C# and Visual Basic compilers and exposed their functionality through APIs as the Roslyn project. The Roslyn analyzer API empowers the developer community to be more productive by lighting up their own features in the editor in real-time—meaning anyone can write a refactoring, code fix, code style rule, or code diagnostic. Come learn more about the Roslyn project and what these live analyzers mean for you and your productivity.”
I have added this session to the Videos section of this website, but here you have the link:
After appearing as the new C# / VB.NET compilers in VS 2015, “Roslyn” is gaining popularity, so I am enriching its sections on this web site.
There is now the first book (AFAIK) about Roslyn, by Alessandro Del Sole, which is even free thanks to Syncfusion:
Roslyn Succinctly (free ebook)
Josh Varty published last month two new videos of his Learn Roslyn Now series on YouTube:
And I have found several new videos:
In this post I blogged about nine bugs introduced in the FileCodeModel of Visual Studio 2015 by the new Roslyn-based implementation. Those bugs were “critical” (that is, no easy workaround) and were fixed in the next days.
Then I reported two additional bugs that were less critical for me since I could implement workarounds:
EnvDTE.CodeElement GetStartPoint(EnvDTE.vsCMPart.vsCMPartBody).Line returns wrong result if declaration uses more than one line
EnvDTE80.CodeProperty2.ReadWrite returns always read-write value for VB.NET body-less properties
Those were fixed too. And two days ago I reported a couple of new critical bugs (no workaround) that I discovered:
EnvDTE.CodeFunction.FunctionKind causes COMException for Sub New() in VB.NET instead of returning vsCMFunction.vsCMFunctionConstructor
EnvDTE.CodeFunction.StartPoint, EndPoint, GetStartPoint, etc. cause exception for VB.NET “Declare Sub”/”Declare Function” methods
And those two have been already fixed on GitHub and will be in the some of the next Visual Studio 2015 CTPs.
It is also very incredible the level of transparency that Microsoft has now using open source for Roslyn on GitHub, where you can see the new code that fixes the bugs, the added unit tests, which MS developer is actually working on the fixes, who is reviewing them, etc.
So, thanks Microsoft for all!
I recommend to watch the following 1-hour recorded session of the past Build 2014 Developer Conference to learn about Roslyn (a.k.a the “compiler as service”):
The Future of C#
The title is somewhat misleading, since the session is not so much about the future of C# (the language) but about the C# compiler, that is, Roslyn. It also covers VB.NET, by the way. In that session Dustin Campbell shows demos about using Roslyn to do powerful things with the code in a (apparently) very easy manner.
One cool thing (for developers of Visual Studio extensions) is that the Visual Studio IDE will use only the same public API that is offered to extensions. That should guarantee that no longer happens what is happening so far: while VS has access to the compiler, your add-in or package has to use the code model (EnvDTE.Project.CodeModel, EnvDTE.ProjectItem.FileCodeModel), which is much less powerful and much more buggy.
It also seems that Roslyn will be very well documented, and furthermore being open source you can examine it, rather than using reverse-engineering.
The greatest announcement for developers of Visual Studio extensions in the past days has been about Roslyn, the .NET compiler platform that will allow you to use the compilers as services, and that will be open source.
Even in closed form Roslyn would be great, because the current automation code model (EnvDTE.Project.CodeModel, EnvDTE.ProjectItem.FileCodeModel), apart from being entirely missing for some .NET languages such as F#:
- It is very limited, either to get information or to emit code.
- It has lots of bugs that I have reported on Microsoft Connect (see the “BUG” articles in the “Articles about the code model” section of my web site)
- Microsoft decided not to improve it long time ago (and not to fix bugs, either).
- Being native (not managed) can cause OutOfMemoryException due to memory fragmentation.
None of those things will happen with Roslyn for C# and VB.NET (other languages will have to wait, though), because they will be the compilers used by Visual Studio (starting with VS 2013 if you want) for those languages and Microsoft is changing Visual Studio to use only the public APIs of the parsers/compilers/etc. that will be available for Visual Studio extensions. So, any problem / limitation with the compilers and your extension is a problem for Visual Studio too.
And as if that was not enough, you can have the source code too!
Now, this raises some questions also for developer of Visual Studio extensions:
- What to do with other languages apart from C# and .NET if your extension supports them (not the case of my MZ-Tools add-in)
- Since Roslyn will be available for VS 2013 and higher, what to do if an extension has to support older versions (VS 2010, 2012 at least)…
- What to do if you have a huge investment in the previous technologies (automation code model or your own parsers). For example, ReSharper has decided not to use Roslyn…
And of course, the next thing that would most benefit developers of Visual Studio extensions is to open the Visual Studio assemblies. I don’t mean to “open source” but simply “reference source” (like the .NET Framework Reference Source) and “step source” (like .NET Framework Step Source) would be huge. Since opening the .NET compilers has taken years for Microsoft, I guess that we will have to wait, but I hope…