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.
The first MZ-Tools Articles Series that I have written this new year is this:
HOWTO: Create two Visual Studio packages in a single assembly
I did it as a pure exercise after a question in the MSDN VSX forum and I don’t think it has any practical use even for the problem of a package targeting multiple versions of Visual Studio with the maximum reuse of code at source and binary levels.
Currently the most notorious problem that I have found (and that I reported at Uservoice) is that you can’t provide a single .vsix package for VS 2010/2012/2013 with a single binary assembly and two .vsct tables with the following conditions:
So, you can create a single package in a single assembly with two .vsct tables, or two packages in a single assembly with a different .vsct file each one (like in the example provided in the article), but neither you can specify in the .vsct table or package attributes the target VS version, nor you can specify in the manifest of the .vsix file the target VS version of each .pkgdef file.
My new article is to document a bug that a customer of my MZ-Tools add-in reported some days ago, and that is caused by a bug (or problem) in the automation model (EnvDTE). It happens in the following scenario:
You have the details and code to reproduce the problem here:
PRB: Window.Close doesn’t save changes if requested for .sql files in non-database projects
http://www.mztools.com/articles/2014/MZ2014027.aspx
I am not sure if this is a bug or not, because the project doesn’t support .sql files. There is an easy workaround, though. You can call:
window.Document.Save(“”);
window.Close(EnvDTE.vsSaveChanges.vsSaveChangesNo);
instead of:
window.Close(EnvDTE.vsSaveChanges.vsSaveChangesYes);
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
A question in the VSX forum has intrigued me enough to test a creative solution: to intercept a command execution to re-execute it with an input parameter that you can retrieve when the execution finishes. This can be useful in a scenario where a command can be executed asynchronously twice and you want to know which/when each execution is finished:
HOWTO: Pass parameters programmatically to a command from a Visual Studio add-in
http://www.mztools.com/articles/2014/MZ2014025.aspx
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
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
I have written this article to show how to provide the bitmaps for commands from embedded resources of the assembly, rather than from files on disk (the default):
HOWTO: Provide command bitmaps from embedded resources of a Visual Studio package.
http://www.mztools.com/articles/2014/MZ2014022.aspx
While migrating my MZ-Tools add-in to a package, I found an issue: I wanted a button to be initially invisible on my toolbar. By “initially” I mean before the package is loaded, that is, declaring the invisibility in the .vsct file using:
<CommandFlag>DynamicVisibility</CommandFlag> <CommandFlag>DefaultInvisible</CommandFlag>
However, the button appeared initially disabled rather than invisible. Investigating I found this reported in the MSDN VSX forum as back as in 2006 (VS 2005 I guess) using the old .ctc file rather than the new .vsct file and, guess what, that behavior is “by design”. However, buttons on toolwindows toolbars (rather that on IDE toolbars) can be initially invisible.
I created a sample package to reproduce the problem. The package creates two commands (the first one initially invisible) that are placed in three locations: the Tools menu, the Standard toolbar and the Solution Explorer toolbar. Notice that the button on the Standard toolbar is disabled rather than invisible:
And I have documented this behavior with code in this article:
PRB: Button of package command cannot be initially invisible on Visual Studio toolbar
Another very confusing thing when starting with packages and you have a background of creating add-ins is how to name a command.
With add-ins, the (full) name of a command was composed by two parts:
And one interesting consequence was that all the commands of your add-in used the same prefix. With packages this is not true. The prefix of a command created by a package follows some complicated rules that depend on the menu / toolbar / context menu where the command is mainly placed (because, you know, a command is not a UI item and you can create several UI items in different locations tied to the same command).
And even the (short) name of the command can vary depending on the values of <CommandName>, <LocCanonicalName> and, go figure, can even be inferred from the caption of the command (<ButtonText>) removing special characters, etc.
I have written this article to try to explain all rules: