Category Archives: VS Extensibility

VS Extensibility

More hell issues code signing VSIX extensions

Continuing on the subject of “Code signing a VSIX package with a hardware-based USB token key”, there are some issues with the new hardware-based code signing certificates shipping since June 1, 2023 make the code signing extremely tricky or impossible in Yubikey keys, the most popular ones.

Here they are and please vote up for them for Microsoft to improve the current scenario:

  1. “Misleading documentation regarding SHA256 required to sign VSIX packages”: https://developercommunity.visualstudio.com/t/Misleading-documentation-regarding-SHA25/10481764
  2. “Insufficient documentation to sign VSIX packages”: https://developercommunity.visualstudio.com/t/Insufficient-documentation-to-sign-VSIX/10481776
  3. “Add support in Visual Studio 2015 and higher for ECDSA-SHA256 (and not only RSA-SHA256) for code-signing VSIX packages”: https://developercommunity.visualstudio.com/t/Add-support-in-Visual-Studio-2015-and-hi/10481797
  4. “VSIXInstaller should log the exception that causes “Invalid signature” installing code-signed VSIX extensions”: https://developercommunity.visualstudio.com/t/VSIXInstaller-should-log-the-exception-t/10481800
  5. “vsixsigntool.exe shows incorrect error message when duplicating the /fd flag”: https://developercommunity.visualstudio.com/t/vsixsigntoolexe-shows-incorrect-error-m/10481804

Visual Studio Extensibility is tricky, as usual 🙂 And current tooling / documentation / implementation doesn’t help. Even the tool that you use for code signing (vsixsigntool.exe) has a verify verb (apart from the sign verb that you know) that is useless because, being a native tool (not a .NET-based tool), it can state that the signature is valid but VSIXInstaller.exe (which is .NET-based) can state that it is not (for example, using ECDSA-SHA256) because crypto support is not exactly the same in native implementation and in .NET implementation. It’s a good thing that code signing is not mandatory for extensions as it is for regular setups…

And although not related to code signing, you may also vote up the following, which would be very handy for VSIX developers and are long overdue:

  1. “Single VSIX entry in Visual Studio marketplace for VS 2022 and for VS 2019 and lower”: https://developercommunity.visualstudio.com/t/Single-VSIX-entry-in-Visual-Studio-marke/1584630
  2. “VSIX project with SDK-style csproj”: https://developercommunity.visualstudio.com/t/VSIX-project-with-SDK-style-csproj/1572145
  3. “Make Shared Project SDK style”: https://developercommunity.visualstudio.com/t/Make-Shared-Project-SDK-style/10296159



VS Extensibility

Code signing a VSIX package with a hardware-based USB token key

Yes, I know that 5 years have passed since my last post here. That last post was about Code signing a VSIX package targeting multiple Visual Studio versions and this one is a continuation. As you may know, there are three kinds of code signing certificates:

  • Individual Validation (IV)
  • Organization Validation (OV)
  • Extended Validation (EV)

Until June 1, 2023, only EV certificates were issued on hardware-based devices such as USB keys. But since that date, IV and OV certificates provided by all vendors are only issued either on Federal Information Processing Standard 140-2 (FIPS 140-2) USB tokens or some kind of cloud-based code signing FIPS-compliant service. This change is in compliance with the Certificate Authority/Browser (CA/B) Forum’s new key storage requirements to increase security for code signing keys. Although it is expected that instances of code signing keys being stolen and misused by malicious actors will be greatly reduced, this poses a challenge to sign VSIX packages using the vsixsigntool.exe tool due to lack of documentation.

In this scenario, you have:

  • A certificate without the private key. You have got this certificate from the vendor and imported into the USB key, or you have got a USB device with the certificate already preloaded from the vendor directly. When you insert the key in the USB port (with maybe a Windows smart card driver installed) the certificate appears also in the Windows Certificate Store for user (certmgr.exe), in the Personal > Certificates node. Apparently the vsixsigntool.exe tool doesn’t support certificate files in .per or .crt formats, and the .pfx format requires the private key, so you have to use the .p7b format for the certificate file. You can export the certificate from the Windows Certificate Store to the .p7b format.
  • A private key inside the USB key that cannot leave the device (hence the enhanced security).

Since you don’t have a password-protected .pfx file with the certificate and the private key, you can’t use the /p flag (for the password) of the vsixsigntool.exe tool. Instead, you must provide access to the private key inside the USB device using the following flags:

  • /f: Path to the certificate file in .p7b format (without the private key)
  • /csp : Specify the Cryptographic Service Provider (CSP) containing the Key Container of the private key.
  • /k : Specify the name of the Key Container of the private key.

The steps to sign VXIS packages with a hardware-based USB key are the following:

  • Get the SHA1 Thumbprint of the certificate. To get it, locate the certificate Windows certificate store of user (certmgr), open it and in the Details tab look for the Thumbprint property. It should be a string of 40 characters.
  • Get the name of the CSP provider containing the container of the private key. To get it use this command and use the “Provider” field of the output:

    certutil.exe -user -store my "<SHA1-thumbprint-of-your-certificate>"

    It should be something like “Microsoft Smart Card Key Storage Provider”.
  • Get the name of the Key Container of the private key. To get it use the same previous command and use the “Key Container” field of the output. It should be something like a GUID.

With all those pieces, the command would be something like this:

vsixsigntool.exe sign /f <CodeSigningCertificate.p7b> /csp <CertificateCryptographicServiceProvider> /k <CertificateKeyContainerName> /sha1 <CertificateSHA1Thumbprint> /fd sha256 /t <TimeStampServerUrl> <MyVSIXProject.vsix>

At that point you should get a prompt to enter the PIN of your USB key to get access to the private key and the VSIX file should be signed successfully.

VS Extensibility

The VisualStudio-TestHost project to execute interactive UI tests in Visual Studio

3 Comments

I started with automated tests for my MZ-Tools extension early in the development of version 7.0 (then an add-in, not a package), ten years ago, around the year 2008 or so. At that time Visual Studio 2008 provided a Visual Studio TestHost dll (even with source code, if I remember correctly) to run automated tests of Visual Studio packages using the own Visual Studio. I remember that it was so painful to use that approach (crashes, hangings, etc.) that after months of investment I threw all the stuff and started to build my own test framework infrastructure and test runner:

(yep, I have 3,354 automated integration tests for my extension for Visual Studio)

It was perfect in most aspects because I owned the code and could adapt it to my needs but it had one important inconvenient: it didn’t allow Continuous Integration (CI). Instead, I ran the tests manually before each (monthly) build. It had another inconvenient: I learned automated testing by myself without formal training and I ended with tons of integration tests (which use the real Visual Studio to host the extension), no system tests (that would mock Visual Studio) and no unit tests (that just test a single method or class). I know now that, for performance reasons, it is much better to have have a pyramid with tons of unit tests, lots of system tests and few integration tests.

Last year I started to focus on DevOps (even if I am a solo developer) and continuous integration, and decided to make my test framework infrastructure compatible with VS Test / MSTest, so I could keep using my own test runner for integration tests but use them 100% as system tests mocking Visual Studio with stubs:

As you can see, my progress is quite modest at this point (only 133 system tests vs 3,354 integration tests) because I need to mock the full EnvDTE.FileCodeModel for most tests. But it is a feasible approach because I have fully mocked with stubs the whole VBA / VB6 IDEs that I use for MZ-Tools 8.0 for VBA / VB6. So, for example I have 1,822 integration tests for VB6 with my own test runner (an add-in for VB6):

And the same 1,822 tests as system tests using the test runner of Visual Studio:

Once I finish the system tests for Visual Studio, the next step is to give another try to run the integration tests using the test runner of Visual Studio, rather than my own test runner, which will allow me Continuous Integration not only for system tests, but also for integration tests. For such approach, I learned in the Two videos about building High Performance Extensions by Omer Raviv about the Microsoft/VisualStudio-TestHost project on GitHub. I have still to read and learn about it, but I think it is based on the code of the VS TestHost of 2008 and hopefully these 10 years have been used to solve the problems that caused me to abandon that approach.

Update (July 29, 2018): yesterday I finished the last stubs for Visual Studio and now all the integration tests for the real Visual Studio are also system tests with stubs that simulate the behavior of Visual Studio:

VS Extensibility

Two videos about building High Performance Extensions by Omer Raviv

Omer Raviv, author of the OzCode extension for Visual Studio, has recorded two videos with Robert Green on Channel 9 about building high performance extensions for Visual Studio. If creating extensions for Visual Studio is already tricky, creating high performance extensions is quite difficult and Omer has some advices and techniques about it.

The first video is this one:

Building High Performance Extensions Part 1

And the second one is this:

Building High Performance Extensions Part 2

VS Extensibility, VS Packages

MSDN Magazine article: Creating Extensions for Multiple Visual Studio Versions

4 Comments

Back in April or May I started to write a post on this blog about creating extensions for multiple Visual Studio versions. I have been struggling to support multiple versions of Visual Studio with my MZ-Tools add-in since Visual Studio .NET (2002) / 2003, and other IDEs such as VB6/VB5/VBA before that. So, I know how tricky it can be to share as much code as possible between versions, and using a single binary dll / setup if possible. It seems that I am not the only one wanting to target multiple Visual Studio versions with a single vsix package because I have seen lots of questions in the forums, chat rooms and private email asking about it. The post on this blog was never finished, because it was becoming so long that I thought it would be… a good article for MSDN Magazine! And finally today it has been published in the August issue:

Visual Studio – Creating Extensions for Multiple Visual Studio Versions

VS 2017, VS Extensibility

Sample code and utilities to get installed Visual Studio 2017 editions programmatically

As I explained in the post Some implications of the new modular setup of Visual Studio 2017 for VSX developers, Visual Studio 2017 has changed all that you knew about installations of Visual Studio. In this episode of Channel 9, Art Leonard explains to Robert Green the internals of this re-architecture of Visual Studio:

The use of a private registry file causes that if you want to know programmatically the installed editions of Visual Studio 2017, the old approaches don’t work. For example, my article HOWTO: Detect installed Visual Studio editions, packages or service packs is now obsolete.

Fortunately, Microsoft provides a new Setup API to query the installed editions of Visual Studio 2017 or the highest VSIXInstaller.exe, along with sample code and utilities:

Visual Studio Setup Configuration Samples
Microsoft/vs-setup-samples
“This is a sample in various programming languages that demonstrates how developers can use the new Visual Studio setup query API. The included samples show how to use the new setup configuration API for discovering instances of Visual Studio 2017”.

Visual Studio Locator
Microsoft/vswhere
“Over the years Visual Studio could be discovered using registry keys, but with recent changes to the deployment and extensibility models a new method is needed to discover possibly more than once installed instance. These changes facilitate a smaller, faster default install complimented by on-demand install of other workloads and components. vswhere is designed to be a redistributable, single-file executable that can be used in build or deployment scripts to find where Visual Studio – or other products in the Visual Studio family – is located.”

Visual Studio Setup PowerShell Module
Microsoft/vssetup.powershell
“This PowerShell module contains cmdlets to query instances of Visual Studio 2017 and newer. It also serves as a more useful sample of using the Setup Configuration APIs than the previously published samples though those also have samples using VB and VC++.”

VSIX Installer Bootstrapper
Microsoft/vsixbootstrapper
“An installer that can be chained with other packages to locate the latest VSIXInstaller.exe to use for installing VSIX extensions. One of the great new features of Visual Studio 2017 is an initial smaller and fast install. To compliment a smaller – but powerful – initial feature set, installing additional workloads and components on-demand is supported for both end users and package developers. Package developers can install their VSIX extensions for Visual Studio using this bootstrapper to find the latest version of VSIXInstaller.exe and install their extension(s). This may be preferable for extensions that support Visual Studio 2017 or newer than installing extensions in Windows Installer .msi packages, since MSIs cannot run concurrently in separate processes. Other deployments may also benefit since they no longer have to find where VSIXInstaller.exe is installed. The command line passed to VSIXBootstrapper.exe is passed through to VSIXInstaller.exe.”

VS 2017, VS Extensibility, VS Packages

Building a VSIX extension with the Visual Studio 2017 Build Tools

