Category Archives: VS Extensibility

VS Extensibility, VS Packages

The four versions of a Visual Studio package

One of the confusing aspects when you create a new Visual Studio package is that there seems to be many places where a version number appears. They are the following:

  1. The version on the Tools > Extensions and Updates dialog:

VersionExtensionsAndUpdates

2. The version on the Help > About dialog:

VersionHelpAbout

3. The version on the deployment folder:

VersionFolder

4. The version of the file:

VersionFile

5. The version of the assembly:

VersionAssembly

All those five versions are set in four places, that are the following:

1. The version on the Tools > Extensions and Updates dialog and the version on the deployment folder are the same version and it is set in the source.extension.vsixmanifest file, Version field. It is recommended (in my opinion) to set it to the file version (4 numbers):

VersionManifest

2. The version on the Help > About dialog is set in the package class, InstalledProductRegistration attribute. It is recommended to set the same value than in the previous point, so that the Help > About and the Tools > Extensions and Updates dialogs show the same value:

VersionPackageClass

3. The version of the file is set in the AssemblyInfo.cs file, AssemblyFileVersion attribute. This file version is a Win32 concept (not a .NET concept) and it is best practice to change it on each build:

FileVersionAssemblyInfo

4. The version of the assembly is set in the AssemblyInfo.cs file, AssemblyVersion attribute. This assembly version is a .NET concept and it is not required to change it on each build:

AssemblyVersionAssemblyInfo

Note: to learn the difference between Assembly File Version and Assembly version read the Knowledge Base Community article How to use Assembly Version and Assembly File Version.

VS Extensibility

Build 2016 sessions of interest for Visual Studio Extensibility developers

In the past Microsoft Build 2016 conference a few weeks ago there were a couple of sessions that were of interest to VSX developers:

In the first one, “Visual Studio 2015 Extensibility”, Mads Kristensen “writes an extension from scratch live on stage, then integrates with GitHub, automates the build process and deploys the finished extension to the Visual Studio Marketplace”. I enjoyed it a lot and learned some things that I didn’t know. I encourage you to see it:

The second one is “The Future of Visual Studio”, by Amanda Silver. While this session doesn’t talk about VSX, it contains some good news: the new version of Visual Studio “15” will take much less time to install, like 180 seconds a minimal installation thanks to a new “streamlined acquisition experience”, with no MSI or GAC involved (this is mind-boggling, isn’t it?). Of course, adding components for development with different technologies will take considerably more time, so we will have to wait for the final result of the new setup experience:

She had also an interview with Seth Juarez about that session:

I currently have on my development machine six versions of Visual Studio (2005, 2008, 2010, 2012, 2013 and 2015), along with their service packs and Windows updates, which are required to ensure that my MZ-Tools extension (as add-in or as package) works correctly on each VS version. Also, I have different virtual machines with only one version of VS installed on each one, which is required to ensure that I am not using a reference that is missing in some VS version (which wouldn’t be noticed on the main development machine because all VS versions are installed). Each time that I have to create a new development environment of VS versions I know it will take me the whole day… watching TV shows or doing something else. On the one hand I think that Visual Studio has become a huge monster, still COM-based, with lots of internal technologies and dependencies. On the other hand, there is something in the MSI technology that makes it slow. For example, a setup created by InnoSetup for a Visual Studio add-in is faster than a setup created by MSI. Anyway, hopefully in the future the installation of Visual Studio will be less painful, now that Microsoft is aware of the pain.

VS Extensibility

How to send feedback to Microsoft about Visual Studio Extensibility

Either if you are a new or a veteran developer of extensions for Visual Studio, chances are that at some point you will have to send feedback to Microsoft to report bugs, suggest enhancements or ask for new features. In the last years, the number of channels to do it has increased significantly. Here it is a recap:

The “formal” channels (with tracking) are the following:

    • Microsoft Connect: this has been the traditional channel to send feedback to Microsoft about some of its products, specially for Visual Studio and .NET. I have reported tons of bugs about VSX through this channel in the last years.
    • GitHub: with some portions of Visual Studio and .NET going open source, such as the .NET Compiler Platform (Roslyn), this is the preferred channel by those Microsoft teams to get reported issues.
    • UserVoice (“Extensibility” category): to suggest new ideas, features or enhancements, this is one of the best channels. The most voted items have more chances of being implemented.
    • Visual Studio feedback: recent versions of Visual Studio provide a feedback button at the top-right corner of the IDE.

VSFeedback

You can either provide a suggestion (it redirects to UserVoice) or report a problem, which shows a dialog and you can select the “Integrated Development Environment” problem area:

ReportProblem

The “informal” channels are forums that are visited frequently by members of the VSX team:

    • Gitter (Microsoft/extendvs): this is the community for developers of Visual Studio extensions. It can be used to get help, but since it is visited by the VSX teams you can provide feedback, bugs, etc. There is a monthly office hour every 3rd Thursday, 10am – 12pm PST, where members of the VSX teams can address your questions, suggestions, requests, etc.
    • MSDN Visual Studio Integrate Forum: this forum is more suited to get problems solved, but it is also visited by members of the VSX team.

With more and more code samples on GitHub, better docs, and extensions and templates to help you to develop extensions, this whole range of options to get help, report bugs, send feedback, suggest improvements, etc. without cost is the another fundamental piece to improve your experience when developing extensions.

VS 2015, VS Extensibility, VS Packages

Resources to create high-DPI images with the new Visual Studio 2015 Image Service

In my post Visual Studio extensions and DPI-awareness I introduced the basics that you need to know to become DPI-aware. The final step once all the user interface of your extension handles high-DPI gracefully is to provide high-DPI images for the toolbars, as Visual Studio 2015 does since CTP 3. Apparently, support for high-DPI images through a new image service was in the Visual Studio 2015 RTM release, but it hasn’t been until a couple of days ago that Microsoft has published the MSDN documentation. Here you have the resources to learn and use it:

UPDATE (Jan 26, 2016): The Visual Studio Image Library, which contains .zip files with VS images, has been updated with VS 2015 images.

Add-Ins, Moving from add-ins to packages, VBA add-ins, VS Add-Ins, VS Extensibility, VS Packages

Announcing unified MZ-Tools 8.0 for Visual Studio, VBA (64-bit/32-bit), VB6 and VB5

1 Comment

It has been a long time since my last post here, and for a good reason. Since I released MZ-Tools 8.0 for Visual Studio 2015 last July 1 (converted from add-in to package), I have been very busy the last months to achieve a new huge milestone:

Announcing unified MZ-Tools 8.0 for Visual Studio, VBA (64-bit/32-bit), VB6 and VB5

From the extensibility point of view, MZ-Tools 8.0 is a unique piece in the world, AFAIK: it provides the same feature set for four different IDEs (Visual Studio, VBA editor, Visual Basic 6.0 and Visual Basic 5.0) with different extensibility APIs reusing the same code at binary level:

MZ-Tools 8.0 for Visual Studio (as package):
MZTools8VSPackage

MZ-Tools 8.0 for Visual Studio (as add-in):
MZTools8VSAddIn

MZ-Tools 8.0 for VBA:
MZTools8VBA

MZ-Tools 8.0 for VB6:
MZTools8VB6

MZ-Tools 8.0 for VB5:
MZTools8VB5

As you can see in the images, in all cases there is the same big MZTools8PlugIn.dll file, which contains the feature set, and smaller host adapter dlls that “plug” the features into the IDEs. If you are interested, I outlined the strategy to achieve this in this other post.

The strange case of..., VS 2015, VS Extensibility, VS Packages

The strange case of CreatePkgDef failing because of strong name validation

After several days fixing bugs of my new MZ-Tools 8.0 version, today I have tried to run the build process that I have to generate the “Production” version and it has failed with this chain of errors:

Error 1 CreatePkgDef : error : ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. MZTools8VSPackage

Error 2 at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) MZTools8VSPackage

Error 3 at System.Reflection.RuntimeModule.GetTypes() MZTools8VSPackage

Error 4 at System.Reflection.Assembly.GetTypes() MZTools8VSPackage

