Carlos Quintero (Microsoft MVP) blog

Not too much to blog about VS 2010 these weeks...

carlosq — Thu, 21 Jan 2010 09:36:00 GMT

You may have noticed that I am not blogging too much these weeks. The reason is that I have been working on the next version of MZ-Tools (and it is too early to comment about it) and testing the VS 2010 Super-Limited-CTPs that Microsoft provide to some people to test their extensions (add-ins, packages, etc.). These SLCTPs are under Non-Disclosure-Agreement (NDA) so the bug reports are private and I can't comment what is fixed or it is still wrong. I am looking forward to the public VS 2010 Release Candidate to provide more information in the add-ins area.

On a separate thing, I have finished watching the videos of the Visual Studio Extensibility (VSX) Developer Conference October 2009 that were of my interest. I have updated the Resources page on my web site to list all the videos.

The first thing that strikes me is that none of the 20+ sessions is devoted to add-ins, and none was devoted in the 2008 conference too. Add-ins is an area of extensibility that is basically dead for Microsoft, only maintained due to the number of add-ins out there. While not as easy as they should be, historically add-ins have been the easiest way to extend Visual Studio, and originally in VS.NET 2002, the only way to do it providing a user interface (macros don't provide user interface, the VS SDK was not introduced until VS 2005 and the former VSIP SDK was introduced in VS.NET 2003). The EnvDTE API is not certainly elegant and it suffers lots of inconsistencies and drawbacks that I have blogged about extensively all since I started this blog back in November 2006 (it turned 3 years recently), but it worked for most of us, specially because it was powerful enough for most purposes and the alternative (the SDK) was even worse until recently. If I had to start today building a VS extension, the SDK would be the way to go, but when you have an 8-years old add-in with tons of lines of code, it is difficult to think about migrating it knowing that it will provide no added value to the end users once migrated and tested completely.

The second thing that strikes me is that there are no progress in the extensibility of ASP.NET Webforms or the new WPF / Silverlight forms for add-ins (or may even for packages, I don't know). If your extension wants to manipulate programmatically those forms or usercontrols, it's going to be a difficult time. The Window.Object may return something for ASP.NET forms, but nothing for WPF / Silverlight forms. AFAIK, the designer of WPF is even a separate process and when they talk about WPF Designer Extensibility, they mean extensibility for developers of WPF controls to provide editors, adorners, custom actions or menus, etc. It seems that all emphasis about VS extensions is about to explore or manipulate code, and never to explore or manipulate forms/usercontrols.

The last striking thing, on the positive side, is that Visual Studio has got so much extensibility in several areas to deserve an annual conference with lots of sessions. That's certainly great.

Happy New Year 2010 and MVP again!

carlosq — Fri, 01 Jan 2010 15:55:00 GMT

Happy New Year!

I have just received the Most Valuable Professional (MVP) award again, the 7th one that I receive from Microsoft. As always, I am very grateful for this award :-)

VS 2010 Release Candidate announced

carlosq — Fri, 18 Dec 2009 20:13:00 GMT

Finally, on the contrary to what I posted some days ago, Microsoft announced yesterday that there will be a public VS 2010 Release Candidate, and that "the planned final launch date is moved back a few weeks".

This is good news for developers of add-ins, because:

1) That release will be the first one where the automation model of the WPF-based commandbars will work without the many critical bugs of Beta 2.

2) Developers will be able to release add-ins compatible with VS 2010 RC for the end users to test them.

That said, there will be minor bugs that finally won't be fixed even in RTM because the bar to get them fixed is very high already today, but I think there will be workarounds. I will post about them when the RC is released.

Developer Tools Ecosystem Summit Videos now available

carlosq — Mon, 14 Dec 2009 13:25:00 GMT

Channel 9 has now the video recordings of the talks that were given at the 2009 Developer Tools Ecosystem Summit:

http://channel9.msdn.com/tags/Development-Tools-Ecosystem-Summit/

I'd suggest to start with the keynote:

