Although VS 2010 Beta 2 hasn’t been released yet, Microsoft has stopped fixing the certainly minor bugs that I have reported in the last days about the C# file code model. Instead they are currently focused “on stabilizing and improving the performance of VS2010”. This is something that has happened in the past (I remember since VS 2005): once the Beta 2 is released no feature is changed and very few bugs are fixed (only the big ones that would prevent the release of the product), but I think that this time is worse, the facts are:
Too bad. I’m talking about minor bugs that should be easy to fix, not ones requiring architectural changes that I understand will be postponed.
I find quite stressing what will happen if the WPF commandbars are not fixed correctly for Beta 2, or new bugs appear with features that were not completed in Beta 1. I’d rather see no CTPs at all and a longer series of betas instead:
- Beta 1: quite feature completed. Time to complete it and fix bugs.
- Beta 2: feature completed. Time to fix bugs.
- Beta 3: bugs fixed. Time to focus on stabilization and performance.
- RC1, etc.
At least we would have two beta cycles to get bugs fixed.
All that said, I welcome the focus on the performance of the Visual Studio (the 2005 release was quite bad in this regard).
UPDATE: Microsoft clarified that this affects only to bugs in the code model because they are investing in a new code model. See Clarification on my previous post “Microsoft no longer fixing (small) bugs for VS 2010”
Another minor bug in the C# file code model that I have reported to Microsoft:
BUG: EnvDTE.CodeElement.Name doesn’t return interface name for explictly implemented C# interface events
In the following article:
INFO: Default .AddIn file locations for Visual Studio add-ins
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:
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.
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:
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.
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
It happens too in VS 2010 Beta 1, I have reported it to Microsoft. Hopefully it can get fixed.
Another bug that I have found today:
BUG: C# indexers are not mapped to EnvDTE80.CodeProperty2 in Visual Studio macros or add-ins
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.
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
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:
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
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
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
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
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