Sergey Vlasov, from Tabs Studio, has found a workaround to the problem of VS 2010 SP1 breaks add-in debugging targetting .NET Framework 2.0 that I posted yesterday:

Debugging add-ins for Tabs Studio in VS 2010 SP1
http://blog.tabsstudio.com/2011/03/16/debugging-add-ins-for-tabs-studio-in-vs-2010-sp1/

Thanks, Sergey.

On the other hand, apparently this problem debugging add-ins targeting something below .NET Framework 4.0 can also happen without SP1 according to this report in the MSDN VXS Forum (although the reports refers to a shared add-in for Office, not an add-in for Visual Studio 2010)

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.