Apart from these ones, other thing that I dislike a lot of SP1 of Visual Studio is that it has changed the editing experience of “ByVal” in the VB.NET code editor.

While in “classic” VB6 “ByRef” was the default and “ByVal” was required to pass parameters by value, in VB.NET it’s the opposite: “ByVal” is the default and “ByRef” is required to pass parameters by reference. However, until VS 2010 SP1, the VB.NET code editor always added “ByVal” when typing or when generating code (like in the parameters of event handlers).

My first alarm sign was reading:

Visual Basic Editor

• Mandatory ByVal is displayed in Visual Basic .NET (https://connect.microsoft.com/VisualStudio/feedback/details/542271).

in the Description of Visual Studio 2010 Service Pack 1. And indeed, after installing SP1, “ByVal” was not inserted when typing parameters in VB.NET. I tried to find some setting in the Options window to get back the old behavior, to no avail. I e-mailed the program managers who changed this behavior, which in turn introduced me the developer, and they confirmed that there is no setting (and no plans) to get the old behavior in the VB.NET code editor. So, after applying SP1:

1) If you like the old style, you have to type “ByVal” on your own.

2) Likely you will end with inconsistent styles in your VB.NET code, sometimes using “ByVal” (old code) and sometimes missing it (new code).

These irreversible changes of behavior is not what I expect from a service pack (I expect it to fix bugs, not to introduce issues). This should deserve a setting (opt-in) for those people who want to get rid of “ByVal”, and let the people who want the old behavior as they are.

I installed the Service Pack 1 (SP1) of Visual Studio 2010 last week and in a few hours I was already unhappy with it.

I use VS 2010 to develop my MZ-Tools add-in and since it targets VS 2005, VS 2008 and VS 2010 with a single binary add-in dll, the add-in project uses .NET Framework 2.0 and CLR 2.0 (the only one supported by VS 2005), not .NET Framework 4.0 with CLR 4.0. Soon after installing VS 2010 I noticed that breakpoints were not hit when debugging the add-in!

I created a new minimal add-in with the wizard and debugging worked. Then I tried to change the .NET Framework of the add-in project from 4.0 to 2.0, and the debugging stopped working. I reproduced it on two computers with SP1 applied to VS 2010, so I reported it to Microsoft:

VS 2010 SP1 breaks add-in debugging targetting .NET Framework 2.0 rather than .NET Framework 4.0
https://connect.microsoft.com/VisualStudio/feedback/details/650694/vs-2010-sp1-breaks-add-in-debugging-targetting-net-framework-2-0-rather-than-net-framework-4-0#details

And I am not the only one affected by this issue.

When I read the list of fixes of a service pack of any product, it seems that it never fixes my bugs :-(. VS 2010 SP1 doesn’t fix a random crash that I experience deleting lines in VB.NET code, and due to the previous problem I can’t test if it fixes the Performance problem (100% CPU) for long time deattaching VS 2010 after debugging an add-in that happens with VS 2010 but not with VS 2008, and according to Microsoft, not with the next version of Visual Studio.

But at least I expect that a SP doesn’t break something. This was not the case with VS 2010 SP1.

I was thinking about blogging about the different (reduced) user interface customizations in the new WPF-based toolbars of Visual Studio 2010 (the most noticeable, the totally modal Customize dialog) but I have learned today that someone else was more exhaustive reporting them to Microsoft Connect back in the Beta 2 timeframe:

Limited ability to customize VS 2010 Beta 2 IDE
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=511327

More than a year ago I wrote about .NET Frameworks, CLRs and Visual Studio add-ins, where I explained that the new CLR 4.0 can coexist (for the first time in .NET) with a different CLR (2.0) in the same Windows process, and ended that post with the following question:

If I compile a Visual Studio add-in against CLR 2.0 (and .NET Framework 2.0 to be compatible with VS 2005, VS 2008 and VS 2010), when it is loaded within Visual Studio 2010 (which uses CLR 4.0), which CLR will use that add-in: CLR 2.0 or CLR 4.0?

At that time my answer (according to a test that I did) was CLR 4.0, but it was inconclusive because I was using a Community Technology Preview (CTP) version of Visual Studio 2010 and I didn’t know the switch in a .config file that controls that behavior.

These days I am struggling with a subject that indirectly got me back to that question. So, after some more investigation, today I have a definite answer to the question:

It depends on:

1) The useLegacyV2RuntimeActivationPolicy value in the <startup> section in the devenv.exe.config file

