Page 14 - MSDN Magazine, August 2017

Figure 3 Contents of a VSIX File
The Package DLL
A managed Visual Studio package is a DLL that contains a class that inherits from Microsoft.VisualStudio.Shell.Package. It’s decorated with certain attributes that help at build time to generate a .pkgdef file (which, as mentioned earlier, you can find inside the VSIX file and in the installation folder of the extension). The .pkgdef file is used at startup (older versions of Visual Studio) or at installation time (version 15.3 of Visual Studio 2017) to register the DLL as a package for Visual Studio. Once it’s registered, Visual Studio will try to load the package at some point, either on startup or when one of its commands is executed if the package uses delay loading (which is the best practice). During the attempt to load the man- aged DLL and initialize the package, three things happen: the DLL will be loaded by the Common Language Runtime (CLR) of a Microsoft .NET Framework version; it will use some DLLs pro- vided by a .NET Framework; and it will use some DLLs provided by Visual Studio. I will examine each of these in turn.
A .NET Framework is the sum of two things: The CLR + libraries (both base class and additional libraries). The CLR is the runtime (the JIT compiler, garbage collector and so forth) and it loads managed DLLs. In the distant past, each .NET Framework version 1.0, 1.1 and 2.0 (used by Visual Studio.NET 2002, Visual Studio.NET 2003 and Visual Studio 2005) provided its own CLR version (1.0, 1.1 and 2.0). However, the .NET Frameworks 3.0 and 3.5, used by Visual Studio 2008, continued to use the exact same CLR 2.0 of .NET Framework 2.0, instead of introducing a new one. Visual Studio 2010 intro- duced .NET Framework 4 and CLR 4.0, but since then all new .NET Frameworks 4.x have used CLR 4.0 (although swapping it “in-place” with a backward-compatible version rather than reusing the exact CLR 4.0 of .NET Framework 4). Since Visual Studio 2012 and higher
all use CLR 4.0, the CLR version is not a problem when the DLL of an extension targets Visual Studio 2012, 2013, 2015 and 2017.
Libraries constitute the second part of a .NET Framework; these are DLLs referenced by a Visual Studio project and used at run time. To develop a single extension that targets multiple ver- sions of Visual Studio, you must use the highest .NET Framework installed by default by the lowest Visual Studio version that you want to target. This means that if you want to target Visual Studio 2012 and higher, you need to use .NET Framework 4.5. You can’t use, say, .NET Framework 4.5.1 introduced by Visual Studio 2013, because any DLL introduced in that version would not be present on a computer with only Visual Studio 2012 installed. And unless you really need that DLL, you won’t want to force such users to install .NET Framework 4.5.1 to use your extension (it could hurt sales or downloads and support).
The release of a new version of Visual Studio is always a challenge for developers of extensions.
The extension also needs DLLs that are provided by Visual Studio (typically named Microsoft.VisualStudio.*). At run time, Visual Studio finds its DLLs at some well-known locations, such as the folder Common7\\\\IDE with its subfolders Common7\\\\IDE\\\\Public- Assemblies and Common7\\\\IDE\\\\PrivateAssemblies, and from the Global Assembly Cache (GAC). The GAC for .NET Framework 4.x is located at C:\\\\Windows\\\\Microsoft.NET\\\\assembly (there’s another GAC at C:\\\\Windows\\\\assembly, but that one is for older .NET Frameworks). Visual Studio 2017 uses a more isolated installation that avoids the GAC, relying instead on the folders described previously.
There are a couple of key principles to follow when developing and generating a VSIX file: You must use the versions provided by the lowest Visual Studio version your extension targets. That means that if you want to target Visual Studio 2012 and higher, you must use only assemblies and extensibility APIs provided by that ver-
Figure 4 The Contents of a Manifest File 10 msdn magazine
Visual Studio