This is one of those rare cases where both the Name and FullName properties of an EnvDTE.CodeElement can return an exception “by design”!:
PRB: FullName and Name properties of EnvDTE.CodeElement return exceptions for using/Imports statements of C# and VB.NET
http://www.mztools.com/articles/2011/MZ2011013.aspx
Fortunately, there is an easy workaround.
Another question that is asked from time to time in the forums and whose answer requires some ellaboration and references to other articles:
HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET.
http://www.mztools.com/articles/2011/MZ2011012.aspx
Almost three years ago I wrote this post about Visual Studio version numbers. At that time, Visual Studio 2010 was at Community Technology Preview (CTP) state, not even beta, and some values changed in the Release To Manufacturing (RTM) release. Today I have written this new article for the MZ-Tools Articles Series with updated information and some fix:
INFO: Visual Studio version numbers.
http://www.mztools.com/articles/2011/MZ2011011.aspx
As you can see, version numbers are inconsistent across Visual Studio versions. You may have noticed that even the .NET Framework version has become inconsistent: previously you had .NET Framework 1.0, 1.1, 2.0, 3.0 and 3.5, and the new version is officially named .NET Framework 4, not .NET Framework 4.0.
This is another article that was in my list of articles “pending to write” and that is asked from time to time in the forums:
HOWTO: Detect when a Visual Studio toolwindow is shown or hidden
http://www.mztools.com/articles/2011/MZ2011010.aspx
This is a problem that a developer sent me by e-mail and after reproducing it I have documented it here:
BUG: COMException getting DocComment of method of generic base class
http://www.mztools.com/articles/2011/MZ2011009.aspx
and I have opened a bug report at Microsoft Connect:
COMException getting DocComment for method in generic base class in C#
https://connect.microsoft.com/VisualStudio/feedback/details/683116/comexception-getting-doccomment-for-method-in-generic-base-class-in-c
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
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
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
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
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: