CODEWITHSUNDEEP
visual-studioadd-invsxextensibility
Dmitri Nesteruk
Dmitri Nesteruk

Reputation: 23798

VS2010 Extensibility - how different is it?

A question to those of you who already looked at VS2010. How big are the changes that add-in developers will have to make in order to get their add-ins working under VS2010?

Upvotes: 3

Views: 2238

Answers (2)

Anna-Jayne Metcalfe
Anna-Jayne Metcalfe

Reputation: 101

We've already migrated a development version of our Visual Lint product to VS2010, and for the most part the migration was straightforward - or would have been if there weren't so many bugs in the Visual Studio 2010 Beta 1 automation model. The experience has been akin to the work we had to do to support VS2005 (by contrast VS2008 was a breeze), so it's obvious that VS2010 represents a major change in the evolution of Visual Studio.

As we're using the same binary for all versions of Visual Studio we support (which means the code is contstained to be native C++ throughout), breaking changes in the interfaces tend to be quite visible to us. This time, the areas which have caused us issues are:

  1. The new .vcxproj project file format (we parse project files to read project properties as that's more reliable across multiple Visual Studio versions than using VCProjectEngine - the Visual C++ automation model). Hence we had to write a new parser for .vcxproj files, and as they are potentially very complex that was a major task in itself.
  2. Various bugs in the command bar/command interfaces (presumably related to the new WPF editor/command bar integration). Carlos Quintero has blogged extensively about this subject, so if you have concerns in this area you would be well advised to read his blog.
  3. An undocumented change to the add-in startup sequence in Beta 1 which meant that the DTE Window interfaces were not functional until the OnStartupComplete event had occured. MS have informed us that they are reversing this particular change in Beta 2 due to potential compatibility issues, but we've desensitised our code to this one now, anyway.
  4. Toolwindows in Beta 1 can't be created by internal CLSID (though ProgID works OK). This is the last one we're waiting on before we can wrap up the last major bit of the port.

I suspect that our experience will be pretty representative for most add-ins - it is only if you are using the areas affected directly by major changes in Visual Studio itself (e.g. editor or intellisense integration) that the effects are likely to be particularly severe.

Finally, we're not planning to migrate the build itself to VS2010; it is currently built in VS2008, and we quite simply can't see any reason to migrate to an IDE which is showing every sign of still being a "work in progress" even when it RTMs later this year (that's just my personal opinion though - YMMV).

Upvotes: 1

JB Brown
JB Brown

Reputation: 614

As luck would have it I've just written about this exact subject and shown what it took to upgrade my add-in. (links below)

Basically your answer is that there is a low-impact migration, because a back-wards compatible "shim" is in place for most functionality. Understandably though, to get the new stuff in 2010 like MAF, MEF, and WPF there will be some work on the developers part.

Lastly - Be sure to read this outstanding post from Carlos Quintero, MVP about Add-Ins, Frameworks and CLR compatibility. Carlos's blog is the best I've found for add-in stuff.

Upvotes: 5

Related Questions