Moving from add-ins to packages, MZ-Tools Articles Series, VS Extensibility, VS Packages

MZ-Tools Articles Series: HOWTO: Guessing the IDE mode (design, debug or run-time) from a Visual Studio package

June 20, 2015 Carlos Quintero

As I am moving from add-ins to packages, I always like to learn how to do things using native services of Visual Studio instead of using the automation model (EnvDTE). There is an area of Visual Studio extensibility, the debugger, that is very powerful but normally extensions don’t have to use, except maybe to know which mode (design-time, debug-time, run-time) the IDE is, and when the mode changes, because maybe some commands or features should be enabled/disabled based on the IDE mode.

Eight years ago I wrote how to do that using the automation model in this article:

HOWTO: Guessing the IDE mode (design, debug or run-time) from a Visual Studio add-in or macro

Today I have written a small equivalent article doing the same using the IVsDebugger native service:

HOWTO: Guessing the IDE mode (design, debug or run-time) from a Visual Studio package

VS Extensibility, VS Packages

The hidden and broken Generate Load Keys page (for VS 2005/2008 shell and packages)

June 18, 2015 Carlos Quintero

I have found two questions in the last weeks about the somewhat hidden and broken web page to generate Package Load Keys (PLK) or Shell Load Keys (SLK). The first thing to know is that likely you don’t need them: for Visual Studio 2010 or higher, the load keys are not required. If you need them for Visual Studio 2005 / 2008, here are the things to know:

The public page is: https://msdn.microsoft.com/en-us/vstudio/cc655795.aspx

At the time of this writing , if you use Firefox you are missing the form to generate the keys, and you are missing even the warning that you are missing it:

If you use Internet Explorer, you get the warning:

If in Internet Explorer you click the “Open this content in a new window” link, then you get finally the correct page (https://vsipprogram.com/External/key?iframe=true):

There is other path to reach that page: you can become a Microsoft Visual Studio Industry Partner (VSIP) “Basic” level member (which is free) and:

At the bottom of the main page, click the “Support” link.
Click the “How do I get a PLK/SLK for Visual Studio?” FAQ entry link
You get a message:

“Since Visual Studio 2012 you no longer need a PLK or SLK to integrate with Visual Studio.

Bottom line: if you are creating VS 2005/2008 shell or packages, you can go directly to https://vsipprogram.com/External/key

MZ-Tools Articles Series, VS Extensibility, VS Packages

MZ-Tools Articles Series: HOWTO: Get supported frameworks and profiles of a Visual Studio version from a package

June 15, 2015 Carlos Quintero

Since Visual Studio 2008, a project can be built against different .NET Framework targets, versions and profiles. When you create a Visual Studio project, you get the first chance of selecting the target .NET Framework in the New Project dialog:

If you change your mind later, you can go to the project properties dialog and change the target .NET Framework:

This capability is known as framework multi-targetting and in recent versions of Visual Studio has exploded to allow tons of different combinations of .NET Framework versions and profiles (.Net Framework, Silverlight, Windows Phone, XBox, .NET Microframework, .NET Portable, etc. You can read more in this post of MVP fellow Stephen Cleary: Framework Profiles in .NET.

Now, we will get to the code:

A combination of .NET Framework name, version and profile is known as .Net Framework “moniker”, and it has a display name (friendly name).

You can get the .Net Framework moniker that a project is targeting using automation (EnvDTE.Project.Properties.Item(“TargetFrameworkMoniker”).Value) or using the native services of Visual Studio (IVsHierarchy.GetProperty method with the __VSHPROPID4.VSHPROPID_TargetFrameworkMoniker property)

But more difficult is to know which are the available .NET Framework monikers, the display name of a moniker, the available assemblies for that moniker, etc. The interface to use is IVsFrameworkMultiTargeting and this new article of mine shows some sample code:

HOWTO: Get supported frameworks and profiles of a Visual Studio version from a package

The interface has more methods, so check the documentation.

Add-Ins, MZ-Tools Articles Series, VS Extensibility

MZ-Tools Articles Series: BUG: Visual Studio 2008 crashes if unloaded when an add-in executes DoEvents statement on startup

June 14, 2015 Carlos Quintero

Although this article applies only to the old Visual Studio 2008, I am writing it for completeness of the body of knowledge that I have built over the years about add-ins. And if you are a VSX developer who cares about your users/customers, chances are that your extension still supports Visual Studio 2005 / 2008 (which are widely used yet at companies because for some reason developers don’t always migrate to the latest version. See How many old Visual Studio versions does my add-in/package have to support?). Recently I encountered an issue in one of my scripts that remove add-in commands, and it took me a while to find that the root cause was a bug in Visual Studio 2008:

BUG: Visual Studio 2008 crashes if unloaded when an add-in executes DoEvents statement on startup

If you were in the VSX world in the VS 2008 era of add-ins, you may remember that there was another bug that caused VS 2008 to crash on startup:

BUG: Add-in causes Visual Studio 2008 crash when loaded

Fortunately both bugs were fixed in next releases.

VS Extensibility

New Project System Extensibility sections

June 3, 2015 Carlos Quintero

One of the areas of Visual Studio Extensibility (VSX) that I am not very familiar with is project system extensibility, that is, creating new project types, extending project types with flavors (project subtypes) or creating custom tools (single file generators). I knew that that extensibility area was hard, though, as every piece of Visual Studio extensibility that was created around Visual Studio 2005 / 2008.

Yesterday, the time has come for a huge improvement in that area, when Microsoft made public a new Common Project System (CPS) Extensibility SDK in preview for Visual Studio 2015 that aims to simplify project type creation getting rid of MPFproj (“often containing well over 100K lines of code”).

I have noticed that this extensibility area was not well covered in this VSX site, that aims to provide pointers to every VSX bit of information out there, so I have created these new sections:

VS 2015, VS Extensibility, VS Packages

BUG: Extension Manager of VS 2015 RC doesn’t show large image for installed extensions

June 2, 2015 Carlos Quintero

While a couple of days ago I was testing the last .vsix installer of my MZ-Tools extension, now converted to a package, with Visual Studio 2015 Release Candidate, I discovered that its large image was not shown in the Extension Manager. At first I thought that it was my fault, because the VS SDK doesn’t warn you that a resource included in the extension.vsixmanifest (such as the license agreement) isn’t actually included in the package project. After fixing another bugs that were my fault, today I investigated this one, and it happens with all installed extensions, not only with mine. So, while browsing the Visual Studio Gallery (“Online” node of the tree), the large image is shown as expected. Here you have the Developer Assistant, for example:

But once you install it (“Installed” node of the tree), its large image is not shown, the ugly default one is used:

I have opened a bug on Microsoft Connect:

Extension Manager doesn’t show large image for installed extensions
https://connect.microsoft.com/VisualStudio/feedback/details/1391193/extension-manager-doesnt-show-large-image-for-installed-extensions

Hopefully it will be fixed for VS 2015 RTM. You can vote for it to make it so.

Visual Studio Extensibility (VSX)

Monthly Archives: June 2015