There are “painful” Visual Studio releases which require you a lot of testing and changes in your add-in, a lot of time isolating bugs to reproduce them with the minimal code, and a lot of wait until they are fixed in some beta, CTP, etc:
– VS.NET 2002: introduced a new automation model (EnvDTE) very different to the one used in VB6, with commands (a new concept at that time), required (native!) satellite DLLs, shim COM controls for toolwindows, etc.
– VS 2005: introduced XML-based add-in registration, a new
Microsoft.VisualStudio.CommandBars assembly, managed (.NET) satellite DLLs, truecolor bitmaps, a new EnvDTE80 assembly, temporary solutions, build platforms, partial classes, etc.
Then there are “painless” Visual Studio releases which don’t introduce many changes and for the most part use the same code than the one before, so add-ins don’t suffer much:
– VS.NET 2003: it was very similar to VS.NET 2002.
– VS 2008: it is very similar to VS 2005.
VS 2010 belongs to the first group. In the long journey (several releases) that Microsoft is taking to convert the COM-based original VS.NET 2002 IDE to a 100% managed (.NET) IDE, it is the one suffering the most important changes so far. Suffice to say that this is the first VS release that needs to load the .NET Framework when launched (so it loads slower), previous ones went native code all the launch code path.
In this VS 2010 release the commandbars and the code editors are being changed, which causes add-ins to suffer lots of bugs, specially because Microsoft don’t use add-ins (but SDK packages), so bugs get unnoticed until developers of add-ins start testing extensively. I haven’t counted them exactly, but I’m quite sure I have reported more than 30 bugs in the automation model at Microsoft Connect since I started to test VS 2010 Beta 1. I don’t remember me reporting so many bugs in the beta period of any previous release. BTW, the bugs that I report that are still in beta 2 are prefixed with “VSIP: VS 2010 Beta 2” if you want to search them.
Yesterday I finally got tired of not being able to load my MZ-Tools add-in in VS 2010 Beta 2 due to its multiple frustrating critical bugs in the new WPF-based commandbars. So, for testing purposes, I decided to skip the creation of toolbars, menus and commandbar popups and instead I created by hand a custom toolbar with the commands of my add-in (through the Tools, Customize dialog), so I could at last test the actual features. Of course, the process of creating and populating a custom toolbar couldn’t go without finding a new bug:
VSIP: VS 2010 Beta 2 Bug: Removing last button from custom toolbar causes it to disappear temporarily from the list of commandbars
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=515143
(and another one that I was unable to reproduce)
So today I have started to test some features and soon I have found a bug that didn’t happen in previous releases and that can break add-ins with toolwindows whose content changes with the active document window:
VS 2010 Beta 2 Bug: EnvDTE.WindowEvents.WindowActivated event not fired for window getting the focus after closing other window
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=515234
Notice that the Properties window of VS 2010 is not affected by that bug and changes the content correctly as you close document windows, because it doesn’t use the automation model (EnvDTE.WindowEvents.WindowActivated event).
Maybe I am too pessimistic, but I think this will be the outlook for add-ins in this and next releases of Visual Studio: a lot of internal changes in Visual Studio that cause bugs in the automation model for add-ins that get unnoticed until very late in the beta cycle (because early betas and CTPs are under heavy construction and are unusable for add-ins).
And if you think that the next VS release (maybe VS 2012 or VS 2013) will be a “painless” one, Microsoft is planning to introduce a new language model (different than the code model provided by Project.CodeModel or ProjectItem.FileCodeModel). Even if the current code model is preserved for backward compatibility, chances are that add-ins will want to use a better code model, given the limitations of the current one (no support for generics, no support for code inside methods, limited code generation, bugs, etc.).
And if you think that the new WPF-based commandbars will be here to stay many years, I bet that sooner of later Microsoft will change them by the ribbon UI of Office 2007 and new Windows 7 applications 😉
On the positive side, I do know that Microsoft people are doing a lot of hard work to fix the bugs and are providing the means to get fixed as many bugs as possible by the RTM release at March 2010.
I agree. After having begun work on migrating an AddIn to VS2010 myself and having talked to one of the VS devs about this, I am really not so sure about the future of AddIns any more…
As you describe, Microsoft seems to put all energy into enhancing VSX/packages, MEF etc. Now, because of Macros, I expect the DTE API itself to stay for another few releases and MS (reluctantly?) seems to be committed on keeping the API stable. For Macros, the effort they put into DTE may be sufficient, but for AddIns, this hardly seems to be the case: As you describe, even tiny API changes can cause enough trouble to make porting to a new relase painful. That said, it seems to me that AddIns are in some way lost between Macros and packages — they are more complex and sensitive to API changes than Macros and at the same time, do not receive much attention from MS because of competing with packages.
I am therefore wondering whether going forward, the only sane choice is to migrate from AddIns to VSX/packages. What is your opinion on this? Have you considered turning MZ-Tools into a package?
Currently I am working on adapting MZ-Tools v6 to VS 2010 and on a new MZ-Tools v7 that it is too late to migrate to a package, but certainly packages are the way to go. The problem with them is that they are suffering also changes in each release, from VS.NET 2002 (where there was no API for 3rd parties), VS.NET 2003 (which introduced VSIP), VS 2005 (which introduced the SDK), etc. suffering also the migration from a COM API to a .NET API. Since a commercial add-in or package needs to target the current VS release a one or two previous releases, it is convenient that the same code base can be used to target the two or three releases. But yes, I will look into packages after I release MZ-Tools v7.
Hi Carlos,
As always I appreciate your blogging and feel equally as frustrated by the menu management issues discovered in the subsequent beta releases of VS2010.
Many Thanks
Beth
I couldn’t have put it better myself. My experience is that every otherrelease of Visual Studio is going to cause us real pain one way or another, and in that regard Visual Studio 2010 is right on form.
FWIW here’s my take on each release:
VC4 – New UI and project format. Some issues, hence VC4.1 and 4.2 (the latter pretty good).
VC5 – New poor quality help system as well as the first attempt at a plug-in model. New project format.
VC6 – Stable, no real surprises.
VS2002 – A dog. New automation model, project format IDE and installation requirements all at the same time. Too many changes to not have issues, really.
VS2003 – Stable, and a pleasure to develop for.
VS2005 – A dog. Breaks existing add-ins and *still* has outstanding issues with native add-ins four years on.
VS2008 – Stable. One break in the VCProjectEngineLibrary interfaces (don’t they unit test this stuff?), but it’s an annoyance rather than a showstopper. Works well in practice, despite the larger footprint.
VS2010 – A dog since the WPF editor and new project file format went in (the previous CTPs were quite stable). Too many unnecessary breaking changes which are diverting effort from more important tasks. It really is like VS2005 all over again.
VS2012 – Hopefully stable. We’ll see – but that’s my prediction.