VSX100: Visual Studio Extensibility Keynote: Past Present and Future
http://channel9.msdn.com/posts/VSIPMarketing/VSX100-Visual-Studio-Extensibility-Keynote-Past-Present-and-Future/

Brian Harry's comments about my post "No public VS 2010 Beta 3 or release"

carlosq — Thu, 10 Dec 2009 23:10:00 GMT

Brian Harry, Microsoft Technical Fellow and Product Unit Manager for Team Foundation Server (TFS) has commented about my last post "No public VS 2010 Beta 3 or release". (Brian is making a huge effort in transparency about the performance problems of VS 2010 Beta 2 and the work to get them fixed for RTM)

I reproduce his comments here:

"I don't know Quan but I can say definitively that this is not an official Microsoft communication. I've remarked before (on my blog) that when you have an organization of 2,000 - 3,000 people, you have to assume random stuff happens. Said another way "Don't believe everything you read" :)

1) We've had an RC on the books from the beginning. We are investigating the possibility of making it a public release. We didn't originally for that but the Beta 2 feedback has made us rethink it. We will ensure that there is time to incorporate customer feedback. Quan wrote this a while ago and, to be honest, I'm not sure we had reached that conclusion yet.

2) We haven't decided what we are going to call the public release yet. We've discussed both "Release Candidate" and "Beta 3". I responded to one comment on this post: http://blogs.msdn.com/bharry/archive/2009/12/05/anatomy-of-a-performance-problem.aspx with some thoughts on this. Regardless of what we call it, we will be looking for customer feedback/validation and will allot time to get it before releasing.

3) March 22 is NOT the release date. It never was. March 22 is the marketing launch date. We generally don't announce RTM dates ahead of time but we do communicate launch dates. Sometimes RTM happens before the launch, sometimes after. I think it's fair to say that we are targeting an RTM in the general timeframe or we wouldn't have set the launch date there but there are many considerations that go into launch dates - lining up with other events, hollidays, venue availability, ... Further, it would make no sense for us to have set a final RTM date before getting Beta 2 feedback. We always say "we'll ship the product when it's ready".

Am I the official Microsoft spokesman on this topic, well, um, no. However, I will say that I'm in all of the discussions about when we'll ship, how do we know, what prereleases will we do, etc, etc. And those who do actually own the "official responsibility" know I'm writing about it and are keeping quiet. Maintaining plausable deniability, I think :)

If you want to learn more, please visit my blog at http://blogs.msdn.com/bharry. I'm passionate about shipping a great developer tool and partnering with all of you to accomplish it. I'm always listening and open for feedback. Nothing I like more than a productive debate.

Thanks for listening,

Brian"

It's great that Microsoft is considering another public release before RTM. I know it would be to validate the performance fixes after Beta 2, not because add-ins are broken in the current Beta 2. I am fortunate enough to get the private Limited CTPs (LCTPs) after Beta 2 but I am under a Non-Disclosure Agreement (NDA) so I can't blog about their fixes, workarounds or new problems as I did with the public Beta 1 and Beta 2 in the last months to help others, and my new Microsoft Connect bug reports are now private to Microsoft too. But other developers of add-ins would benefit from that public release, and working add-ins could finally be made available to end users for testing before VS 2010 gets RTM. I wouldn't have any hope of getting fixes in the automation model between that public release and RTM, though.

No public VS 2010 Beta 3 or Release Candidate

carlosq — Mon, 07 Dec 2009 08:51:00 GMT

I knew it privately but I have realized today that it is public (from a Microsoft source):

"There are no plans to release a Beta 3 for Visual Studio 2010. The official release date will be March 22nd. If you (or your company) are part of the TAP or VSIP program, a release candidate will be available in the near future. Dates are still tentative."

TAP is the Technical Adoption Program (TAP) and VSIP is the Visual Studio Industry Partner Program (VSIP).

Given the really horrible / bad / unusable / state of the automation / commandbars model for add-ins in public VS 2010 Beta 2, it is a pity that there isn't a public Beta 3 available to everybody so that:

- All developers of add-ins (not just those invited to TAP of paying the fee of VSIP) can test that the reported bugs about VS 2010 Beta 2 extensibility are fixed without praying or crossing fingers waiting for the RTM.

- Better yet, consumers of their add-ins can test the add-ins for them also in real life. It is interesting that Microsoft itself is going to suffer the same problem of a lack of a public Beta 3 or RC to verify that their internal fixes / tests actually solve the performance problems of VS 2010 Beta 2 in real scenarios ...

Since the bar for bugs to pass the triage and get fixed becomes higher and higher as Visual Studio reaches Release Candidate status. I don't even think that a public Release Candidate would be of any benefit for developers of add-ins, since bugs discovered and reported at that point wouldn't be fixed unless they are critical (that is, prevent launching the product or affect a large number of users).

In general, given the "application monster" that Visual Studio is becoming (with more and more features each release) and the huge internal changes that Microsoft is doing to migrate it from a native app to a managed app, what is required IMHO is longer cycles, maybe 3 years instead of 2 (as it happens with Windows / Office / SQL Server, etc.), where the beta 2 is "fully feature completed" and then you devote several months to a beta 3 to fix all the bugs, and then you release a product that you know that will work great rather than just being confident without actual external verification. Otherwise you end with things like Windows Vista or, to less extent, like Visual Studio 2005 (with its embarrassing performance problems in real scenarios), products that were fixed in the next releases (Windows 7, Visual Studio 2008).

Microsoft fixing VS 2010 Beta 2 bug: EnvDTE.WindowEvents.WindowActivated event not fired for window getting the focus after closing other window

carlosq — Fri, 04 Dec 2009 22:28:00 GMT

While VS 2010 Beta 2 has still an undesirable number of bugs as I have blogged a lot, Microsoft is putting a lot of effort to fix them. This one was fixed today (for the RTM release):

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

VS 2010 not installing .NET Framework 2.0 / 3.0 / 3.5 by default

carlosq — Fri, 04 Dec 2009 21:55:00 GMT

More than a year ago I wrote a popular post:

.NET Frameworks, CLRs and Visual Studio add-ins
http://msmvps.com/blogs/carlosq/archive/2008/11/14/net-frameworks-clrs-and-visual-studio-add-ins.aspx

I stated that VS 2010 would install .NET Framework 2.0, 3.0 and 3.5 (all of them based on CLR 2.0) and, of course, .NET Framework 4.0 (based on CLR 4.0). You may have noticed in the betas of VS 2010 that .NET Framework 2.0, 3.0 and 3.5 are not installed by default, you have to download and install them separately for VS 2010 to use them in projects. So, I have updated the post.

BTW, in the December 2009 issue of MSDN Magazine there is a good article about loading multiple CLRs in the same process

In-Process Side-by-Side
http://msdn.microsoft.com/en-us/magazine/ee819091.aspx

Visual Studio "painful" releases and "painless" releases for add-ins. VS 2010 belongs to the first group (by far). And maybe next ones too...

carlosq — Sat, 28 Nov 2009 16:52:00 GMT

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:

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.

Importing Visual Studio settings destroys commandbars of add-ins

carlosq — Thu, 19 Nov 2009 15:42:00 GMT

There is a bug/issue that I reported years ago for VS 2005 and was not even acknowledged as a bug but "by design". VS 2010 (Beta 2) still exhibits it so I keep pushing to get if fixed (the original bug report was lost, I think it died when MSDN Product Feedback became Microsoft Connect):

VS 2010 Beta2: importing settings destroys commandbars created by add-ins
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=512214

The problem is that Visual Studio thinks that all the commandbars of the IDE belong to it, ignoring the fact that some commandbars belong to add-ins and it should ignore them when importing settings, rather than resetting them or destroying them...

To complicate things, when the add-in is unloaded at some point later (by the user or closing VS), it doesn't have a direct way to know if its commandbars have been destroyed by Visual Studio, so it tries to delete them and it gets a ObjectDisposedException....

