Another issue related to my last post  VS 11 Beta issue: EnvDTE.Project.CodeModel returns null for a project just loaded without open documents is the following: the SolutionEvents.Opened event is not fired when you open a solution that was closed previously with all documents closed. Furthermore, the event is not firing when you open some document!.

The bug report is the following:

EnvDTE.SolutionEvents.Opened event not fired for a solution just loaded without open documents
https://connect.microsoft.com/VisualStudio/feedback/details/730000/envdte-solutionevents-opened-event-not-fired-for-a-solution-just-loaded-without-open-documents#details

Two of the unit tests of my MZ-Tools add-in failed due to a change in VS 11 Beta that took me a couple of hours to isolate: if your add-in opens a solution and no document is open (for example, because the solution was closed previously with all documents closed), the EnvDTE.Project.CodeModel property returns null. In previous Visual Studio version you could get the code model of a project even if none of its files was opened. It happens that my add-in needs to know the language of the projects of the solution, using the Project.CodeModel.Language property.

At the time of this writing I am waiting for the Visual Studio 11 Beta Performance Part #2 post on the Visual Studio blog that according to Part #1 will explain the changes loading solutions in VS 11 to perform better, which I suspect are related to this issue.

Meantime, here it is the Microsoft Connect bug report that I have opened:

EnvDTE.Project.CodeModel returns null for a project just loaded without open documents
https://connect.microsoft.com/VisualStudio/feedback/details/729987/envdte-project-codemodel-returns-null-for-a-project-just-loaded-without-open-documents#details

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.