2) Whether the add-in is COM-based or XML-based (using .AddIn file)

And specifically (bottom line):

1) XML-based (using .AddIn file) add-ins compiled against CLR 2.0 use always CLR 4.0 when loaded in VS 2010.

2) COM-based (using COM-Interop) add-ins compiled against CLR 2.0 use:

2.1) CLR 4.0 if the useLegacyV2RuntimeActivationPolicy value of the <startup> section of devenv.exe.config is true. This value means that the runtime activation policy of .NET 2.0 will be used, which is to use the latest CLR available, so the COM-based add-in built using CLR 2.0 will use actually CLR 4.0.

2.2) CLR 2.0 if the useLegacyV2RuntimeActivationPolicy value of the <startup> section of devenv.exe.config is false. This value means that the runtime activation policy of .NET 2.0 will not be used, the new runtime activation policy of .NET 4.0 will be used instead, which is to use the CLR that the add-in was compiled against, so the COM-based add-in built using CLR 2.0 will use CLR 2.0.

This can be tested showing the value System.Environment.Version.ToString() when the add-in is loaded. Notice that while the default value (when omitted) of useLegacyV2RuntimeActivationPolicy is false, Visual Studio 2010 sets it to true in its devenv.exe.config file, which means that all add-ins (whether XML-based or COM-based) will use CLR 4.0.

The official documentation about the <startup> section and the useLegacyV2RuntimeActivationPolicy attribute is:

<startup> Element
http://msdn.microsoft.com/en-us/library/bbx34a2h.aspx

and Mark Miller (Marklio) explained it in full detail:

What is useLegacyV2RuntimeActivationPolicy for?
http://web.archive.org/web/20130128072944/http://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx

The official documentation about In-Process side by side execution is here:

In-Process Side-by-Side Execution
http://msdn.microsoft.com/en-us/library/ee518876.aspx

which contains the following relevant paragraphs:

“Side-by-side hosting does not solve the compatibility problems that library developers face. A library that is directly loaded by an application — either through a direct reference or through an Assembly:Load call — continues to use the runtime of the AppDomain it is loaded into.”

and:

“In the past, managed COM components automatically ran using the latest version of the runtime installed on the computer. You can now execute COM components against the version of the runtime they were built with”

One of the things that I provide in my add-ins is that modal windows are 1) resizable and 2) with memory (that is, remembering the last size used by the user). I am passionate about user interface usability and I hate modal windows that are not resizable in today’s big screens, such as the Tools, Options window of Visual Studio. I know this is so because of historical reasons (MFC stuff or similar), but after 8 years and five Visual Studio releases (including a new WPF-based shell) you are still forced to scroll, despite you may have a big display… some new stuff like the windows related to data sources are resizable (they are implemented in .NET where resizing is more easy). I also hate the windows that are resizable, but the programmer didn’t take the extra step to persist the size when the window is closed, so the user must resize it each time that the window is opened…

Anyway, I have special code for all that stuff that resizes and centers the window before is shown, and while doing some testing with VS 2010 I noticed that something was wrong when the VS 2010 IDE was maximized because the window(s) of my add-in didn’t show centered. Finally I isolated the bug and it happens that DTE.MainWindow.Width property of the new WPF-based VS 2010 shell can return a wrong result if you maximize the IDE window by hand.

Here it is the acknowledged bug:

