Page 16 - MSDN Magazine, August 2017

sion (or lower). If your extension uses a DLL introduced by Visual Studio 2013 or higher, the extension won’t work on a machine with only Visual Studio 2012. The second principle is that the extension never must deploy Visual Studio DLLs, neither to the locations I mentioned (folders of Visual Studio or GAC), nor to the installa- tion folder of the extension. These DLLs are provided by the target Visual Studio, which means that the VSIX file shouldn’t include them.
Many Visual Studio DLLs have a version number (8.0 ... 15.0) in the name, such as Microsoft.VisualStudio.Shell.11.0.dll or Microsoft.VisualStudio.Shell.Immutable.10.0.dll. These help to iden- tify the Visual Studio version that introduced them, but don’t get fooled: it’s a name, not a version. For example, there are four ver- sions (11.0.0.0, 12.0.0.0, 14.0.0.0 and 15.0.0.0) of Microsoft.Visual. Studio.Shell.11.0.dll, each one provided, respectively, by a Visual Studio version (2012, 2013, 2015 and 2017). The first three 11.0.0.0 to 14.0.0.0 are installed by the respective Visual Studio version in the GAC and the fourth version, 15.0.0.0, used by Visual Studio 2017, is installed in the Common\\\\IDE\\\\PrivateAssemblies folder.
Because an extension that targets Visual Studio 2012 and higher must use Visual Studio assemblies with version 11.0.0.0 (the first principle mentioned earlier), this means that the reference Microsoft.Visual.Studio.Shell.11.0.dll must be version 11.0.0.0. But because that version isn’t installed by Visual Studio 2013 and higher (they start at version 12.0.0.0), and the extension shouldn’t deploy Visual Studio DLLs (the second principle), wouldn’t the extension fail when trying to use that Visual Studio DLL? The answer is no, and it’s thanks to an assembly-binding redirection mechanism provided by the .NET Framework, which allows you to specify rules like “when something requests this version of an assembly, use this newer version of it.” Of course, the new version must be fully backward-compatible with the old version. There are several ways to redirect assemblies from one version to another. One way is this: An executable (.exe file extension) can provide an accom- panying configuration file (.exe.config file extension) that speci- fies the redirections. So, if you go to the Common7\\\\IDE folder of your Visual Studio installation, you’ll find the devenv.exe execut- able of Visual Studio, and a devenv.exe.config file. If you open the .config file with a text editor, you’ll see that it contains lots of as-
sembly redirections:
<dependentAssembly> <assemblyIdentity
name="Microsoft.VisualStudio.Shell.11.0" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="2.0.0.0-14.0.0.0 newVersion="15.0.0.0"/>
</dependentAssembly>
So, Visual Studio 2017 (15.0) has an assembly version redirection for Microsoft.VisualStudio.Shell.11.0 that states that whenever some- thing requests old versions 2.0.0.0 to 14.0.0.0, use the new version 15.0.0.0 instead. That’s how Visual Studio 2013 or later can use an extension referencing Microsoft.VisualStudio.Shell.11.0 version 11.0.0.0, even if they don’t provide that exact version.
Developing the Extension
Now that you know how things work at run time, you can develop the package. To recap, you’ll create a VSIX project using Visual
Studio 2017 with a manifest that targets Visual Studio versions from 12.0 to 15.0; it will contain a package and a command; and it will use only references with version 11.0.0.0 (or lower) installed by Visual Studio 2012.
You might wonder at this moment which Visual Studio versions should be installed on your development machine. The best prac- tice is to have two development machines as follows: On the first, if you have enough space on your disk, install all the Visual Studio versions—2012, 2013, 2015 and 2017. They can all coexist side by side and you’ll be able to test them during development. For Visual Studio 2017, even different editions such as Community, Professional and Enterprise can coexist at the same time, something that wasn’t possible with older versions of Visual Studio. If available space is a concern, install the minimal components for the old versions, or skip some version in the middle of the range (2013 or 2015).
On your second development machine, install only Visual Studio 2017 or, even better, a build server with no Visual Studio version installed (just the Build Tools 2017), to build your extension for release. This approach will help ensure that you’re not inadvertently using DLLs or other dependencies from folders installed by older Visual Studio versions. You might also wonder if it wouldn’t be safer to develop or build on a machine with only Visual Studio 2012 installed and the answer is that it’s not possible: To generate a VSIX file for Visual Studio 2017 (which creates a version 3 manifest and adds the catalog.json and manifest.json files), you need the Visual Studio SDK 15.0 of Visual Studio 2017 or, with some work, the Visual Studio SDK 14.0 of Visual Studio 2015. Neither the Visual Studio SDK 12.0 of Visual Studio 2013 nor the Visual Studio SDK 11.0 of Visual Studio 2012 can generate VSIX files for Visual Studio 2017.
And the best practice for (serious) testing is: Use a separate machine (virtual or cloud-based) for each Visual Studio version (so you’ll need four machines to test your extension on Visual Studio 2012 to Visual Studio 2017 in isolation). This best practice helped me to find some errors in the code sample for this article!
And the best practice for (serious) testing is: Use a separate machine (virtual or cloud-based) for each Visual Studio version.
To get the Visual Studio 2017 project templates to create a package (or any other kind of extension) you need the “Visual Studio exten- sion development” workload. If you didn’t install it when you first installed Visual Studio 2017, go to the folder C:\\\\Program Files (x86)\\\\ Microsoft Visual Studio\\\\Installer, launch vs_Installer.exe, click the Modify button and select that workload at the bottom of the list.
Create a new VSIX project using the File | New | Project menu; go to the Visual C# | Extensibility templates; ensure you’ve selected .NET Framework 4.5 on the dropdown list at the top; and select the
12 msdn magazine
Visual Studio