Add-ins and the "Tools", "Customize" dialog, "Commands" tab of Visual Studio 2010 (Beta 2)

carlosq — Thu, 19 Nov 2009 11:20:00 GMT

In VS 2008 (and previous versions), when you opened the "Tools", "Customize..." dialog, "Commands" tab, you got a list of "categories", and each category has a list of commands that you could drag and drop on some toolbar to create a button from that command. For commands provided by add-ins, you had the "Add-Ins" category and for commands provided by macros you had the "Macros" category. Furthermore, you had a "Rearrange Commands..." button where a new dialog allowed you to select a menu bar or a toolbar, and add/move/remove commands (buttons), etc. So far so good, except one thing that VS has never managed well which is that toolbars, menu bars, commandbar popups and buttons provided by add-ins can be temporary if the add-in uses that approach instead of the permanent one, and therefore Visual Studio should not offer the temporary UI items of add-ins for customization, since customization will be lost when the add-in is unloaded and when loaded again the add-in will recreate the UI from scratch. I discussed these issues in detail in the article:

HOWTO: Handling buttons and toolbars user customizations from a Visual Studio add-in
http://www.mztools.com/articles/2008/MZ2008019.aspx

In VS 2010 (Beta 2), commandbars are WPF-based and the Customize dialog has suffered a re-design, but if it is not fixed in the RC / RTM builds things are getting worse due to these bugs (currently under evaluation, but likely closed as "won't fix" in this release):

VS 2010 Beta 2 Bug: wrong customization for commandbarpopup of add-ins
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=501255

VS 2010 Beta2: Add-ins and macros commands should not appear in the "Tools", "Customize" dialog, "Commands" tab, "Menu bar" combobox
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=512141

Those bugs will cause confusion to users of add-ins if they try to use the Customize dialog...

At least these two minor bugs were fixed after Beta 2:

VS 2010 Beta 2 Bug: Command picture not shown in Tools, Customize window, Commands tab
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=502250

VS 2010 Beta 2 Bug: Command name shown instead of caption in Tools, Customize window, Commands tab
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=502242

Another critical VS 2010 Beta 2 bug that causes the IDE to hang

carlosq — Mon, 02 Nov 2009 20:12:00 GMT

This bug eluded me during several days because there was another bug that already caused VS 2010 Beta 2 to hang, but finally a couple of days ago I realized that was seeing a different issue (no commandbarbutton involved in this new bug) and I was able to isolate and report it today:

VS 2010 Beta 2 Bug: adding CommandBarPopup to CommandbarPopup causes VS to hang if CommandBarPopup was added to Toolbar before

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=507650

As I expressed some days ago, my feeling with VS 2010 so far (after four builds) is that once you patch your add-in to (somehow) bypass a bug, the add-in finds a new one.

The (VB.NET) code to reproduce it is:

Imports System
Imports Microsoft.VisualStudio.CommandBars
Imports Extensibility
Imports EnvDTE
Imports EnvDTE80