As I explained in the post Migrating the build of a VSIX project to a build server if you are a solo developer, I am taking the steps to build my MZ-Tools extension on a build/release server. As part of that process, I realized than rather than installing Visual Studio 2017 Community edition on the server, I could use the Visual Studio 2017 Build Tools that were thought, well, for build servers that don’t need the overhead of a Visual Studio 2017 installation. They are a lightweight version of Visual Studio 2017 without the IDE (devenv.exe executable). They can be used to build either managed (C#, VB.NET, etc.) projects or native (C++) projects. Incidentally my MZ-Tools solution has both type of projects.

The Visual 2017 Build Tools can be downloaded from here. Once you install them on a clean machine, you will notice that they provide only the following:

  • A built-in (non-optional) set of components to build MSBuild-based projects (for example managed projects).
  • An optional workload “Visual C++ build tools”.
  • An optional workload “Web development build tools”.

There are also optional individual components to install .NET Framework 4.6.1 support Windows SDKs, ATL support, etc.:

In my case my extension needs to use .NET Framework 2.0 for some projects (I still support Visual Studio 2005). Since that version is not installed by default on modern versions of the Windows OS, I need to install it going to “Control Panel”, “Programs and Features” item, “Turn Windows Features on or off” link:

My obfuscator tool needs the .NET Framework 3.5 SDK (or the .NET Framework 2.0 SDK). While the Visual Studio 2017 Community installer provides the optional individual component “.NET Framework 3.5 developments tools”, the installer of Build Tools 2017 doesn’t. That is not only a pity but also causes a bug if you install yourself the Windows 7.0 SDK that contains the .NET Framework 3.5 SDK that I reported here: the resource .resx files of a .NET project targeting .NET Framework 2.0 are compiled using the Assembly Linker (al.exe tool) of the .NET Framework 4.0, which will cause them to fail silently at run-time. Microsoft fixed the bug just in time for RTM in Visual Studio 2017, but the Build Tools 2017 still has the bug due to the lack of the “.NET Framework 3.5 developments tools”. There is a fix that I explained in the bug report if you find this problem. I have also requested to Microsoft to include the “.NET Framework 3.5 developments tools” in the installer of Build Tools 2017.

My extension for Visual Studio targets version 2012, so I need to stick to .NET Framework 4.5, not some higher version. Since that version is not provided by the Build Tools 2017, I need to install the Windows 8.0 SDK, that contains the .NET Framework 4.5 assemblies and SDK.

For the C++ projects, I needed to install:

  • “Visual C++ ATL Support”: required to get files such as atlbase.h, etc.
  • “Windows 8.1 SDK”: I could upgrade to some Windows 10 SDK version but they occupy much more space on disk.
  • “UCRT SDK”: the Universal Common RunTime that provides files such errno.h and other files in the folder “C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt”.
  • “.NET Framework 4.6.1 SDK”: to get files such as mscoree.h / mscoree.lib in the folder “C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\”.

My build script uses tf.exe to set a workspace and download the latest sources. Alas, tf.exe is not installed with Build Tools 2017 (Visual Studio 2017 installs the Team Explorer extension, that contains that file in the folder “C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer”). Now there is a standalone installer for Team Explorer (that includes tf.exe) announced here. Since that’s a bit overkill, I just copied tf.exe and the required dlls.

The build script needs also nuget.exe, but that’s easy to get.

So, when I thought that I had all the required components installed, I tried to build the extension. I got the following problems:

First, the error “Error’MSB4226: The imported project “(…)\VSSDK\Microsoft.VsSDK.targets” was not found.” Initially I thought it was a bug, that I reported to Microsoft here, but I discovered that the problem was solved setting the “VisualStudioVersion” MSBuild property, something that a machine with the full Visual Studio 2017 does and that a machine with the Build Tools 2017 does if you open a developer command prompt. Since I was not using it, I passed it as a parameter to the MSBuild script. It can be defined too inside the .csproj file, something that previous Visual Studio versions did automatically but recent versions don’t.

Then I got an error about a missing Microsoft.VisualStudio.Settings.15.0 file. How is that a file from Visual Studio is required by the NuGet package that provides the Visual Studio SDK?. It happens that Microsoft.VsSDK.Build.Tasks.dll, the file that contains the MSBuild tasks needed when creating a VSIX file, references it. But on a machine without Visual Studio, that dll is not present. I discovered that despite the error, the VSIX file was generated correctly, so that DLL was required for a task after generating the VSIX file. That task is to deploy the generated VSIX file to the experimental instance for debugging. Since on a release server that step is not needed, I knew how to instruct the .csproj project file to avoid it:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
   ... 
   <!-- Do not deploy the extension in Release configuration -->
   <DeployExtension>False</DeployExtension>
</PropertyGroup>

Finally, when I thought that all obstacles were solved, I got an error about the Microsoft.Visualstudio.Shell.Interop.dll being delay-signed rather than strong-signed. Since my development machine has tons of Visual Studio versions and SDKs, I discovered that all the Microsoft.Visualstudio.Shell.Interop.dll files were strong-named except an old one, which somehow Microsoft shipped delay-signed, and that was the one that I was referencing. So, I only need to change it by the correct version. And finally, my extension generates a VSIX file on a release server with only the Build Tools 2017 plus some additional components, but without Visual Studio 2017 installed.

The next step is to install some agent to connect to the Build/Release Management of Visual Studio Team Services.

VS Extensibility

Microsoft, the Visual Studio Shells and the old versions

2 Comments

Visual Studio 2008 started to offer a new form of extensibility: a whole IDE for your app! That is, reusing the core of the Visual Studio IDE for your own tool instead of reinventing the wheel creating a new IDE from scratch. This is named Visual Studio Shell and there are two flavors: the “Isolated Shell“, where your app has its own instance of Visual Studio Shell even if the Visual Studio IDE is already installed (because the user is a developer); and the “Integrated Shell“, where if the Visual Studio IDE is already installed, your Visual Studio Shell integrates with it (otherwise is installed anyway).

I have never worked with the Visual Studio Shell, nor I have any knowledge, but I provide a page on this site for the download links. Alas, it seems that Microsoft doesn’t pay much attention to keep the links working, so I get questions on forums and by email about their availability. If the links of that page fail, you can try the following:

It would be nice if Microsoft provided a centralized, public page with the downloads that VSX developers may require to develop and test extensions (Visual Studio SDKs, .NET Framework SDKs, Visual Studio Shells, Community editions, etc.) and, very important, from the current Visual Studio version going back to… Visual Studio 2005 and .NET Framework 2.0. Not everyone wants or can use the latest bits. I keep a couple of hard disks at home and at my basement with all the required Visual Studio versions, Visual Studio SDKs, Windows SDKs, .NET Framework SDKs, Windows OS versions,  etc. fearing that they would disappear from the web some day (which certainly is happening with the shells). And now that Microsoft uses web-based installers for Visual Studio with no .iso file provided, I am even afraid that my Visual Studio 2017 installer won’t work in a few years, so I have to create an offline installer.

VS 2017, VS Extensibility, VS Packages

Migrating the build of a VSIX project to a build server if you are a solo developer

2 Comments

Some months ago I started a long and slow journey to migrate the build process of my MZ-Tools extension from a custom .NET-based builder that ran on my development computer to Visual Studio Team Services, leveraging its Build management and Release management capabilities. My goals are to learn those capabilities and, well, to use them as if I were a team. I haven’t reached yet that destination but I have made significant progress and I am quite close now. In the process I have realized somewhat ashamed that I wasn’t following the best practices in a lot of places. I say “somewhat” because there are some mitigating circumstances:

  • Being a solo developer it is too easy to arrange things in such a way that only works on your development machine. You don’t have a team to warn you that it doesn’t work outside your development machine.
  • Even if you change your development machine to a new one from time to time, or use two development computers, you use the same username and tend to install and configure the software in the same way.
  • My Visual Studio solution and some projects were born in the year 2002, with the first Visual Studio .NET. At that time Team Foundation Server, NuGet, MSBuild, etc. didn’t even exist on paper.
  • I have all the Visual Studio versions and VS SDKs from 2005 to 2017 installed on my development machine. That causes that you don’t think carefully where a DLL is referenced from.
  • I have also all the .NET Frameworks and SDKs from .NET Framework 2.0 installed on my development machine. Another source for undocumented hidden dependencies.
  • My Visual Studio solution has become quite complex over the years with several projects and technologies:
    • One project that uses .NET Framework 2.0 and C# for the core plug-in, that is reused at binary level for many Microsoft’s IDEs.
    • Four projects with host adapters for Visual Studio (2005, 2008, 2010) as add-in, VBA (Microsoft Office 2000 or higher, even on Windows XP), VB 6.0 and VB 5.0, using .NET Framework 2.0, C# and 3rd party tool for the setups.
    • One project with a host adapter for Visual Studio (2012, 2013, 2015 and 2017) as package, using .NET Framework 4.5, C#, and VSIX.
    • Four projects with COM Shims for VBA (32-bit and 64-bit), VB 6.0 and VB 5.0 using Visual C++, ATL, Windows 8.1 SDK and the .NET CLR loader APIs.
    • One project for a portable version for VBA, using .NET Framework 2.0 and C#.
    • Help file and online help generated by a 3rd party tool.
    • Two projects with integration tests.
    • Obfuscation performed by a 3rd party tool, that requires delay signing.

Microsoft tends to create a new VSIX with each new Visual Studio release but most of us want to create a single package and single VSIX for as many Visual Studio versions as possible, using always the latest Visual Studio version for development (Visual Studio 2017 at the time of this writing). If this is your case, even if your solution is not as complex as mine, ask yourself these questions:

In the process that I have followed first I envisioned the final result:

  • I would use the hosted agent of the Build management of Visual Studio Team Services to provide the following benefits:
    • Gated check-ins to prevent code that breaks the build.
    • Gated check-ins to prevent code that violates code analysis rules.
    • Integration tests. This will require a major effort because I use my own test runner and testing framework instead of Visual Studio Test with the MSTest framework.
  • I would use a private agent on the Release server with the Release management of Visual Studio Team Services to provide the following benefits:
    • Tracking of releases deployed to the test environment, to the pre-production environment and to the production environment.
    • Maybe automated releases.

For these purposes I decided that I would use a new “Build” configuration of the solution for the Build server. In this configuration the obfuscation, help file and online help, setups, etc. are not created. For the Release server I would use the “Release” solution configuration that performs all those additional steps.

For the Build server it is quite easy and I can use the hosted agent of Visual Studio Team Services since I don’t need any 3rd party tools.

For the Release server I cannot use the hosted agent because I need the 3rd party tools that I use to obfuscate, create the help, setups, etc. In the process I have also removed the need for admin rights that my custom builder required previously (the hosted agent of Visual Studio Team Services doesn’t allow admin rights either).

The milestones would be:

  • Migrate the custom .NET-based builder to a MSBuild script. This took me weeks but it’s done.
  • The solution and projects, when built in “Release” configuration, would auto-increment version numbers and would obfuscate the output assemblies, build the help, setups, etc. with their own MSBuild targets without requiring external steps.
  • A master MSBuild script would perform some additional steps before building the solution (such as creating a workspace, getting latest files, restoring NuGet packages, etc.) and some other steps afterwards (such as publishing and archiving binaries).
  • Build on a separate workspace on my development machine. Previously I was building on the same workspace used for development. I know, I know, a horrible bad practice.
  • Create a separate temporary virtual machine to act as Release server with only Visual Studio 2017 Community edition installed, without previous Visual Studio versions to identify missing dependencies and build with the master MSBuild script.
  • Discard the virtual machine of the previous step and create a new virtual machine with the Build Tools 2017 but without Visual Studio 2017, identify and install missing dependencies, build with the master MSBuild script and document everything. I have reached this point!
  • Install a private Visual Studio Team Services agent on the virtual machine that acts as Release server and launch the master build script from the Release management section of Visual Studio Team Services.
  • Create additional scripts to publish binaries to the pre-production and production environment rather than using manual FTP.
  • Repeat everything with the solution for my ASP.NET web site.

I encourage you to follow the same journey if you are a solo developer (and of course if you are a team). At the very least, the exercise of building on a separate build server with only Build Tools 2017 will unhide you hardcoded paths, references that are not provided by source control or supplied as NuGet packages, etc.

VS 2017, VS Extensibility, VS Packages

Microsoft now working on conditional payloads for VSIX. And for VS 2017 service release!.

1 Comment

Almost three years ago I created this request on Uservoice:

Conditions support for <Content> section of VSIX manifest

This request tries to solve a problem that is increasingly tricky: while Microsoft (or developers that work within Microsoft) release a new extension for each new Visual Studio version, most of us want desperately to update our existing extensions to support multiple versions of Visual Studio. Ideally we would like to have a single package DLL that targets many Visual Studio versions, but if you want to use the latest extensibility APIs, then most of the time you are forced to add references that demand a new package DLL because those references don’t exist on old versions of Visual Studio. But yet, we would like to ship those different package DLLs in the same unified VSIX file, so that for some versions of Visual Studio the VSIX file deploys a package DLL, and for other versions of Visual Studio the VSIX file deploys a different package DLL. Even you may want to deploy different .pkgdef files, as I explained in the request. And nowadays, with the release of Visual Studio 2017 and its manifest “v3”, we would like even different manifests (“v1” for Visual Studio 2010, “v3” for Visual Studio 2012-2017) within the same VSIX, which would solve the most common question on the forums these days: “How can I make a single VSIX that targets Visual Studio 2010-2017?” (sorry, you can’t).

Today, I have received an update from UserVoice indicating that Microsoft is now working on it, and that it will be “for a future servicing release of Visual Studio 2017”. Big news!!!

You can still vote for the idea to show user demand 🙂