Add-Ins

Microsoft fixing the hardcoded, unlocalized “Application Data” subfolder when searching for .AddIn files

In the following article:

INFO: Default .AddIn file locations for Visual Studio add-ins
http://www.mztools.com/articles/2008/MZ2008001.aspx

I mentioned the problem with one of the locations (%ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\AddIns) that hardcodes “Application Data” subfolder, when it should be localized.

I reported the problem to Microsoft and it will be fixed in VS 2010 Beta 2:

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

All add-in developers using that location should pay attention because if Microsoft don’t follow my advice (mentioned in the bug report) of keeping the wrong location and adding a new, correct, one and they just change them instead, add-ins will be broken in international versions of Windows (because VS would no longer would search in the hardcoded path that many add-ins use). Stay tuned.

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

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

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

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

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

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

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

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

Other

MS fixing problem with the 6th path where Visual Studio searches for .AddIn files

According to the last notification from Microsoft, they have fixed the problem where the 6th location (%ALLUSERSDOCUMENTS%\Microsoft\MSEnvShared\AddIns) that was introduced by VS 2008 when searching for .AddIn files was broken (it’s about time):

%ALLUSERSDOCUMENTS%\Microsoft\MSEnvShared\AddIns folder is not searched for add-ins
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=466741

The fix is quite irrelevant currently because VS 2005 doesn’t support that folder and VS 2008 is broken (even with SP1), but in a few years when your add-in has only to support VS 2010 and above versions, that location will be the preferred choice because being an “all users” location:

1) It doesn’t suffer the localization problem of %ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\AddIns

2) If doesn’t force you to use separate .AddIn files for each VS version as happens with %VSCOMMONAPPDATA%\AddIns

See: INFO: Default .AddIn file locations for Visual Studio add-ins

VS 2010

MS fixing problem with 32-bit bitmaps with alpha channel for transparency in SetTabPicture method of toolwindows

The little problem that I reported when using the SetTabPicture method with a 32-bit bitmap with alpha channel for transparency has been fixed according to the last notification from Microsoft for the following VS 2010 beta build:

EnvDTE.Window.SetTabPicture doesn’t support 32-bit bitmaps with transparency in alpha channel when toolwindow not active
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=470236

That means that for the first time a Visual Studio version (2010) will support 32-bit bitmap with alpha channel for transparency both for add-in command pictures (EnvDTE.DTE.AddNamedCommand) and toolwindow pictures (EnvDTE.Window.SetTabPicture), and you can get rid of magenta (RGB=255,0,255) and almost green (RGB=0,254,0) hacks in add-ins, which is really great and very close to the support for icons with built-in transparency that I have been battling for all these years. I don’t care if I have to use 32-bit bitmaps with alpha channel instead of icons. It is also great because in most cases the toolwindow picture is the same than the picture of the command that shows the toolwindow, so you can use the same picture without re-colorizing the background from green to magenta or transparent when calling SetTabPicture, or providing two versions of the same picture with different backgrounds.

The only problem is if you still have to support old versions of Visual Studio (2005, 2008) which I guess will be the case for most commercial add-ins because VS 2010 doesn’t support the RGB=0,254,0 color for command picture transparency that was used in those versions, this issue is still active at the time of this writing (Update (August 6): VS 2010 Beta 2 will support RGB=0,254,0 too for backwards compatibility):

Custom pictures in CommandBarButtons created by add-in don’t show a transparent background
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=461192

MZ-Tools Articles Series

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

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

VS SDK, packages, add-ins, macros and more…