Category Archives: VS Packages

Three bugs in MSDN Walkthrough: Extending the Solution Explorer Filter

One of the things that I do from time to time is to take a question in the MSDN Visual Studio Integrate or StackOverflow forums about a subject of VSX that I am not very familiar with, and try to investigate and provide an answer. The other day I picked this one about extending the Solution Explorer filter with a custom filter, something that I didn’t know.

The question was that following the MSDN Walkthrough: Extending the Solution Explorer Filter the sample didn’t work for VS 2013 Update 4. I reproduced the issue and after some investigation I concluded that it was a bug in VS 2013, because the version of the Walkthrough for VS 2012 actually worked. I reported it to Microsoft Connect (the report seems to have been deleted now) and actually what was wrong was the MSDN sample, which should use the SVsServiceProvider parameter type (instead of IServiceProvider type) in this constructor:

public FileNameFilterProvider(SVsServiceProvider serviceProvider, ...)

There is now a MSDN feature suggestion to fix the code sample. But the sample has other two bugs:

  • The Utilities.cs class is no longer required, you can use the provided HierarchyUtilities class.
  • The command should not be bound with an event handler in the Initialize() method of the package. Its command guid/id are used as parameters in the SolutionTreeFilterProvider attribute to bind the command with the filter.

MZ-Tools Articles Series: HOWTO: Create a toolwindow WITHOUT a ToolWindowPane class in a Visual Studio package

The usual way to create toolwindows in a package is described in my last post HOWTO: Create a toolwindow with a ToolWindowPane class in a Visual Studio package. While with add-ins only a usercontrol was required, with packages you need the usercontrol and a class that inherits from ToolWindowPane. That is, two files. When I first learned this, I found it somewhat overkill. But when I started to migrate my MZ-Tools add-in to a package, which has quite a few toolwindows, I found it totally overkill. Furthermore, requiring to decorate the package with a ProvideToolWindow attribute for each toolwindow defeats the 3rd strategy that I exposed in Strategies migrating from Visual Studio add-ins to packages, in which a core plug-in provides the features (and therefore the usercontrols for toolwindows) and a host adapter provides the communication between the host (Visual Studio) and the core plug-in. The host adapter is not aware of the features implemented by the core plug-in, and therefore it shouldn’t use specific toolwindows classes or attributes. I am aware that the ProvideToolWindow attribute and the class that inherits ToolWindowPane serve a purpose which was not available for toolwindows created by add-ins: to show automatically when VS is launched the toolwindows that were open in the last VS sessions. So, the initialization of the toolwindow must be contained in a class and not in the “click event” of the command that shows the toolwindow. But it happens that add-ins can provide that functionality too with minimal effort: when unloaded the add-in stores which toolwindows were open and when it is loaded again it shows them. Version 7.0 of MZ-Tools, being an add-in, offered this feature since it was released in 2012.

So, I wanted to create toolwindows in my MZ-Tools package like I was doing in my MZ-Tools add-in. While you can use the automation model (EnvDTE) from a package, alas, the EnvDTE80.Windows2. CreateToolWindow2 method is among the few ones that cannot be used from a package because it requires an EnvDTE.AddIn parameter, that a package cannot provide. Fortunately, the the IVsUIShell interface provides a CreateToolWindow method that can be used from packages. In this new article (equivalent to HOWTO: Create a dockable toolwindow from a Visual Studio .NET add-in) I show how to use it:

HOWTO: Create a toolwindow without a ToolWindowPane class in a Visual Studio package
http://www.mztools.com/articles/2015/MZ2015005.aspx

MZ-Tools Articles Series: HOWTO: Create a toolwindow with a ToolWindowPane class in a Visual Studio package

Creating a package with a toolwindow using the package wizard is easy because the wizard provides you an option to do it:

PackageWizard

However, the steps to create a second toolwindow are not evident. And even if you figure out the steps, knowing what they do may be difficult. And if you come from the add-ins space (where toolwindow creation uses an easier approach), toolwindows of packages is difficult stuff. This question has appeared twice in the StackOverflow forum in the last days.

I have written the following article to explain the stuff generated by the wizard when you request the toolwindow option, how the pieces are connected, and why each piece is required:

HOWTO: Create a toolwindow with a ToolWindowPane class in a Visual Studio package
http://www.mztools.com/articles/2015/MZ2015004.aspx

In my next post/article I will explain a different approach to create toolwindows in a package, without a ToolWindowPane (hence the title of this article).

MZ-Tools Articles Series: BUG: Toolwindow guid attribute value hardcoded in code generated by Visual Studio package wizard

