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

4 thoughts on “MSDN Magazine article: Creating Extensions for Multiple Visual Studio Versions”

  1. Hi Carlos – I thought your MSDN article was really great. It helped me get most of my extension working across vs2013, vs2015 and vs2017 with one executable.

    There is one issue I haven’t been able to solve in an elegant way. I followed your suggestion and targeted VS2013 and so used v12.0.0.0 of the assemblies I use, and I had a test machine with all three versions of Visual Studio installed.

    Most of my extension worked first time (thanks!). But one piece of functionality uses the VCCodeElement in the VCCodeModel assembly. It turns out that the VCCodeModel is not automatically redirected by the devenv.exe.config file. So when I first tested this on my dev machine (with just vs2017 installed), that functionality failed because the required assembly version could not be loaded. That was easy enough to solve using the AssemblyResolve event handler.

    Unfortunately on my test machine (with all three versions of Visual Studio installed), the assembly is present in the GAC, so AssemblyResolve is never called and I end up with most of my assemblies being redirected to the relevant version for which ever Visual Studio I run, except for the VCCodeModel which is always the version 12.0.0.0 assembly from the VS2013 installation. So in VS2015 and VS2017 I then get invalid COM interface errors when I convert an EnvDTE.CodeElement to a VCCodeModel.VCCodeElement because I am using incompatible versions of the assemblies.

    If all 3 versions of Visual Studio are installed then my extension will only have full functionality in VS2013! Alternatively I can remove VS2013 and then the extension works fine for both VS2015 and VS2017.

    I could of course manually edit the devenv.exe.config files to redirect the VCCodeModel.dll. This works, but it is not a great solution: if you want to distribute the extension, then you’d have to tell your users to manually edit their config files too.

    As far as I can see this means, if I want to use the VCCodeModel (and possibly other assemblies that may not be present in the devenv config file) then I do not have an elegant way of building a single extension that will work in VS2013, VS2015, and VS2017 if multiple versions are installed on the same machine.

    If you have any ideas about how to force VS2015 and VS2017 to ignore the 12.0.0.0 version of VCCodeModel, other than amending the devenv config files, then I would be very pleased to hear it!

    Regards

    1. Hi Andrew,

      I am not very familiar with VCCodeModel and other VC*.* extensibility assemblies especific for C++, but AFAIK, each version of VS requires its own VC assemblies, on the contrary to the general automation assemblies (EnvDTE, VSLangProj) which are cross-version. You can ask at https://gitter.im/Microsoft/extendvs/ for the VS team or someone with the proper knowledge to answer.

  2. Hi Carlos – I thought I’d quickly update here just in case any of your other readers have a similar issue. I found a good way around my particular problem.

    Just a recap – I want to target VS versions 2013 – 2017. I now follow your suggestion and build using VS 2017. All the referenced assemblies are from VS2013 and are version 12 (or earlier), except for the VCCodeModel assembly which I reference from VS2017 and is version 15. With this configuration, the AssemblyResolve event is triggered for VS2013 and VS2015 and I can force version 12 or version 14 of the VCodeModel accordingly. All the other assemblies I use are redirected automatically by the devenv.exe.config file.

    So it’s not quite according to your recommendation, but it seems to work very well.

    Regards
    Andrew

Comments are closed.