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!