Error 5 at Microsoft.VisualStudio.Tools.CreatePkgDef.ProcessAssembly(String fileName, Hive hive, PkgDefContext context, Boolean register, RegistrationMode mode) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 260 MZTools8VSPackage

Error 6 at Microsoft.VisualStudio.Tools.CreatePkgDef.DoCreatePkgDef(InputArguments inputArguments) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 164 MZTools8VSPackage

Error 7 at Microsoft.VisualStudio.Tools.CreatePkgDef.Main(String[] arguments) in f:\dd\VSSDK\VSIntegration\Tools\src\CreatePkgDef\CreatePkgDef.cs:line 85 MZTools8VSPackage

Error 8 Could not load file or assembly 'MZTools8PlugIn, Version=8.0.0.0, Culture=neutral, PublicKeyToken=a756ad4bac8a0579' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A) MZTools8VSPackage

The first thing I noticed is that the errors show a location “f:\dd\VSSDK\VSIntegration\Tools\src” that is not on my hard disk. This is because the VS SDK tools (at C:\Program Files (x86)\Microsoft Visual Studio 12.0\VSSDK\VisualStudioIntegration\Tools\Bin) are shipped with the .pdb files for debugging.

The second thing that I noticed is that the CreatePkgDef.exe utility was failing because of a strong name validation that happened in the System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) method of the .NET Framework. However, this had been working until a few days ago. My MZ-Tools package (MZTools8VSPackage.dll) uses .NET Framework 4.5 and it is not obfuscated, but it uses a core MZTools8PlugIn.dll that uses .NET Framework 2.0 and it is obfuscated. So, the things are arranged as follows:

  • In “Debug” configuration, the MZTools8PlugIn.dll assembly is generated with a strong name because no obfuscation is performed.
  • In “Release” configuration, the MZTools8PlugIn.dll assembly is delay-signed, because it requires obfuscation, and you can’t alter an assembly signed with a strong name. So, obfuscation is done in a post-build step and then the obfuscated assembly is finally signed. The details are documented here.

So, in “Release” configuration, CreatePkgDef.exe is failing because the package assembly is loading a required assembly that doesn’t have a strong name yet (delay-sign). I was well aware that normally you need to instruct the .NET Framework to skip strong name validation using sn.exe -Vr (which for sn.exe 32-bit adds a special registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification) but somehow the CreatePkgDef step of the package assembly compilation of my build process has been working for ages until a few days ago without that strong name validation skipping step.

What has changed in the last days? My only suspect was Visual Studio 2015 and .NET Framework 4.6, that I installed on my main dev machine once they got RTM status. Since .NET Framework 4.5, 4.5.1, 4.5.2 and 4.6 are “highly compatible” with .NET Framework 4.0, they are not installed “side by side” but “on top” of the previous version. But it could be that one version introduces a breaking change to existing apps. To verify this hypothesis, first on my main dev machine where the issue was happening I created a package with Visual Studio 2008 (which uses .NET Framework 3.5 and CLR 2.0) and it compiled even setting the following delay sign in the AssemblyInfo.cs file:

[assembly: AssemblyDelaySign(true)]

The same was not true if I used Visual Studio 2010 or higher (which use .NET Framework 4.0 / CLR 4.0 or higher), but it was true in the past. So the suspicion increases.

Then, I setup a new virtual machine with only Visual Studio 2013 (.NET Framework 4.5.2) and lo and behold, a package compiles even if you use delay sign:

VSPackageBuildWithNet45

As soon as I downloaded and installed  only .NET Framework 4.6 (no need to install Visual  Studio 2015), the same package compilation gets this error:

CreatePkgDef : error : FileLoadException: Could not load file or assembly 'VSPackage1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=69b8a83eb37e3459' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

VSPackageBuildWithNet46

So, .NET Framework 4.6 introduces a breaking change that I have not seen documented.

