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

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

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

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

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...

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

If you are testing your add-in with the recently released VS 2010 Beta 2 chances are that you have noticed that the new WPF-based commandbars, buttons and icons are not yet ready for prime time. It seems that my MZ-Tools add-in uses every possible method, property and technique offered by the Microsoft.VisualStudio.CommandBars API so I am discovering lots of bugs (I have reported 15 so far) since I started testing with Beta 1. I reported these two ones before Beta 2 but the fixed will come in builds

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

If you are developing add-ins for in-house use, chances are that you can drive, encourage or even force the whole organization to use the latest version of Visual Studio and therefore your add-in needs to target only that version. But if you are developing add-ins for commercial or open-source purposes, to be used by lots of people, your add-in needs to target several IDE versions (nowadays, at the very least VS 2005, 2008 and 2010). To simplify your life as a developer, you try to keep a single

As you know if you develop add-ins, Visual Studio 2005 introduced XML-based add-ins that use an .AddIn file that you must place in the proper folder for Visual Studio to show the add-in in the Add-In Manager . Which XML parser Visual Studio uses to parse .AddIn files wouldn't be of interest if it wasn't because for some people their Add-In Manager didn't show XML-based add-ins... and the problem was solved installing MSXML . While I didn't experience that problem personally, I have