DTE.MainWindow.Width or DTE.MainWindow.Height don’t return correct size when IDE maximized by hand
https://connect.microsoft.com/VisualStudio/feedback/details/536703/dte-mainwindow-width-or-dte-mainwindow-height-dont-return-correct-size-when-ide-maximized-by-hand

Interestingly, it works fine if you resize the main window by code (and not by hand), so tricky and subtle are the bugs introduced by the new WPF-based shell.

Since I didn’t have any hope of getting this kind of bugs fixed for the RTM, I was able to workaround the problem in the add-in.

I updated my MZ-Tools 6.0 add-in to support Visual Studio 2010 Release Candidate and finally today March 1 I have released it.

Microsoft finally fixed most of the bugs that I have been reporting in the last months in the WPF-based commandbars so add-ins can get loaded in the IDE without crashing and AFAIK I was able to workaround all the issues that were not fixed (and won’t be in the RTM).

FWIW, some technical details:

– Internally this MZ-Tools build is compiled (using VS 2008) against .NET Framework 2.0 / CLR 2.0 and not the .NET Framework 4.0 / CLR 4.0 that VS 2010 uses (and the only that ships), but it works fine AFAIK.

– Although this MZ-Tools 6.0 build ships several assemblies (one for each VS IDE) for historical reasons (it still supports VS.NET 2002/2003), I have done tests for future versions and it seems to be possible to build a single assembly in .NET Framework 2.0 / CLR 2.0 that targets VS 2005, 2008 and 2010, using references provided by VS 2005 (that are also available in next VS versions) or using Reflection for references whose version changes between IDE versions (I think that you can use assembly redirections too).

Although not very usual, add-ins can be created for the Macros IDE too. In fact, version 6.0 of MZ-Tools integrates with the VS IDE and with its macros IDE. I will remove support for the macros IDE in future versions because I think that nobody needs/uses it and it complicates the code and the setup (specially the uninstallation), but until then, it works with both IDEs.

While the VS IDE executable is devenv.exe, the macros (VSA) IDE is vsaenv.exe. From the automation (EnvDTE) point of view, the EnvDTE.DTE class has the EnvDTE.DTE.MacrosIDE() As EnvDTE.DTE property.

Until VS 2010, each VS IDE has its own macros IDE with matching versions. However, VS 2010 (VS 10.0) actually uses the VS 2008 Macros IDE (VSA 9.0), as you can see by the look and feel (not WPF-based) and in the About window.

Joginder Nahil (from Starprint Tools) has notified me about a breaking change that I was not aware in the new WPF-based commandbars of VS 2010: the lack of support to create comboboxes on commandbars. I have been fortunate enough to avoid the need to use that UI item in my MZ-Tools add-in (I haven’t even written an article about this), but I was aware that comboboxes and MRU lists were possible since VS 2005 because of this old post of Craig Skibo (former member of the automation team of Visual Studio):

Command Bar Types – Part 2
http://blogs.msdn.com/craigskibo/archive/2005/10/20/483133.aspx

Now, in VS 2010 comboboxes are no longer creatable through automation (EnvDTE), only through packages (SDK). Here is the report:

Exception DeprecatedException occurs when adding a combobox to vs2010 IDE toolbar
https://connect.microsoft.com/VisualStudio/feedback/details/532817/exception-deprecatedexception-occurs-when-adding-a-combobox-to-vs2010-ide-toolbar

Thanks Joginder, and I am sorry the bad news.

These are two “minor” bugs that the new WPF-based commandbars of Visual Studio 2010 are going to have since won’t be fixed in this release:

VSIP: VS 2010 Dec LCTP: toolbar with CommandBar.RowIndex = -1 not created in new row
https://connect.microsoft.com/VisualStudio/feedback/details/518455

VSIP: VS 2010 Dec LCTP: CommandBar.RowIndex of toolbar not updated after creating and making it visible
https://connect.microsoft.com/VisualStudio/feedback/details/518452

If your add-in uses more than one toolbar, it can affect you. I found a workaround using big values for the RowIndex property rather than -1 to ensure that the toolbars appear below existing toolbars.