Now, there is at least a couple of solutions:

  • You can build the package assembly with a strong name even in “Release” configuration, so CreakePkgDef doesn’t fail, and remove the strong name before obfuscating. Since the sn.exe utility doesn’t allow to remove strong names, you must search some other utility on the web (they exist).
  • You can instruct the .NET Framework to skip strong name validation using sn.exe -Vr before the package assembly is built, not after the package is built and before the assembly is obfuscated. The utility sn.exe is so handy that it allows you to skip strong name validation for assemblies that don’t exist yet, specifying just the public key token that will be used to sign them:
sn.exe -Vr *,public_key_token
Moving from add-ins to packages, VS 2015, VS Extensibility, VS Packages

Visual Studio 2015 RTM just released

Finally Visual Studio 2015 RTM has been released today and I am installing now on my main dev machine, rather than on separate virtual machines as I have been doing until now. There is and there will be a lot of information about what’s new in this release, but as a developer of extensions for Visual Studio, this release introduces these changes that you must know:

  • Add-ins are gone and now packages are the primary way of extending Visual Studio for the typical need of creating some toolbar, menu, buttons, toolwindows, etc. or listening to events to do something. Migrating from an add-in to a package is not trivial due to the usage of services instead of the EnvDTE automation model (although you can still use the automation model) but also for the difficulties of the .vsct file. ElektroStudios StackOverflow user (and others): I do feel your pain. I will do my best to find time and provide decent tutorials and a GitHub sample about .vsct in the next couple of months.
  • The editions offering has been simplified a bit and now you have:
    • Community Edition, which supports extensibility and is free for some scenarios, at least “still free”, huh?
    • Professional Edition
    • Enterprise Edition
      All of them are already available. There is no Ultimate edition, but for some reason there are still Express editions for Windows Desktop, Web (both already available) and Windows 10 (coming soon).
  • The compilers for C# and VB.NET are now exposed to extensions through the .NET Compiler Platform (formerly “Roslyn”). This should replace the automation code models (EnvDTE.Project.CodeModel, EnvDTE.ProjectItem.FileCodeModel), although they can be still used and in fact their implementation has changed to use Roslyn under the hood, with quite a few bugs along the way that I have reported and most of them are fixed now.
  • There is new support for high resolution icons on buttons for high-dpi displays, although AFAIK it is not documented yet.
  • There is a new Common Project System (CPS) in the works.
  • The Visual Studio 2015 SDK is available as a separate download as until now, but it is also already included in the Visual Studio setup under the name Common Tools > Visual Studio Extensibility Tools:
    VS2015SDK
  • The way to create a package, to add commands and toolwindows has changed, as hinted in the setup:
    VS2015SDK_2
  • To create a package there is no longer a wizard as in Visual Studio 2013, but just a barebone VSIX project template, and later you add as many custom commands or custom toolwindows as you want using the Add > New Item dialog and selecting the corresponding item templates under the Extensibility node. This solves the old problem of how to add a second command or toolwindow to an existing package, at the cost of making it more difficult to know how to add the first ones.

I will elaborate on all these aspects in the next weeks (during my vacations, I’m afraid), and will provide new links on this site to VS 2015 specific stuff.

Did I mention that my extension MZ-Tools 8.0 is now a package for VS 2012, 2013 and 2015? It is also an add-in for VS 2005, 2008 and 2010, and they share 80% of code at binary level using the strategy of core plug-in +  host adapters that I outlined here. I have even released in the last weeks a restricted Beta 2 of MZ-Tools 8.0 for the VBA editor of Office and even for VB6 / VB5 sharing the same 80% of binary .NET code. This is an example of a complex add-in migrated to a package with a new good underlying architecture to accommodate not only future changes in the extensibility model of Visual Studio, but also to support other Microsoft IDEs.

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

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)

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:

GenerateLoadKeysFirefox

If you use Internet Explorer, you get the warning:

GenerateLoadKeysInternetExplorer

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):

GenerateLoadKeys

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.

For older versions of Visual Studio that still require a PLK or SLK, you can use the PLK/SLK generator tool.”

that is wrong, since Visual Studio 2010 doesn’t require PLK/SLK either, and in fact the combobox of the “Generate a Key” page is right and only offers Visual Studio versions until VS 2008:

GenerateLoadKey

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

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:

NewProject

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

ProjectProperties

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.