If Monty Hammontree and his team continue to ignore the community feedback like so far, this is the macro that you need to fix the ALL CAPS of the main menu of VS 11:
Sub NoALLCAPS()
Dim commandBar As Microsoft.VisualStudio.CommandBars.CommandBar
commandBar = CType(DTE.CommandBars, Microsoft.VisualStudio.CommandBars.CommandBars).Item("MenuBar")
For Each control As Microsoft.VisualStudio.CommandBars.CommandBarControl In commandBar.Controls
control.Caption = StrConv(control.Caption, VbStrConv.ProperCase)
Next
End Sub
Disclaimer: I haven't tested it in VS 11, I created a similar one to set ALL CAPS in VS 2010 just for fun and I got dismayed ;-)
Oops! they removed the Macro IDE...
My MZ-Tools add-in was experiencing a random "System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL
has been returned from a call to a COM component." when using the EnvDTE.DTE.ActiveSolutionProjects property that I knew that other developer reported in the MSDN VSX Forum in January. Today I tested a guess of Ryan Molden (from Microsoft) in his answer about a dependency on the visibility of the Solution Explorer and he was right.
But when I was writing the corresponding MZ-Tools Series article as I always do to document all the issues and bugs of the Visual Studio automation model (EnvDTE), I noticed that the problem didn't happen in Visual Studio 2005 or 2008, only in VS 2010, so rather than considering it a "by design" issue, I opened a bug at Microsoft Connect:
BUG: DTE.ActiveSolutionProjects property causes COMException if Solution Explorer is not shown
https://connect.microsoft.com/VisualStudio/feedback/details/735830/bug-dte-activesolutionprojects-property-causes-comexception-if-solution-explorer-is-not-shown#details
So, in VS 2010 the problem happens when one condition is met: The Solution Explorer is not shown.
Then, I tried in VS 11 Beta, which is more annoying because the Macros IDE is gone and you have to use an add-in to reproduce bugs, and I noticed that the problem doesn't happen when a solution is loaded, but still happens when two conditions are met: The Solution Explorer is not shown and there is no solution loaded. So, I opened a separate bug against VS 11 Beta:
BUG: DTE.ActiveSolutionProjects property causes COMException if Solution Explorer is not shown and no solution loaded
https://connect.microsoft.com/VisualStudio/feedback/details/735835/bug-dte-activesolutionprojects-property-causes-comexception-if-solution-explorer-is-not-shown-and-no-solution-loaded#details
Since my laptop has several software issues that will require a fresh installation at some point in the near future, I decided to install VS 11 Beta side by side with VS 2010, and one thing that I noticed the other day was that my MZ-Tools add-in, when loaded in VS 2010, was showing gray pictures (rather than color pictures) for controls of the System.Windows.Forms namespace in some of its features.
Yesterday I decided to investigate the glitch and I noticed that the Document Outline built-in toolwindow of VS 2010 was also affected. Since my add-in gets the icons from the embedded resources of the System.Windows.Forms library, calling type.Assembly.GetManifestResourceStream(type, type.Name & ".bmp"), I used .NET Reflector to examine the resources and certainly it seems that VS 11 Beta installs a new version of System.Windows.Forms 4.0.0.0 that uses the new awful gray icons for controls, while the original System.Windows.Forms 4.0.0.0 of VS 2010 used colored icons. This seems to be a case of breaking the look & feel backwards compatibility of a product ;-)
I reported it to Microsoft last night. You can see the attached image in the bug report to know what I mean:
Document Outline toolwindow of VS 2010 shows icons of VS 11 Beta (gray)
https://connect.microsoft.com/VisualStudio/feedback/details/735124/document-outline-toolwindow-of-vs-2010-shows-icons-of-vs-11-beta-gray#details
So, not only the new developer experience of VS 11 is the most hated feature, it also affects some features of VS 2010 and 3rd party extensions for that IDE when VS 11 Beta is installed side by side. And AFAIK, Microsoft continues to be silent about the future of the new look and feel introduced by VS 11 Beta, despite the huge negative response of the community of VS developers.
This one that I mentioned in my last post that I would investigate has been extremely easy:
HOWTO: Create a command with a custom picture using an ImageList for a XML-based Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012005.aspx
And Microsoft updated correctly the documentation for Visual Studio 2010 regarding the new possibilities of the Bitmap parameter of the EnvDTE80.Commands2.AddNamedCommand2 method:
EnvDTE80.Commands2.AddNamedCommand2
http://msdn.microsoft.com/en-us/library/envdte80.commands2.addnamedcommand2(VS.100).aspx
I should have written the following article near two years ago, but also Microsoft should have provided this way of creating commands with custom pictures without the need for satellite dlls 10 years ago, since the very beginning of VS.NET 2002:
HOWTO: Create a command with a custom picture without using a managed satellite DLL for a XML-based Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012004.aspx
The history has been quite compolicated:
- Visual Studio .NET 2002 and 2003 only supported COM-based add-ins that required native Visual C++ Win32 satellite dlls to provide custom pictures.
- Visual Studio 2005 introduced XML-based add-ins (using an .AddIn file to register the add-in within Visual Studio) and managed (VB.NET/C#) satellite dlls.
- As documented in the Microsoft Connect Bug Report 336868, I requested to Microsoft during the VS 2010 beta to following: "Satellite DLLs (managed or native) should not be required. They may be
OK for string localizations, but please don't force us to create
satellite DLLs for pictures that could be in the own assembly add-in."
- In the same bug report, Suzanne Hansen (the Program Manager of Visual Studio Platform Shell Team at that time) answered that (in VS 2010) "There will be support for loading a command's bitmap from the add-in module if there is no satellite DLL or if the satellite DLL doesn't contain the image."
- And that was my knowledge of the matter until two days ago, when while writing the add-ins for the article I discovered that Visual Studio 2008 already supported providing custom pictures in a resource file of the add-in dll rather than through a satellite dll. Alas, the same doesn't apply to Visual Studio 2005, which insists on finding a ".resources.dll" satellite assembly, which is a pity, because if your add-in targets VS 2005, 2008 and 2010 with the same .NET Framework 2.0 dll, you need to provide the satellite dll.
- And there is more! As I posted back in 2009, the EnvDTE80.Commands2.AddNamedCommand2 was changed internally in VS 2010 to accept a managed (.NET) System.Drawing.Bitmap or System.Drawing.Icon. I will try it and this will be the subject of another article if I am successful.
The approach that I described in the following article to use a single satellite Dll with the "en-US" culture using the AppDomain.AssemblyResolve event doesn't work in VS 11 Beta:
HOWTO: Create a command with a custom picture using a managed satellite DLL for a XML-based Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012002.aspx
I have just opened a bug report at Microsoft Connect:
VS11 Beta does not raise AppDomain.AssemblyResolve to receive the satellite dll in add-ins in localized versions
https://connect.microsoft.com/VisualStudio/feedback/details/731914/vs11-beta-does-not-raise-appdomain-assemblyresolve-to-receive-the-satellite-dll-in-add-ins-in-localized-versions#details
BTW, some other bugs that I have been reporting will be fixed in next builds of VS 11, according to the Microsoft answers. Hopefully this is fixed too.
When a CommandBarButton is created from a Command on a Visual Studio menu, it
has an icon and a text. However, when it is created on a toolbar, it can have
only an icon, or an icon and a text. Typically buttons on a toolbar have only an
icon (without a text). There are two ways to set that style (only the icon) to a
CommandBarButton on a toolbar:
- Setting the CommandBarButton.Style = MsoButtonStyle.msoButtonIcon. This
approach has the drawback that Visual Studio first creates the button with icon
and text, and then it changes it to icon only.
- Setting the default style of a command to
EnvDTE80.vsCommandStyle.vsCommandStylePict, so that CommandBarButtons created on
toolbars have only the icon, while those created on menus have icon with text
(the only possible style for them).
My latest article shows a sample of the second approach:
HOWTO: Set the default style a CommandBarButton on a toolbar from a Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012003.aspx
I have created a new article that shows a whole example of an add-in creating a command and a button with a custom picture using a satellite managed (.NET) dll:
HOWTO: Create a command with a custom picture using a managed satellite DLL for a XML-based Visual Studio add-in.
http://www.mztools.com/articles/2012/MZ2012002.aspx
While I had the article HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands, buttons and toolwindows, it was not supplying a whole example of a working add-in. The next version of my MZ-Tools add-in will switch from being a COM-based add-in with a native satellite dll to a XML-based add-in with a managed (.NET) satellite dll, and I have found quite a few issues until it worked fine. One of them was that I wanted a single satellite dll, not one dll for each culture ("en-US", "es-ES", etc.) and finally I found a nice trick to accomplish that, using the AppDomain.AssemblyResolve event.
If you have followed my blog last years, you know how much I hate satellite dlls so after 4 years I finally got Microsoft to get rid of them in Visual Studio 2010 (bad luck if you want to support Visual Studio 2005 and 2008. Update: it happens that the approach also works in VS 2008). My next article will show a whole example.
In the Visual Studio blog it has been published the expected Visual Studio 11 Beta Performance Part #2 about changes in the solution loading experience that can explain the issues that I posted some days ago:
VS 11 Beta issue: EnvDTE.Project.CodeModel returns null for a project just loaded without open documents
http://msmvps.com/blogs/carlosq/archive/2012/03/09/vs-11-beta-issue-envdte-project-codemodel-returns-null-for-a-project-just-loaded-without-open-documents.aspx
VS 11 Beta issue: EnvDTE.SolutionEvents.Opened event not fired for a solution just loaded without open documents
http://msmvps.com/blogs/carlosq/archive/2012/03/09/vs-11-beta-issue-envdte-solutionevents-opened-event-not-fired-for-a-solution-just-loaded-without-open-documents.aspx
As the article explains, solution loading is now done in two phases, one "modal loading" in the main UI thread, and other "background loading", which has important effects on extensions (add-ins, packages, etc.). Specifically the article explains why the previous issues only happen when there are no files open from the last session:
During the Modal Loading phase, we load projects most likely to
be needed by the user and block the UI thread to ensure this task has
the highest priority. Specifically, we create only the projects that had
files left open in the last VS session or projects. We rely on the new Preview Tab feature (discussed here)
to help ensure that only projects that you were actively working with
in your last session are loaded in this phase of solution load. (...) Finally, we notify components and extensions that the Modal Load phase
of solution loading is about to complete, so they can initialize their
data models.
and:
In the Background Loading phase, we unblock the UI thread and
start processing the background load tasks one at a time. Each time a
project is loaded in the background, we notify components and extensions
that the project has loaded. If the user requests information about a
project that has not finished loading, we immediately load that project
and its dependencies (on the UI thread for maximum performance). We made
this operation cancellable if you don’t want to wait. Once all project
loading tasks have been processed we notify all components and
extensions that the Background Loading phase of solution load has
completed.
So, it seems that VS 11 notifies extensions when each project has finished loading, when the Modal Loading phase is about to complete and when the Background Loading phase has completed. The question is how add-in extensions are notified since the EnvDTE.SolutionEvents only has a Opened event and there are no events for projects, I guess that for packages new services are introduced in the SDK and Microsoft is working with "popular extensions" to address the changes and issues, but for add-ins I am not sure if new events will be introduced in the EnvDTE automation model. Maybe we will have more information when Microsoft answers the two Microsoft Connect issues that I opened.
One new "feature" of Visual Studio 11 is that it will support language packs to provide multiple languages for the user interface (UI). You can download them for VS 11 Beta here:
Microsoft Visual Studio 11 Beta Language Pack
http://www.microsoft.com/download/en/details.aspx?id=28980
This is something I wanted to have since long time ago (I wish Visual Studio had Multilingual User Interface (MUI) implemented as on Windows Vista). And finally Microsoft has provided this. While multiple languages for the UI is not important for most developers (they will use only one), it is a very important feature for developers of add-ins and other extensions. Why? Because chances are that you will develop your extension in Visual Studio in English and it will fail when some user uses Visual Studio in Spanish, German, French, etc. In the following post I explained things to be aware of:
MZ-Tools Articles Series: HOWTO: Testing add-ins in localized versions of Visual Studio
http://msmvps.com/blogs/carlosq/archive/2010/04/01/mz-tools-articles-series-howto-testing-add-ins-in-localized-versions-of-visual-studio.aspx
(In a next post I will talk about another area to take into account: the language of the satellite dlls used by add-ins to provide custom pictures for commands and buttons, which depend on the language of Visual Studio, but I found a workaround to use only one satellite dll.)
Until now, you had to install the full Visual Studio in some language on top of the Visual Studio in some other language (and the service packs) to get the two languages in the "Tools", "Options" window, "Environment", "International Settings" section. Now, you can just install a language pack on top of the Visual Studio in some language, which supposedly will take less time.
But Visual Studio is half of the environment. The other half is the Windows operating system, which also varies from one language to another, and some folders are localized (for example, "Application Data" in Windows XP), which can cause bugs if you are not careful as the bug of Visual Studio described in the post mentioned above. To catch these problems since I have two computers in one of them I have Windows and Visual Studio in Spanish (my native language) and in other in English. Of course you can use virtual machines for foreign languages if English is your native language.
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
A reader of my article:
HOWTO: Detect when a Visual Studio toolwindow is shown or hidden.
http://www.mztools.com/articles/2011/MZ2011010.aspx
pointed me to an inconsistent behavior of the EnvDTE80.Events2.WindowVisibilityEvents in one case, so I have investigated all the cases and I have documented all the inconsistent behaviors (which are a lot in several VS versions) in a new article:
BUG: Inconsistent behavior of EnvDTE80.Events2.WindowVisibilityEvents from a Visual Studio add-in
http://www.mztools.com/articles/2012/MZ2012001.aspx
Since VS 11 Beta exhibits the same two bugs than VS 2010, I have opened two bug reports to Microsoft:
EnvDTE80.Events2.WindowVisibilityEvents.WindowHiding event not fired when collapsing toolwindow
https://connect.microsoft.com/VisualStudio/feedback/details/729827/envdte80-events2-windowvisibilityevents-windowhiding-event-not-fired-when-collapsing-toolwindow#details
EnvDTE80.Events2.WindowVisibilityEvents.WindowShowing event fired twice
https://connect.microsoft.com/VisualStudio/feedback/details/729845/envdte80-events2-windowvisibilityevents-windowshowing-event-fired-twice#details
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.zip\ClassLibrary.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.zip\ClassLibrary.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.
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:
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.
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.
Happy New Year!
I have just received the Most Valuable Professional (MVP) award again!. It's always great to start a new year with this award, something that has happened to me the 9 last years :-)
As always, I am very grateful to Microsoft for this recognition :-)
More Posts
Next page »