Public Class Connect
   Implements IDTExtensibility2

   Private _applicationObject As DTE2
   Private _addInInstance As AddIn
   Private _commandBarToolbar As CommandBar
   Private _commandBarPopupOnToolbar As CommandBarPopup
   Private _commandBarPopupMenu As CommandBarPopup
   Private _commandBarPopupOnMenu As CommandBarPopup

   Public Sub OnConnection(ByVal application As Object, ByVal connectMode As ext_ConnectMode, ByVal addInInst As Object, ByRef custom As Array) Implements IDTExtensibility2.OnConnection

      _applicationObject = CType(application, DTE2)
      _addInInstance = CType(addInInst, AddIn)

      Select Case connectMode

         Case ext_ConnectMode.ext_cm_AfterStartup
            InitializeAddIn()

         Case ext_ConnectMode.ext_cm_Startup
            ' OnStartupComplete will be called

      End Select

   End Sub

   Public Sub OnStartupComplete(ByRef custom As Array) Implements IDTExtensibility2.OnStartupComplete
      InitializeAddIn()
   End Sub

   Private Sub InitializeAddIn()

      Dim commandBars As CommandBars

      Try

         commandBars = CType(_applicationObject.CommandBars(), CommandBars)

         If MessageBox.Show("Create toolbar before menu?", "", MessageBoxButtons.YesNo) = DialogResult.Yes Then

            ' This hangs VS 2010 Beta 2
            CreateToolbar(commandBars)
            CreateMenu(commandBars)

         Else

            ' This causes nested menus but doesn't hang VS 2010 Beta 2
            CreateMenu(commandBars)
            CreateToolbar(commandBars)

         End If

      Catch ex As Exception
         System.Windows.Forms.MessageBox.Show(ex.ToString)
      End Try

   End Sub

   Private Sub CreateToolbar(ByVal commandBars As CommandBars)

      _commandBarToolbar = commandBars.Add(Name:="My toolbar", Position:=MsoBarPosition.msoBarTop, Temporary:=True)
      _commandBarPopupOnToolbar = AddCommandBarPopupToCommandBar(_commandBarToolbar, "MyPopupOnToolbar", "My Popup On Toolbar")
      _commandBarToolbar.Visible = True

   End Sub

   Private Sub CreateMenu(ByVal commandBars As CommandBars)

      Dim menuCommandBar As CommandBar

      menuCommandBar = commandBars.Item("MenuBar")

      _commandBarPopupMenu = AddCommandBarPopupToCommandBar(menuCommandBar, "MyPopupMenu", "My Menu")
      _commandBarPopupOnMenu = AddCommandBarPopupToCommandBar(_commandBarPopupMenu.CommandBar, "MyPopupOnMenu", "My Popup On Menu")
      _commandBarPopupMenu.Visible = True

   End Sub

   Public Sub OnDisconnection(ByVal disconnectMode As ext_DisconnectMode, ByRef custom As Array) Implements IDTExtensibility2.OnDisconnection

      Try

         If Not _commandBarPopupOnMenu Is Nothing Then
            _commandBarPopupOnMenu.Delete()
         End If

         If Not _commandBarPopupOnToolbar Is Nothing Then
            _commandBarPopupOnToolbar.Delete()
         End If

         If Not _commandBarPopupMenu Is Nothing Then
            _commandBarPopupMenu.Delete()
         End If

         If Not _commandBarToolbar Is Nothing Then
            _commandBarToolbar.Delete()
         End If

      Catch ex As Exception
         System.Windows.Forms.MessageBox.Show(ex.ToString)
      End Try

   End Sub

   Public Sub OnAddInsUpdate(ByRef custom As Array) Implements IDTExtensibility2.OnAddInsUpdate
   End Sub

   Public Sub OnBeginShutdown(ByRef custom As Array) Implements IDTExtensibility2.OnBeginShutdown
   End Sub

   Friend Shared Function AddCommandBarPopupToCommandBar(ByVal objParentCommandBar As CommandBar, _
ByVal sCommandBarName As String, ByVal sCaption As String) As CommandBarPopup

      Dim objCommandBarPopup As CommandBarPopup = Nothing
      Dim objCommandBar As CommandBar
      Dim objCommandBarControl As CommandBarControl
      Dim iPosition As Integer

      If Not (objParentCommandBar Is Nothing) Then

         iPosition = objParentCommandBar.Controls.Count + 1

         objCommandBarControl = objParentCommandBar.Controls.Add(Type:=MsoControlType.msoControlPopup, Before:=iPosition)

         objCommandBarPopup = CType(objCommandBarControl, CommandBarPopup)

         objCommandBar = objCommandBarPopup.CommandBar

         If Not (objCommandBar Is Nothing) Then

            objCommandBar.Name = sCommandBarName

            objCommandBarPopup.Caption = sCaption

         End If

      End If

      Return objCommandBarPopup

   End Function

End Class

More on CommandBarButton.Mask property deprecated in VS 2010

carlosq — Sun, 01 Nov 2009 16:40:00 GMT

