Yesterday while writing the code of an add-in for a new article I was calling Form.ShowDialog() without passing the owner window and I noticed that clicking the Visual Studio button on the Windows 7 taskbar, I got the modal form hidden behind the Visual Studio window (I had to click Alt+Tab to get the it back). Today I have been unable to reproduce this problem on another computer with Windows 7, but the other computer still reproduces it. Anyway, I already knew how to fix this problem for good, so I have documented it in this new article:

HOWTO: Show a modal form from a Visual Studio .NET add-in
http://www.mztools.com/articles/2011/MZ2011014.aspx

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