In the last days I have watched (among others) two videos of the PDC 2008 about subjects that are always of interest for developers of extensions for Visual Studio, specially if the extension deals with source code, which will be the usual thing in most cases:

Future Directions for Microsoft Visual Basic
http://channel9.msdn.com/pdc2008/TL12/

The Future of C#
http://channel9.msdn.com/pdc2008/TL16/

The matter of new syntax and language constructs is of most interest for many 3rd party tools. To put two examples, C# 4.0 will allow optional parameters and VB 10.0 will not require the line continuation character “_” to break lines in many cases.

There are two concerns regarding all this:

1. Whether the automation model (EnvDTE*) will be updated to recognize it. It is not a secret that EnvDTE was not much enhanced since VS 2005 when EnvDTE80 brought new classes like EnvDTE.CodeClass2, EnvDTE80.CodeFunction2, etc.
2. Four releases later, the automation model doesn’t support yet code inside methods, so you can’t get the method variables, constants and statements unless you parse the code on your own. While this is somewhat easier for VB.NET due to its verbose syntax (Dim, Const, End If, Next, etc.) it is painfull for C#.

In C# 3.0 and VB 9.0 parsing, type resolution and expression resolution got complicated with lambda expressions, extension methods, infering types from initializers, etc. but in the next versions of the languages with its “dynamic” approach this is going to be crazy. For example, VB 10.0 will support this syntax:

Sub Main()
...
   Dim thread As New Thread(Sub()
         For Each o In scores
            Console.WriteLine(o.ToString)
         Next
      End Sub
...
End Sub

That is, a Sub inside a Sub!. So, when you parse looking for variables, you will need also to take into account nested methods…  will the automation model provide something like EnvDTE100.CodeFunction3.CodeElements or EnvDTE100.CodeFunction3.CodeFunctions?

Not all are bad news; in fact, there are a couple of very good news:

1. “Co-Evolution – there are no differences between the users of VB and C#. We are going to co-evolve the languages going forward. This means that if we introduce the features in one – then we will work hard to make that feature available in the other.”I wonder why MS took 6 years and four releases to realize this. When I heard some years ago that VB.NET developers where more concerned about productivity and C# developers were more concerned about “the code”, I thought it was a nonsense, as if C# developers wouldn’t like to be productive or VB.NET developers wouldn’t care about the elegance of code. The fact is that it is only a question of syntax: VB.NET is the natural option for people coming from a VB6/VBA background while C# is the natural choice for people coming from Java/C++ (let me say that I think that any good developer should know several languages). And from that point, both groups want the same features in the IDE and in the language(s). I have heard some people arguing that forcing both VB.NET / C# teams inside MS to provide the same features would hinder innovation, it takes time to catch on the other language, and that competition is good. For me, the question is why there are two whole huge separate teams to create two project subtypes that for the most part differ only in the syntax of the language (this is also true for the deceased Visual J#). I mean, they use similar project subtypes, with files or linked files, with imports/using, with compiled or source code references, with project property pages with similar properties, with configurations (Debug/Release) with similar properties, that compile to the same IL, etc. I guess this is for historical reasons, and maybe I am too naive, but it seems to me more natural to evolve towards a whole huge team that takes care of common things and allows extensions for VB.NET and C# (for example, the parsers), which would be developed by two small teams. My MZ-Tools add-in for Visual Studio supports VB.NET, C# and VJ #, it has tons of files and code, but it has a single file called MultiLanguageLibrary that handles the language differences. For example, imagine that Microsoft builds parsers that convert:C#

   int i = 5;
   f(i);
   

   or

   VB.NET

   Dim i As Integer = 5
   Call f(i)
   

   to something like this:

   <codeelement name = "i" kind="methodvariable" type="Int32" initialValue="5">
   <codeelement kind="methodcall" name="f">
      <arguments>
         <argument kind="methodvariable" name="i"></argument>
      </arguments>
   </codeelement>
   

   (just an idea)

   and then the remaining path is common for all languages. BTW, it would be nice to provide that parsing output to developers of extensions, and this is the second good news:

2. Parsers/Compilers/Code Generators as services: Microsoft is going to “open up the box” so it is no longer a “black box” and will expose services to interact with its internal parsers, compilers, etc. so hopefully you don’t need to build your own parser and you don’t need to use the buggy and incomplete EnvDTE.Project.CodeModel / EnvDTE.ProjectItem.FileCodeModel. Don’t get too excited yet, since this will take years, though, and several Visual Studio releases.