Carlos Quintero (Microsoft MVP) blog : MZ-Tools Articles Series

MZ-Tools Articles Series: BUG: EnvDTE.CodeFunction.Parameters causes COM Exception with C# event add/remove methods in Visual Studio macros or add-ins

carlosq — Sun, 26 Jul 2009 19:35:00 GMT

And yet another bug in the file code model of C# that happens with events:

BUG: EnvDTE.CodeFunction.Parameters causes COM exception with C# event add/remove methods in Visual Studio macros or add-ins:
http://www.mztools.com/articles/2009/MZ2009019.aspx

Curiously this didn't happen with VS.NET 2002/2003 when CodeEvent didn't exist (it was introduced as EnvDTE80.CodeEvent in VS 2005) and C# events were mapped to EnvDTE.CodeProperty.

I have also reported it to Microsoft through Microsoft Connect.

MZ-Tools Articles Series: BUG: EnvDTE.CodeFunction.Attributes doesn't work with C# property get/set methods in Visual Studio macros or add-ins

carlosq — Sun, 26 Jul 2009 13:23:00 GMT

Another bug of the file code model for C#:

BUG: EnvDTE.CodeFunction.Attributes doesn't work with C# property get/set methods in Visual Studio macros or add-ins
http://www.mztools.com/articles/2009/MZ2009018.aspx

It happens too in VS 2010 Beta 1, I have reported it to Microsoft. Hopefully it can get fixed.

MZ-Tools Articles Series: BUG: C# indexers are not mapped to EnvDTE80.CodeProperty2 in Visual Studio macros or add-ins

carlosq — Wed, 22 Jul 2009 13:21:00 GMT

Another bug that I have found today:

BUG: C# indexers are not mapped to EnvDTE80.CodeProperty2 in Visual Studio macros or add-ins
http://www.mztools.com/articles/2009/MZ2009017.aspx

It only happens in VS 2005 and VS 2008. Curiously it is alrady fixed in VS 2010 Beta 1.

If you need to access the parameter collection of a C# indexer, since EnvDTE.CodeProperty lacks a Parameters property and you can't get an EnvDTE80.CodeProperty2 (which doesn't lack it), you need to use the Getter or Setter properties of EnvDTE.CodeProperty and use the EnvDTE.CodeFunction.Parameters property.

MZ-Tools Articles Series: BUG: EnvDTE.CodeElement.GetStartPoint(vsCMPart.vsCMPartBody) returns wrong result for VB.NET classes using the Implements or Inherits clauses

carlosq — Tue, 21 Jul 2009 14:05:00 GMT

This is a bug that I have found twice in the last couple of days:

EnvDTE.CodeElement.GetStartPoint(vsCMPart.vsCMPartBody) returns wrong result for VB.NET classes using the Implements or Inherits clauses
http://www.mztools.com/articles/2009/MZ2009016.aspx

The bug was not present in VS.NET 2003, it appeared in VS 2005, it is in VS 2008 and also in VS 2010 Beta 1. You can vote to get it fixed here:

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

MZ-Tools Articles Series: HOWTO: Get the output build folder from a Visual Studio add-in or macro

carlosq — Fri, 17 Jul 2009 11:05:00 GMT

This gets asked from time to time in the forums so I wrote a sample code about it:

HOWTO: Get the output build folder from a Visual Studio add-in or macro
http://www.mztools.com/articles/2009/MZ2009015.aspx

MZ-Tools Articles Series: BUG: EnvDTE.Project.CodeModel doesn't retrieve attributes in the AssemblyInfo file

carlosq — Wed, 01 Jul 2009 11:39:00 GMT

If you are trying to retrieve attributes in the assemblyinfo file, it's better to use the ProjectItem.FileCodeModel rather than the Project.CodeModel:

BUG: EnvDTE.Project.CodeModel doesn't retrieve attributes in the AssemblyInfo file
http://www.mztools.com/articles/2009/MZ2009014.aspx

The bug report for Microsoft is here:

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

MZ-Tools Articles Series: PRB: PEVerify.exe causes problem verifying add-in with referenced assemblies from Visual Studio not in the GAC

carlosq — Mon, 29 Jun 2009 15:15:00 GMT

I am currently working on a new version of MZ-Tools and yesterday I updated its build script. When running it, to my surprise, I found the following error in the step that verifies the assembly with the peverify.exe tool after the obfuscation step:

Error 0x80070002 "The system cannot find the file specified"

After diagnosing the problem with the Assembly Binding Log Viewer, I found that the file in question was the Microsoft.VisualStudio.Data.Interop.dll assembly that this version of MZ-Tools will reference for one of its features. This file, on the contrary to others such as Microsoft.VisualStudio.Shell.Interop.8.0.dll, does not reside on the Global Assembly Cache (GAC) and, as any Visual Studio assembly, should not be distributed, the VS IDE will find it. However, when using the peverify.exe tool, that referenced assembly is not found.

