How to create single VSIX extension for multiple Visual Studio version?

Question

Need to create common VSIX extensions which need to support all versions of Visual Studio(2010 to 2017).

I referred to the below link to achieve the above requirement.

https://msdn.microsoft.com/en-us/magazine/mt493251.aspx

In that, they told to add the package(go to the Visual Studio C# Items | Extensibility | VSPackage node, select the Visual Studio Package template and name it MyPackage.cs) to the VSIX project by using the Visual Studio Package template in VSIX project but my visual studio didn't have the Visual Studio Package item template. It only has the Visual Studio AsyncPackage template. I have added my visual studio details below.

Visual studio old version only have “Visual Studio Package” option and also they suggest to use the AsyncPackage now to create a common package for multiple Visual Studio versions. Kindly find that details here.

https://developercommunity.visualstudio.com/content/problem/293478/visual-studio-package-template-not-available-on-sd.html

If I have added the Visual Studio AsyncPackage in VSIX project, then followed the procedure, am facing below compilation error while VSIX project compilation.

Kindly suggest any solution to resolve that or else kindly suggest any other way to achieve my requirement.

Note: I have created a project with VS2012 with Visual Studio supported versions in vsixmanifest file. It's working only in VS2012 installed machine alone. Kindly advise on this.

Answer 1

I am the author of the MSDN Magazine article. It was written before Visual Studio Package project template was replaced by the Visual Studio Async Package project template.

Even if you could get the template (from an old VS version), it is not possible to target from VS 2010 to VS 2017 with a single VSIX, due to the three different versions of the manifest, as explained in the article. At most, you could target from VS 2012 to VS 2017.

But given Microsoft's push to use async packages (at least for auto-load packages) in VS 2017 15.8 and future VS 2019 16.0 and 16.1 (see Improving the responsiveness of critical scenarios by updating auto load behavior for extensions) the best future-proof approach is to develop a non-async package for VS 2010-2013 and another async package for VS 2015-2017. Because maybe your package doesn't require autoload today (async package would not be required), but maybe in the future it requires autoload (and then you would be forced to async package), or maybe Microsoft decides in VS 2019 16.2 that even non-autoload packages must be async too...

Note: you can try even async package on VS 2013 and higher with the sample Visual Studio 2013 backwards compatible async package but it is not worth if you need to target also VS 2010 and 2012.

Bottom line: focus your time on reusing as much code as possible between the two package projects that you must create to target VS 2010-2019.