VSIX extensions built against VS2010 that involve deep integration with Visual Studio take many dependencies on core Visual Studio extensibility assemblies. Many of these assemblies use a versioning strategy that has the name of the assembly contain the version of the Visual Studio they are specific to. (e.g. Microsoft.VisualStudio.Shell.10.0.dll).
In VS2012, the names of these critical integration assemblies has been changed, (e.g. Microsoft.VisualStudio.Shell.11.0.dll) negating the possibility of using assembly binding redirection to manage the dependency.
As such, said VSIX extensions are required to change the names of their assembly references, and be recompiled against the new versions of these assemblies.
In order to create a VSIX that is compatible with both VS2010 and VS2012, the source code needs to be VS version aware.
Several strategies are possible, and some may require significant rework to be viable. For example:
- Fork the source code into code that compiles against VS2010, and code that compiles against VS2012.
- Use build configurations, MS build variables, text templates, and other mechanisms in order to target a specific version of Visual Studio.
Abstract all references to Visual Studio extensibility behind an interface layer, and dynamcially load the correct implementation at runtime.
A progressive hybrid approach may be sought in order to keep project momentum.
Option 1. Offers difficulties in ongoing maintenance, and increases complexity, with two forks of the same code, which can evolve independently. It results in a seperate VSIX redistributable for VS2010 and VS2012. But the initial rework to set this up is minimal.
Option 2. Also results in a seperate VSIX redistributable for VS2010 and VS2012, but does not fork the codebase, reducing complexity to a minimum as the differences between VS versions can be contained in the same source base. There is some rework in reworking the mechanisms to target different versions of VS.
Option 3. Results in a single redistribute that is compatible with all versions of VS (past and present). Differences between versions of VS can also be contained in the same code base. However, this option requires significant and time consuming effort in factoring out the VS extensibility dependencies into interface layer, and building the dynamic loader.