Fortunately Microsoft has ways to fix for all these problems through a .config file. Long time ago I posted how to fix the problem PEVerify.exe causes problem with EnvDTE.dll verifying Visual Studio 2005 add-ins and this new article explains how to fix this other problem:

PRB: PEVerify.exe causes problem verifying add-in with referenced assemblies from Visual Studio not in the GAC
http://www.mztools.com/articles/2009/MZ2009013.aspx

MZ-Tools Articles Series: updated articles

carlosq — Tue, 23 Jun 2009 13:44:00 GMT

I have updated the following MZ-Tools Series articles to fix/explain better some things, provide C# code some cases, cover Windows Vista folders, cover Visual Studio 2008/2010 in some other cases, etc:

HOWTO: Removing commands and UI elements during Visual Studio .NET add-in uninstallation
http://www.mztools.com/Articles/2005/MZ2005002.aspx

HOWTO: Reset a Visual Studio add-in
http://www.mztools.com/Articles/2006/MZ2006014.aspx

HOWTO: Get rid of a Visual Studio add-in
http://www.mztools.com/Articles/2006/MZ2006018.aspx

INFO: Visual Studio .NET Add-In Commands Disappear On Next Session
http://www.mztools.com/Articles/2005/MZ2005014.aspx

MZ-Tools Articles Series: BUG: Infinite recursion in add-in causes Visual Studio crash

carlosq — Mon, 16 Mar 2009 10:57:00 GMT

This bug that I commented in a previous blog entry and that I reported to Micorosoft through Microsoft Connect is not going to be fixed in the next version VS 2010:

Add-in causing stack overflow causes "Microsoft Visual Studio has encountered a problem and needs to close"
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=414301

So, there will be three versions of Visual Studio affected. I have written a MZ-Tools article to document it:

BUG: Infinite recursion in add-in causes Visual Studio crash
http://www.mztools.com/articles/2009/MZ2009004.aspx

MZ-Tools Articles Series: INFO: Testing a Visual Studio add-in against new Visual Studio tools or extensions from Microsoft

carlosq — Fri, 13 Mar 2009 08:12:00 GMT

When you create your Visual Studio extension, whether an add-in or package, likely you test it most of the time against project types provided by Visual Studio out of the box, such as VB.NET/C# projects, smartdevice projects, database projects, etc.

Long time ago I wrote an article warning that likely add-ins fail throwing exceptions when tested against 3rd party project types, because they tend to be "unmodeled projects" (meaning that they don't support automation):

PRB: Add-ins fail with 3rd party project kinds in Visual Studio .NET
http://www.mztools.com/articles/2004/MZ2004006.aspx

New project types can introduce new icons for project/project items, new text file types that are searchable, etc. so your add-in can be affected.

While you may argue that it is annoying and time-consuming to test an add-in/package against every single new project type that any 3rd party company feels the need to create, there are new project types from a company that you should test: the new project types from Microsoft itself. This is because they are extensions for Microsoft products and technologies and very likely they will be installed on tons of computers with Visual Studio. My latest article mentions some of the new extensions or tools for Visual Studio that you should test against:

INFO: Testing a Visual Studio add-in against new Visual Studio tools or extensions from Microsoft
http://www.mztools.com/Articles/2009/MZ2009003.aspx

MZ-Tools Articles Series: HOWTO: Prevent dead CommandBarButtons when Visual Studio or an add-in crashes

carlosq — Tue, 10 Mar 2009 16:39:00 GMT

This is another problem that was bugging me for quite some time: if an add-in uses a temporary user-interface rather than a permanent one when adding buttons to a built-in toolbar of Visual Studio, the add-in must remove the buttons when unloaded, typically keeping a reference to the CommandBarButton instance and calling the CommandBarButton.Delete method in the OnDisconnection method.

This approach has a problem that was affecting some customers of my MZ-Tools add-in: if Visual Studio or the add-in crashes, the add-in doesn't have the chance of removing those buttons and they stay there forever, creating duplicates the next one that the add-in is loaded.

A better approach is to delete the command, rather than the button, when the add-in is unloaded (the command should be recreated rather than deleted to keep keyboard bindings). Deleting a command deletes all buttons, even "dead" ones. While this new approach doesn't prevent duplicated buttons, they only stay there for a session. Using this new approach also solves the sporadic problem of COMException 0x800A01A8 that I already blogged about.

I have just written a new MZ-Tools Series article about this:

HOWTO: Prevent dead CommandBarButtons when Visual Studio or an add-in crashes
http://www.mztools.com/articles/2009/MZ2009002.aspx

FWIW, MZ-Tools 6.0.0.93 (February 1, 2009) uses this new approach, which solves both problems.

MZ-Tools Articles Series (update) HOWTO: Automating Visual Studio .NET from outside the IDE

carlosq — Tue, 25 Nov 2008 09:00:00 GMT

I am these days trying to create a single .NET application that can automate all the Visual Studio versions installed on a machine (from Visual Studio .NET 2002 to Visual Studio 2010). For that purpose I have created a .NET application using Visual Studio .NET 2002 so it uses .NET Framework 1.0, which can run on any .NET Framework. Since I want to use early binding, I need to add a reference to EnvDTE.dll. And here I have found a problem; it happens that there are two versions of EnvDTE.Dll:

- Version 7.0.3300.0: it is installed by Visual Studio .NET 2002 and 2003, but not by Visual Studio 2005 or higher.

- Version 8.0.0.0: it is installed by Visual Studio 2005 or higher, but not by Visual Studio .NET 2002 or 2003.

So, depending on the Visual Studio versions installed, you can have one version, the other, or both.

If the ,NET application references version 8.0.0.0, it won't work when only Visual Studio .NET 2002 or 2003 are installed. If it references version 7.0.3300.0, it won't work when only Visual Studio 2005 or higher is installed. Using a .config file to redirect version 7.0.3300.0 to 8.0.0.0 won't help, because if the system has only version 7.0.3300.0 installed, after the redirection it won't find version 8.0.0.0.

That means that you can't automate all Visual Studio versions starting with Visual Studio .NET 2002 or 2003 using early binding. You have to use late binding, either using Option Strict Off (VB.NET) or Reflection (VB.NET / C#).

I have updated accordingly the article that I wrote back in 2005:

HOWTO: Automating Visual Studio .NET from outside the IDE
http://www.mztools.com/articles/2005/MZ2005005.aspx

MZ-Tools Articles Series: BUG: Standard user unable to load/unload COM-based add-ins registered for all users with the VS 2008 Add-in Manager on Windows Vista

carlosq — Wed, 17 Sep 2008 17:11:00 GMT

Almost a couple years ago I wrote an article The Add-In Manager of Visual Studio 2005 got broken...and won't be fixed for SP1 and while Visual Studio 2008 fixed that problem, it has introduced a new one when running on Windows Vista, and guess what...(read more)

MZ-Tools Articles Series: HOWTO: Using the Process Monitor (ProcMon) tool to diagnose Visual Studio add-ins problems

carlosq — Tue, 16 Sep 2008 09:10:00 GMT

Last year I wrote a quite popular article HOWTO: Troubleshooting Visual Studio and Office add-ins , to diagnose many common problems with add-ins for Visual Studio or even Office. One invaluable tool to diagnose a whole range of problems with an add-in...(read more)

MZ-Tools Articles Series (update) INFO: Default .AddIn file locations for Visual Studio add-ins

carlosq — Tue, 02 Sep 2008 21:35:00 GMT

I have updated the article that I wrote back in January about default folders to place .AddIn registration files for add-ins to include actual examples for Windows Vista since the original article only showed Windows XP examples. I have also provided...(read more)

MZ-Tools Articles Series: HOWTO: Add an error with navigation to the Error List from a Visual Studio add-in

carlosq — Wed, 13 Aug 2008 15:16:00 GMT

It is conspicuous that the EnvDTE80.ErrorItems collection introduced by VS 2005 lacks an Add method to add errors to the ErrorList, so it was a common belief, apparently even within Microsoft and also mine until recently that only SDK packages can add...(read more)

MZ-Tools Articles Series: HOWTO: Get an OutputWindowPane to output some string from a Visual Studio add-in or macro

carlosq — Wed, 13 Aug 2008 14:22:00 GMT

To deal with international versions of Visual Studio and other Microsoft products (such as Office) has always been tricky. I think to remember that many years ago some version of Excel went as far as localizing the VBA statements (or macro language before...(read more)

MZ-Tools Articles Series: HOWTO: Retrieve the Command that created a CommandBarControl from a Visual Studio add-in or macro

carlosq — Fri, 08 Aug 2008 09:59:00 GMT

The question "How do I retrieve a Command from a CommandBarControl?" has been posted in the forums at least a couple of times and my answer always was "It's not possible" because the CommandBarControl lacks a Command property,...(read more)

MZ-Tools Articles Series: HOWTO: Get Microsoft Office bitmaps for Visual Studio add-ins

carlosq — Fri, 01 Aug 2008 12:24:00 GMT

I have been struggling during the last weeks to get 32x32 icons from Office 2007 and yesterday I found the 2007 Office System Add-In: Icons Gallery . Also, a question that appears from time to time in the forums is how to get the numerical indexes of...(read more)

MZ-Tools Articles Series: HOWTO: Handling buttons and toolbars user customizations from a Visual Studio add-in

carlosq — Wed, 30 Jul 2008 14:10:00 GMT

Visual Studio allows a rich customization of its user interface and, alas, it can affect your add-in. This new article of mine examines some common customization scenarios and how your add-in can handle them more or less gracefully: HOWTO: Handling buttons...(read more)