BUG: EnvDTE.CodeElement.GetStartPoint(vsCMPartBody) / GetEndPoint(vsCMPartBody) throw COMException for expression-bodied methods and properties

Some days ago I got a bug report from a user that was using the new expression-bodied methods and properties introduced by C# 6.0, which have the following form:

public class Class1
   public int Function1() => 0;
   public int Property1 => 0;

After some investigation, it turned out that the problem was in the calls to get the start/end points of the body of the EnvDTE.CodeElement representing them:


For those kind of code elements, the code model throws COMException (not even NotImplementedException), when it should return valid values since those expression-bodied members have…well, a body.

Today I have reported the bug on the GitHub project for Roslyn, since Microsoft changed the implementation of the automation code model (EnvDTE.Project.CodeModel, EnvDTE.ProjectItem.FileCodeModel) for Visual Studio 2015 to be based on the underlying .NET Compiler Platform (“Roslyn”).

EnvDTE.CodeElement.GetStartPoint(vsCMPartBody)/GetEndPoint(vsCMPartBody) throw COMException for expression-bodied methods and properties

This implementation change caused some bugs in Visual Studio 2015 betas that fortunately were fixed after I reported them, and some calls to GetStartPoint / GetEndPoint are not implemented as I reported two years ago:

EnvDTE.CodeElement.GetStartPoint(part)/GetEndPoint(part) not implemented for many parts

As a workaround for this bug, I assumed that the expression-bodied member expands to a single line, and I searched the string “=>” to find the start of the body.

MSDN Magazine article: Creating Extensions for Multiple Visual Studio Versions

Back in April or May I started to write a post on this blog about creating extensions for multiple Visual Studio versions. I have been struggling to support multiple versions of Visual Studio with my MZ-Tools add-in since Visual Studio .NET (2002) / 2003, and other IDEs such as VB6/VB5/VBA before that. So, I know how tricky it can be to share as much code as possible between versions, and using a single binary dll / setup if possible. It seems that I am not the only one wanting to target multiple Visual Studio versions with a single vsix package because I have seen lots of questions in the forums, chat rooms and private email asking about it. The post on this blog was never finished, because it was becoming so long that I thought it would be… a good article for MSDN Magazine! And finally today it has been published in the August issue:

Visual Studio – Creating Extensions for Multiple Visual Studio Versions