In the post CommandBarButton.Mask property deprecated in VS 2010 I mentioned that VS 2010 will deprecate the Mask property of CommandBarButton to specify bitmap transparency, accepting 32-bit bitmaps with transparency in the alpha channel in the CommandBarButton.Picture property instead.

The VS team told me some weeks ago that the CommandBarButton.Picture would accept also in next VS 2010 builds 24-bit bitmaps with RGB=0,254,0 (almost pure green) as transparent color (as VS has always accepted for commands). I have verified this week that VS 2010 Beta 2 accepts that possibility correctly.

Bottom line: VS 2010 will accept both in Commands (AddNamedCommand) and CommandBarButton.Picture:

32-bit bitmaps with transparency in the alpha channel
24-bit bitmaps with RGB=0,254,0 (almost pure green) as transparent color

Workaround for VS 2010 Beta 2 Bug: CommandBarButton.Style not honored, always Icon + Caption

carlosq — Mon, 26 Oct 2009 20:01:00 GMT

Back in VS.NET 2002/2003 the only way to change the style (Icon only, or Icon + Caption) of a CommandBarButton created from a Command was to cast the CommandBarControl returned by Command.AddControl to CommandBarButton and use the CommandBarButton.Style property.

If you use that approach in VS 2010 Beta 2 you will find this bug that I already mentioned:

VS 2010 Beta 2 Bug: CommandBarButton.Style not honored, always Icon + Caption
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=500403

That means that if the toolbar of your add-in has 30 buttons which should be shown as "only icon", due to this bug they will shown as "icon + caption" and you hardly will see 7 of them...

Fortunately there is a workaround thanks to the EnvDTE80.Commands2.AddNamedCommand2 method that was introduced in VS 2005. So you can:

Cast the EnvDTE.DTE.Commands (or EnvDTE80.DTE2.Commands) property to EnvDTE80.Commands2
Call the Commands2.AddNamedCommand2 method passing in the CommandStyleFlags parameter the EnvDTE80.vsCommandStyle.vsCommandStylePict value

I hope this helps.

Yet another critical VS 2010 Beta 2 bug in CommandBars: this one causes VS to hang, nothing less

carlosq — Mon, 26 Oct 2009 19:32:00 GMT

This one happens when an add-in:

- Creates a temporary toolbar using CommandBars.Add

- Creates a temporary CommandBarPopup on that toolbar

- Creates a command and tries to add a CommandBarButton from that command to that CommandBarPopup using Command.Add(CommandBarPopup.CommandBar)

The bug report is here:

VS 2010 Beta 2 Bug: adding CommandBarButton from Command to CommandbarPopup on Toolbar causes VS to hang

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=503871

The (VB.NET) code to reproduce the problem is:

Another critical VS 2010 Beta 2 bug in CommandBars: this one causes VS to evaporate without warning, nothing less

carlosq — Sun, 25 Oct 2009 20:48:00 GMT

After 3 hours isolating this to the minimal expression (which is tedious if your add-in is has lots of user interface items and debugging a VS 2010 add-in on a virtual machine is painfully slow), here it is:

VS 2010 Beta 2 Bug: deleting a CommandbarPopup unloading add-in causes VS to disappear
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=503093

(the problem happens if the add-in creates two (not just one) CommandBarPopups on a parent CommandBarPopup and tries to delete them when unloaded)

Frustrating new bugs in commandbars of VS 2010 Beta 2

carlosq — Sat, 24 Oct 2009 23:26:00 GMT

I can't express how disappointed, frustrated (and more things!) I am with VS 2010 Beta 2 regarding correct behavior of commandbars for add-ins. It seems that once a bug is fixed in a VS 2010 build and an add-in can pass that point, new bugs surface that prevent its correct loading (and I have tested several builds since Beta 1).

Suffice to make you aware of these bugs:

VS 2010 Beta 2 Bug: CommandBarButton of add-in duplicated in new commandbar when already created in another commandbar
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=502289

