The lack of code model support inside methods

As you probably know, the code model (EnvDTE.ProjectItem.FileCodeModel) of the automation model of Visual Studio doesn’t provide information of variables, constants, statements, etc. inside a method. At most, you get the parameters of the method.

Eric Lippert explains in this post how the C# (or other compilers) work. It happens that they need two steps: the first one parses and resolves everything but the code inside the methods. Once the compiler knows about every possible type, the second step parses method bodies.

I am not sure if the file code model of EnvDTE relies on the internal .NET parsers or parses on its own but in any case it seems to follow the same two-step approach, but unfortunately without the second step (maybe for performance reasons, maybe because the file code model should parse on its own and MS never implemented it). Needless to say, to parse a method body can be quite complex and error prone (MS has whole teams for the development and testing of parsers). Hopefully we’ll have some day access to that information when the compiler is a service, as MS announced in the PDC 2008.

One thought on “The lack of code model support inside methods”

  1. See HOWTO: Get the code element at the cursor from a Visual Studio .NET macro or add-in

    Notice that using the code model (ProjectItem.FileCodeModel) you get EnvDTE.CodeElement, not MethodInfo. MethodInfo is for Reflection over compiled assemblies, which don’t apply to source code.

    PS: in the future use the MSDN Forum of Visual Studio Extensibility to post questions:

Comments are closed.