I am these days working on a couple of articles about toolwindows. As you know, the package wizard has an option to create a toolwindow for you that creates a lot of stuff with guids, ids, attributes and so on. One thing that you notice when you learn about packages with commands is that there are duplicated declared Guids for the package guid and command set guid in the .vsct file (<symbols> section, guidVSPackagePkg / guidVSPackageCmdSet guid symbols) and in the Guids.cs file (guidVSPackagePkgString / guidVSPackageCmdSetString constants). That duplication is unfortunate but required, because those two files are compiled by different tools (the .vsct file is compiled by the Vsct.exe tool of the VS SDK and the Guids.cs file is compiled by the C# compiler). However, when you create a package with a toolwindow, you get a third guid value duplicated, but that duplication is not required.

I have documented it in this article:

BUG: Toolwindow guid attribute value hardcoded in code generated by Visual Studio package wizard
http://www.mztools.com/articles/2015/MZ2015003.aspx

and I have opened a bug report at Microsoft Connect:

VS SDK package with toolwindow: constant guid not used in code, hard-coded guid instead
https://connect.microsoft.com/VisualStudio/feedback/details/1138161/vs-sdk-package-with-toolwindow-constant-guid-not-used-in-code-hard-coded-guid-instead

To prevent the problem in the future packages that you create with toolwindows, you can fix the templates by yourself as explained in my article HOWTO: Changing the source code of Visual Studio Package project templates.

And since I have verified that this problem exists in the templates of the package wizard since VS 2005, chances are that if your package uses toolwindows it has the duplicated guid value if you haven’t noticed it.

MZ-Tools Articles Series: HOWTO: Force files to open with a specific editor from a Visual Studio package

This other article also comes from one of my answers in the MSDN VSX forum:

HOWTO: Force files to open with a specific editor from a Visual Studio package

It explains how to overcome a limitation of the automation model (EnvDTE) forcing a ProjectItem to open in a specific editor even when the user has set the default to other editor (especially problematic if the editor is external, such as Notepad). It is also useful if you want to start getting rid of “EnvDTE” code in your package.

MZ-Tools Articles Series: BUG: TextChanges CommandFlag not honored for toolbars in Visual Studio packages

In my MZ-Tools package I use dynamic localization to avoid the official way to localize .vsct files. So, I use the TextChanges CommandFlag for UI items and I set the text at run-time using the BeforeQueryStatus event handler. While this works fine for most UI items, alas, it doesn’t work for toolbars. I have documented it here:

BUG: TextChanges CommandFlag not honored for toolbars in Visual Studio packages
http://www.mztools.com/articles/2014/MZ2014026.aspx

and this is the Microsoft Connect bug report:

“TextChanges” CommandFlag not honored for toolbars in Visual Studio packages (VS SDK)
https://connect.microsoft.com/VisualStudio/feedbackdetail/view/966908

Issues with command names in Visual Studio packages

When creating a Visual Studio add-in, you had full control of the full name of its commands (command prefix + command short name, such as “MyAddIn.MyCommand”), as I explained in the article HOWTO: Create command names without ‘.Connect’ in Visual Studio add-ins. So, when I created my MZ-Tools add-in for Visual Studio, each version used a command prefix such as “MZTools6” or “MZTools7”, and I could provide that information to the end user to customize the keyboard shortcuts, for example:

keyboardshortcuts

Another nice consequence was that, given a Visual Studio version, two versions of the add-in (for example one purchased, next one evaluating) could be loaded at the same time without collisions of add-in command full names, because each one used a different command prefix.

With packages, you lack the control over the command prefix, as I explained in INFO: How a Visual Studio package command is named. So, the commands of a package cannot be named “MyPackage.MyCommand”. And it is perfectly possible that two packages (or two versions of the same package loaded side by side) create two commands with the same full name as in this example:

TwoCommands

This is possible because Visual Studio commands (as everything else in Visual Studio) are identified by Guids and Ids and not by names (the EnvDTE.Command interface exposes those two properties).

Therefore, given that a collision of command full names is not really a collision internally in Visual Studio (only in the user interface level), so far so good. But if your add-in assumes that its commands have unique full names (because the command prefix is unique for add-ins) and uses code like this:

EnvDTE.Command command = dte.Commands.Item("MyAddIn.MyCommand");

that will cause problems when migrating to a package:

EnvDTE.Command command = dte.Commands.Item("Tools.MyCommand");

You see, the command full name now uses “Tools” (for example) instead of “MyAddIn”. If you have two versions of your package loaded side by side, that call can return the command of the wrong package version. A similar problem to getting the correct CommandBar as explained in HOWTO: Get a CommandBar by Guid and Id rather than by name from a Visual Studio add-in.

The same can happen if you execute a command by name:

dte.ExecuteCommand("Tools.MyCommand");

The solution is to stop using command full names in the code to identify commands, and to use the command Guid / Id instead:

In my MZ-Tools extension I use a lot of command stuff, so I have to review/change several areas of the product as part of the migration to a package. Also, the user can create commands for each code template of the Code Library feature (notice the optional Command Name field):

codelibrary

In the code of the add-in, that is done using the EnvDTE80.Commands2.AddNamedCommand2 method. Although you can use automation (EnvDTE) from a package, you can’t use that method because its first parameter is of the type EnvDTE.AddIn. I guess that a package must use the AddNamedCommand methods of the IVsProfferCommands interface. I will post and provide a sample once I try it.

MZ-Tools Articles Series: HOWTO: Get solution events from a Visual Studio package

Continuing with the series of articles to show how to do things in a native way in a Visual Studio package instead of using the automation model (EnvDTE), in this new article I show how to get the solution events using the IVsSolutionEvents interface. As I expected, it is more difficult than using the automation model, with more code, and even requires you to use a cookie!:

HOWTO: Get solution events from a Visual Studio package
http://www.mztools.com/articles/2014/MZ2014024.aspx

MZ-Tools Articles Series: PRB: Menu commands not refreshed after a change when clicking Start Debugging in a VS 2010 package project

An issue that I noticed some weeks ago when playing with packages in several Visual Studio versions was that in VS 2010 command menus were not updated after a change in the .vsct file just clicking F5 to start debugging, I had to rebuild. However, in VS 2012/2013 it just worked without an explicit rebuild action.

In this new article I provide a repro scenario and a fix that involves updating a MSBuild target of the VS 2010 SDK to behave like the ones of VS 2012/2013 SDKs:

PRB: Menu commands not refreshed after a change when clicking Start Debugging in a VS 2010 package project
http://www.mztools.com/articles/2014/MZ2014023.aspx