(For my MZ-Tools add-in with tons of buttons, menus and popups, only that bug of VS 2010 Beta 2 has completely ruined it, not to mention the time it took me to isolate it until I realized what was happening because initially the add-in seemed to hang, due to the number of duplications that were occurring at the glacial speed of VS 2010 debugging an add-in on another VS 2010 instance on a virtual machine)

VS 2010 Beta 2 Bug: CommandBarButton.Style not honored, always Icon + Caption
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=500403

VS 2010 Beta 2 Bug: System.AccessViolationException attempting to create a temporary popup commandbar
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=500408

VS 2010 Beta2: InvalidCastException casting DirectCast(CommandBarControl, CommandBarPopup).CommandBar.Parent back to CommandBarControl
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=499483

I realize that changing the COM-based commandbars of VS 2008 by new WPF-based commandbars in VS 2010 is a daunting and difficult task, but if the next milestone after Beta 2 is Release Candidate (where only critical bugs are fixed) then Beta 2 should be already free of such nasty bugs. Or there should be a known roadmap of betas / CTPs until RTM so that developers of add-ins can know how many builds they will have to test and rest assured that they will have enough weeks/months to test their add-ins (considering that in Beta 2 they can't get them even loaded in Visual Studio).

I think that since Microsoft builds and extends Visual Studio with packages (SDK) and not add-ins, commandbars/commands/buttons of packages get better behavior earlier in the development cycle of Visual Studio. But for add-ins (automation) every time that commandbars are changed in some VS release, you have to wait until the RTM to check is some bug that could ruin your add-in is fixed. I experienced the same with VS 2005, which introduced 24-bit bitmaps (rather than the 16-color bitmaps of VS.NET 2003) and a different assembly for Microsoft.VisualStudio.Commandbars.

VS 2010 RC/RTM fixing " 'Object must be the same type as the enum' exception calling CommandBars.Add from an add-in" problem

carlosq — Sat, 24 Oct 2009 08:00:00 GMT

Microsoft has reported that this problem will be fixed:

" 'Object must be the same type as the enum' exception calling CommandBars.Add from an add-in"
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=462766

Notice that the "Embed Interop Types" property seems to have been renamed to "Isolated" in VS 2010 Beta 2, in one of those renaming changes that make things more obscure...

VS 2010 Beta 2 certainly supporting RGB=0,254,0 as background color for command pictures as in previous versions of Visual Studio

carlosq — Sat, 24 Oct 2009 07:37:00 GMT

FWIW, I have verified that VS 2010 Beta 2 certainly fixes the issue of supporting RGB=0,254,0 for transparent color in 24-bit command pictures that I mentioned here.

So, if your add-in targets VS 2005, 2008 and 2010 you can use that color for the transparent background color of command pictures and they won't appear with lime green in Beta 2 as it happened in Beta 1 or previous CTPs builds.

If your add-in only targets VS 2010 it is preferable to use the new support for 32-bit command bitmaps. I guess that in a few years Microsoft will only support 32-bit bitmaps in Visual Studio.

VS 2010 and the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface

carlosq — Fri, 23 Oct 2009 22:38:00 GMT

This is going to be messy, so step by step:

Imagine that you are developing an add-in that uses a temporary user interface (not permanent one), and creates a couple of commandbars of kind "toolbar", and many commandbars of kind "popup" (with submenus).

Since it uses a temporary user interface, it must delete those commandbars when unloaded.

For that purpose, it must keep a reference to each created commandbar at class level (all this is explained in the article of the previous link).

Since it creates lots of commandbars, rather than keeping each one individually, they are stored in a class-level collection. Of which type?

CommandBars of kind "Toolbar" have the "Microsoft.VisualStudio.CommandBars.CommandBar" type but commandbars of kind "popup" have the Microsoft.VisualStudio.CommandBars.CommandBarPopup" type, so both can't be stored in the same typed collection, but we would like to use a single collection, not two, or not a collection of System.Object.

Fortunately the Microsoft.VisualStudio.CommandBars.CommandBarPopup type has a CommandBar property, and since the Microsoft.VisualStudio.CommandBars.CommandBar type has a Parent property (typed as System.Object, that should return a Microsoft.VisualStudio.CommandBars.CommandBarPopup actually), you can use a generic typed collection List<Microsoft.VisualStudio.CommandBars.CommandBar>, which stores the CommandBar of toolbars, and the CommandBarPopup.CommandBar of popup commandbars.

When the add-in is unloaded, it iterates the commandbars of the collection to delete them:

If the CommandBar.Type is MsoBarType.msoBarTypeNormal, the commandbar is a toolbar and can be deleted calling the Delete method.
If the CommandBar.Type is MsoBarType.msoBarTypePopup, the commandbar is a popup so we get its Parent property (which is a System.Object) and we cast it to Microsoft.VisualStudio.CommandBars.CommandBarPopup. Then, we call the Delete method of CommandBarPopup.

(As I mentioned, my MZ-Tools add-ins seems to use every conceivable technique provided by the Microsoft.VisualStudio.CommandBars API)

However, this approach that worked perfectly in VS 2005/2008, doesn't work in VS 2010. Why?

It happens that VS 2010 uses WPF-based commandbars, but add-ins for VS 2010 still use the Microsoft.VisualStudio.CommandBars Interop (ActiveX) assembly for backwards compatibility.

That interop assembly provides the Microsoft.VisualStudio.CommandBars.CommandBarPopup type, which is actually an interface (although it doesn't follow the convention for interface names), not a class. The same happens with the CommandBar and CommandBarControl types, which are interfaces, not classes. The CommandBarButton type is a class, though. To complicate things, you have the CommandBars class and the _CommandBars interface... anyway:

In VS 2005/2008, which use native (COM) commandbars, the classes that actually implement those interfaces are native, and from a managed add-in you see them through a System.__ComObject which is the Runtime Callable Wrapper (RCW) that you get when you don't have an interop assembly. But since they implement the interfaces provided by the Microsoft.VisualStudio.CommandBars assembly, the add-in works fine.

In VS 2010, which uses managed (.NET) WPF commandbars, the classes that actually implement those interfaces are managed and are provided by the Microsoft.VisualStudio.PlatformUI.Automation namespace in the managed (.NET) Microsoft.VisualStudio.Shell.UI.Internal.dll assembly (in one of the VS 2010 folders).

When you create a commandbar popup calling:

Microsoft.VisualStudio.CommandBars.CommandBarControl commandBarControl;

commandBarControl = parentCommandBar.Controls.Add(MsoControlType.msoControlPopup);

you get some class instance that implements the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface. So you can do this cast:

Microsoft.VisualStudio.CommandBars.CommandBarPopup commandBarPopup;

commandBarPopup = (Microsoft.VisualStudio.CommandBars.CommandBarPopup) commandBarControl;

In VS 2010, the actual class that implements that Microsoft.VisualStudio.CommandBars.CommandBarPopup interface is the Microsoft.VisualStudio.PlatformUI.Automation.CommandBarPopup._Marshaler class.

However, when you do this:

commandBarPopup.CommandBar.Parent

in VS 2005/2008 you get an object that implements the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface (as expected), so the approach described in the beginning of this post worked.

In VS 2010 you get an instance of the Microsoft.VisualStudio.PlatformUI.Automation.CommandBarPopup class, not of the Microsoft.VisualStudio.PlatformUI.Automation.CommandBarPopup._Marshaler class that you got when creating it.

It happens that the Microsoft.VisualStudio.PlatformUI.Automation.CommandBarPopup class doesn't implement the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface. It implements IMarshaledObject<CommandBarPopup> instead. It also has a Marshaller property that would return the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface implementation.

So, the approach that worked with VS 2005/2008 doesn't work with VS 2010.

Since you can't cast or get the Microsoft.VisualStudio.CommandBars.CommandBarPopup interface and an add-in targeting VS 2005/2008/2010 with the same dll can't include a reference to the Microsoft.VisualStudio.Shell.UI.Internal.dll, keeping this approach the only way would be to call its Delete method would be through Reflection.