Since Visual Studio 2008 introduced multi-targeting .NET Framework, one weird thing of VB.NET projects was that to change the .NET Framework of a VB.NET application you had to go to the project properties window, “Compile” section (whose settings depend on the Configuration and Platform!), click the “Advanced Compiled Options…” and then you had a “Target framework (all configurations)” combobox. Meantime C# projects used the natural location for that combobox: the “Application” section, whose settings don’t depend on the Configuration and Platform.

VS 11 Beta finally fixes this issue for VB.NET projects and the “Target framework” combobox now belongs to the “Application” section, its natural place and much more visible.

The automation model (EnvDTE) for add-in and macros was right and the “TargetFramework” property belongs to the application (EnvDTE.Project.Properties), as shown in my article:

HOWTO: Get the target .NET Framework of a Visual Studio 2008 project from a Visual Studio add-in or macro
http://www.mztools.com/articles/2008/MZ2008015.aspx

When running the unit tests of my MZ-Tools add-in today, I have found the following exception when creating a Class Library project:

System.Runtime.InteropServices.COMException (0x80042003): The project file ‘<omitted>’ cannot be opened.

The project type is not supported by this installation.
at Microsoft.VisualStudio.Windows.UI.Xaml.Project.ProjectFlavoring.TailoredLibraryProject.OnAggregationComplete()
at Microsoft.VisualStudio.Shell.Flavor.FlavoredProjectBase.Microsoft.VisualStudio.Shell.Flavor.IVsAggregatableProjectCorrected.OnAggregationComplete()
at EnvDTE.SolutionClass.AddFromTemplate(String FileName, String Destination, String ProjectName, Boolean Exclusive)
at Microsoft.VisualStudio.TemplateWizard.Wizard.Execute(Object application, Int32 hwndOwner, Object[]& ContextParams, Object[]& CustomParams, wizardResult& retval)
at EnvDTE.SolutionClass.AddFromTemplate(String FileName, String Destination, String ProjectName, Boolean Exclusive)

Debugging it I have found that the unit test was using the following template to create the project:

“C:\Program Files (x86)\Microsoft Visual Studio
11.0\Common7\IDE\ProjectTemplatesCache\VisualBasic\Windows Metro
style\1033\ClassLibrary.zipClassLibrary.vstemplate”

while in the past (using other VS versions and even VS 11 Developer Preview if I remember correctly) it was using:

“C:\Program Files (x86)\Microsoft Visual Studio
11.0\Common7\IDE\ProjectTemplatesCache\VisualBasic\Windows\1033\ClassLibrary.zipClassLibrary.vstemplate”

Notice that the former template belongs to “Windows Metro style” apps and the latter one belongs to “Windows” apps.

The unit test uses the following code to get the template:

EnvDTE80.Solution2.GetProjectTemplate(“ClassLibrary.zip”, “VisualBasic”)

and the root problem is that the “ClassLibrary.zip” template file name is duplicated in two folders, and therefore there is a conflict. According to the MSDN docs, templates should not duplicate names:

“Custom templates require unique file names that do not conflict with the file names defined in:

<drive>:Program Files\Microsoft Visual Studio 8\Common7\IDE\ProjectTemplates\Language

The doc refers to custom templates, but obviously it assumes that built-in templates provided by Microsoft already use unique names.

So, I have opened a bug report in Microsoft Connect:

EnvDTE80.Solution2.GetProjectTemplate(“ClassLibrary.zip”, “VisualBasic”) returns Windows Metro template
https://connect.microsoft.com/VisualStudio/feedback/details/728382/envdte80-solution2-getprojecttemplate-classlibrary-zip-visualbasic-returns-windows-metro-template

The workaround is to hardcode portions of the path to templates in the unit tests, avoiding the Solution2.GetProjectTemplate method. UPDATE (05-JUL-2013): Apparently there is another workaround for the C# case using GetProjectTemplate(“csClassLibrary.vstemplate”, “CSharp”) instead. For VB.NET it doesn’t work because the template is named classlibrary.vstemplate and not vbClasslibrary.vstemplate.

A couple of days ago VS 11 Beta was released. I installed it yesterday and I am still shocked. A few days before, we could read in the Visual Studio Blog about the “New Developer Experience” of VS 11. First I thought is was a joke what I was reading, as if it was April 1 (in Spain that day for jokes is December 28 so I always forget April 1). Then I noticed that is was real. Some (new?) design team has taken full control of the user interface of Visual Studio and, well, you can read the post and the 750+ comments at the time of this writing. VS 11 Beta is almost gray, no colors, no borders, no gradients, toolwindow captions that are SHOUTING and with “:::::::::::::” characters that seem to come from the text-based screens of MS-DOS applications a couple of decades ago. Furthermore, you can choose between the “Light” and the “Dark” color themes, but no “VS 2010” color theme is provided.

Something is severely broken at the Visual Studio team in charge of the user interface since a couple of versions ago:

