MZTools Articles Series: HOWTO: Create a dockable toolwindow from a Visual Studio .NET add-in

Creating toolwindows in Visual Studio .NET 2002/2003 was incredibly difficult because you needed an ActiveX “shim” control to host a .NET (managed) usercontrol. Visual Studio 2005 simplified this a lot using the CreateToolWindow2 function, that doesn’t need the shim control. I have updated completely this article of January 2006 to remove “support” for VS.NET 2002/2003 and instead include a full sample code for VS 2005 and higher (in C# /  VB.NET). Don’t miss the related articles at the end of it (I will add a few ones in the next weeks for stuff related to toolwindows):

HOWTO: Create a dockable toolwindow from a Visual Studio .NET add-in
http://www.mztools.com/articles/2006/MZ2006007.aspx

MZ-Tools Articles Series: PRB: System.NotImplementedException calling EnvDTE.Project.Delete from a Visual Studio macro or add-in.

This problem was reported some weeks ago in the MSDN VSX forum. I was not aware of it before that post so I have documented it today (and fortunately the workaround is easy):

PRB: System.NotImplementedException calling EnvDTE.Project.Delete from a Visual Studio macro or add-in.
http://www.mztools.com/articles/2011/MZ2011008.aspx

MZTools Articles Series: INFO: menuCommandBar.Controls[“Tools”] works in international versions of Visual Studio 2010

Retrieving a CommandbarPopup in Visual Studio to add buttons has always been tricky. There are incorrect ways to do it:

PRB: Performance problem of DTE.CommandBars[name] for CommandbarPopups in Visual Studio 2010
http://www.mztools.com/articles/2011/MZ2011005.aspx

BTW, I have updated this popular article to avoid that performance problem in VS 2010:

HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in
http://www.mztools.com/articles/2005/MZ2005003.aspx

and there are correct ones:

HOWTO: Locate commandbars in international versions of Visual Studio.
http://www.mztools.com/articles/2007/MZ2007002.aspx

HOWTO: Get a CommandBar by Guid and Id rather than by name from a Visual Studio add-in.
http://www.mztools.com/articles/2011/MZ2011004.aspx

And now Visual Studio 2010 introduces a new one, which is correct, but doesn’t work in international versions of Visual Studio 2005 and 2008:

INFO: menuCommandBar.Controls[“Tools”] works in international versions of Visual Studio 2010
http://www.mztools.com/articles/2011/MZ2011006.aspx

MZTools Articles Series: PRB: Performance problem of DTE.CommandBars[name] for CommandbarPopups in Visual Studio 2010

While not recommended because there can be two different  commandbar popups with the same name, you could use DTE.CommandBars[commandBarPopupName] to retrieve the commandbar of a CommandbarPopup from the DTE.CommandBars collection. However, the new WPF-based commandbars of Visual Studio 2010 introduce a performance problem when doing it so if the commandbar popup has not been displayed in the Visual Studio user interface.

This new article exposes the problem and provides proper ways to retrieve a commandbar popup:

PRB: Performance problem of DTE.CommandBars[name] for CommandbarPopups in Visual Studio 2010
http://www.mztools.com/articles/2011/MZ2011005.aspx

MZ-Tools Articles Series: BUG: EnvDTE80.CodeEvent.Comment doesn’t return “” for C# events without doc comment

This article documents a small bug of the Visual Studio code model:

BUG: EnvDTE80.CodeEvent.Comment doesn’t return “” for C# events without doc comment
http://www.mztools.com/articles/2011/MZ2011007.aspx

The bug report that I filed to Microsoft Connect is here:

https://connect.microsoft.com/VisualStudio/feedback/details/652387/envdte80-codeevent-comment-returns-doc-doc-instead-of-for-c-events-without-doc-comment#details