Page 20 - MSDN Magazine, August 2017

Figure 8 Debug Experimental Instance
Visual Studio installation), the best approach is to get the assem- blies from wherever and create a folder called VS2012Assemblies under the root folder of the project. Then, copy the DLLs to that folder, reference them from there (using the Browse button of the project’s Reference Manager dialog) and add the VS2012Assemblies folder to source code control, ensuring that the DLLs are added to it (normally source code control tools don’t add DLLs by default). So, from this point, the required Visual Studio assemblies are part of the source code.
As you probably know, many Visual Studio projects support “round-tripping”; that is, they can be opened and debugged by several Visual Studio versions without suffering modifications.
To follow the principle of not including assembly references in the VSIX file and not even in the output folder, select each refer- ence and in the Properties window ensure that the Copy Local property is set to False. At this point the solution can be rebuilt without errors. Using Windows Explorer, go to the output folder. Only these files should be generated: extension.vsixmanifest, VSIXProjectVS2012_2017.dll, VSIXProjectVS2012_2017.pkgdef and VSIXProjectVS2012_2017.vsix.
When you build the project, one of the MSBuild targets deploys the extension to the Experimental instance of Visual Studio. This is an instance of Visual Studio that uses different folders and Registry entries than the normal instance, so that you don’t make the normal instance unusable if something goes wrong with your extension during development. (You can always reset the Experimental instance clicking the Windows Start button, typing
“Reset the” and executing the “Reset the Visual Studio 2017 Experimental Instance” command.) If you go to the Debug tab on the Properties page of the project, you can set the Start exter- nal program field to the Visual Studio 2017 devenv.exe file. (It’s important to change this if upgrading, since it would point to an old version of Visual Studio.) You can also see that the Command line arguments specify “Exp” as the root suffix (see Figure 8), so that the Experimental Instance is also used for debugging.
Click the Debug | Start Debugging menu entry and a new Visual Studio instance will be launched (notice its caption indicates “Experimen- tal Instance”). If you click the Tools | Invoke MyCommand1 menu entry, the package will be loaded, the command will be executed
and a message box will be shown.
If you want to use Visual Studio 2017 to debug the extension on
a previous Visual Studio version, you need to make two changes: First, because once the extension is built it’s deployed to the Visual Studio Experimental Instance of the version whose SDK was used to build the project, you need to remove the NuGet package Microsoft.VSSDK.BuildTools version 15.0 and use version 14.0 for Visual Studio 2015 or version 12.0 for Visual Studio 2013. For Visual Studio 2012 there isn’t a NuGet package for the VSDK, so you need to edit the .csproj file and point the VSToolsPath vari- able to the location of the VSSDK 11.0 (C:\\\\Program Files (x86)\\\\ MSBuild\\\\Microsoft\\\\VisualStudio\\\\v11.0), which you must install separately. Second, you need to go to the Debug tab on the Properties page of the project and set the Start external program field to the matching Common7\\\\IDE\\\\devenv.exe executable.
As you probably know, many Visual Studio projects support round-tripping. That is, they can be opened and debugged by several Visual Studio versions without suffering modifications. This is not the case with extensibility projects “out of the box.” However, with some mastering of MSBuild and Visual Studio SDKs, you may achieve it, but it’s always a tricky approach.
Once you’re done with the development and debugging, you can build your extension in Release configuration and test it on Visual Studio versions installed in isolated instances on test machines. If everything goes well, you can then publish your extension on the Visual Studio Marketplace! n
Carlos Quintero has received the Microsoft Most Valuable Professional award 14 times, currently in the category of Visual Studio and Development Technologies. He has been helping other developers to create extensions for Visual Studio since 2002, blogging about it since 2006 at visualstudioextensibility.com and more recently tweeting about it: @VSExtensibility.
thanks to the following technical experts for reviewing this article: Justin Clareburt, Alex Eyler and Mads Kristensen
16 msdn magazine
Visual Studio