• In VS 2010 they changed the commandbars from Office-based to WPF-based causing lot of havoc during the CTPs and betas (I reported lots and lots of bugs) as I explained in the post “Visual Studio “painful” releases and “painless” releases for add-ins. VS 2010 belongs to the first group (by far). And maybe next ones too…” to provide no real benefit to the developers, and even causing some loss such as not being able to drag toolbars or adding comboboxes to toolbars.
• In VS11 they have concluded that one of the problems of Visual Studio is that its colors distract the developers from the code, and that the solution is to become gray (dark or light). Yeah. That was of the problems of Visual Studio, the colors. Not the performance, or the memory usage, or bugs, the colors!!!. You know what? You can hide the toolbars and the toolwindows if colors distract you. And an even better solution is to use Notepad to write code (which won’t distract you) and use the command-line compiler.

Furthermore, not only toolbar icons are affected. All the user interface is affected if you want to match the new themes. For example, if you use toolwindows that use icons for classes, interfaces, methods, etc.

What strikes me most is that nobody in the huge VS team (hundreds of developers) or in the VS management team (Scott Guthrie, Brian Harry, etc. or even S. Somasegar) has stopped this abomination before going Beta. This causes a lot of uncertainty to developers of extensions given the huge negative feedback and future direction:

• How many betas will be? This has not been named “Beta 1”, but “Beta” (scary?)
• How much time to final release (RTM)?
• Will the VS 2010 theme color be back?
• Will the Dark and Light theme colors be gone?
• Will they coexist?
• Should an extension that provides toolbars match the horrible Dark and Light themes, or be a color oasis in the gray desert?
• Can the same custom pictures of an extension be used for both the Dark
  and Light themes, or two custom pictures must be provided?
• How to provide custom pictures dynamically when the user changes the theme in the Options window?
• Should I wait until next beta or release candidate?
• Should I stop my current extension and get rich creating a new extension for VS 11 that provides commands, menus, toolbars and toolwindows that do the same that the ones of VS 11, but with color? 😉

My personal approach is that I will stick to VS 2010 during the next two years if VS 11 is released with the current color themes because actually they distract me a lot. About matching the new color themes in my MZ-Tools add-in, it won’t be my priority now. First I have to run hundreds of unit tests to check that they work and ensure that no bugs are introduced by VS 11, or get Microsoft to fix them. I already reported two of them here and here and more are coming in next posts.

This is another issue caused by the VS 11 and the new Find feature with .NET regular expressions change that has been acknowledged and closed as fixed (supposedly in the next build):

Add-Ins: textRanges of EditPoint.FindPattern returns incorrect values for second occurrence
https://connect.microsoft.com/VisualStudio/feedback/details/712348/add-ins-textranges-of-editpoint-findpattern-returns-incorrect-values-for-second-ocurrence

The VS 11 and the new Find feature with .NET regular expressions change not only affects the EditPoint.FindPattern method, it also affects the EditPoint.ReplacePattern method.

I have found an issue that I reported to Microsoft Connect as a bug but it has been closed as “Not reproducible”. Anyone can reproduce it and post a comment?:

Microsoft Connect Bug Report: EditPoint.ReplacePattern in add-in causes COMException 0x800A00B9
https://connect.microsoft.com/VisualStudio/feedback/details/712582/editpoint-replacepattern-in-add-in-causes-comexception-0x800a00b9#details

Update (Jan 14): Microsoft closed this bug report indicating that was fixed in the next build

Update (Mar 3): certainly it has been fixed in VS 11 Beta, released three days ago.

When Microsoft released Visual Studio .NET and the .NET Framework 1.0 back in 2002, one of the quirks of the IDE was that while the .NET Framework has one syntax for regular expressions, the Find dialog has another syntax for them. This has been so for ten years and five Visual Studio releases (2002, 2003, 2005, 2008 and 2010), but finally in VS 11 the IDE will use the .NET Framework syntax for regular expressions, and wildcards support will be removed.

This has two consequences for developers extending Visual Studio, either with macros or with add-ins using the EnvDTE.EditPoint.FindPattern(pattern, vsFindOptionsValue, …) method of the automation model:

• In VS 11 the vsFindOptionsWildcards value is no longer supported. You need to use regular expressions now.
• In VS 11 the vsFindOptionsRegularExpression value now refers to .NET regular expressions, not to VS.NET regular expressions. That is, likely you need to change the pattern value for the FindPattern method to work the same in VS 2010 and VS 11.

Service Pack 1 of Visual Studio 2010 introduced a bug when debugging add-ins in VS 2010 targeting .NET Framework 2.0 that I blogged about back in March. They were kind enough to contact me some months ago to try a private hotfix (which was successful) and yesterday they made it public.

The Microsoft Connect bug report that I opened was this:

http://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

and the new Knowledge Base (KB) article with the hotfix is this:

FIX: Breakpoints are not hit when you debug a Visual Studio Add-in project that targets the .NET Framework 2.0 in Microsoft Visual Studio 2010 SP1
http://support.microsoft.com/kb/2591546