The final change we need is a small tweak to the .csproj so that F5 works out of the box. This is done by adding the appropriate start action to the .csproj to run devenv under a different registry hive. Visual Studio generates this information in new VSIX projects but it does so in the .csproj.user file. Virtually every source code control system excludes this file by default hence it will work until you clone the source onto a new machine. By putting this directly in the .csproj file we ensure F5 will work for anyone who clones our source code
In this change we deploy the reference assemblies which are needed to build the RoundTripVSIX project. These are the reference assemblies from a 2010 installation. All versions of Visual Studio beyond 2010 have appropriate binding redirects for these values in the devenv.exe.config file. Hence our extension will load just fine if it references these. This is generally true for any assembly that Visual Studio includes in the SDK The only change necessary to the project is to include this directory in the reference search path.
The RoundTripVSIX project can now be edited in a variety of Visual Studio environments. Each of these environments want to provide different versions of the SDK references we are using. It's important to guarantee that we are always using the reference assemblies shipped with Visual Studio 2010. These are fully supported when loaded in newer versions (via redirects in devenv.exe.config). Also all of the newer references are bound to newer versions of the .Net Framework. The RoundTripVSIX project will always target 4.0 hence even if the new ones are bound to we can't reference them. With this change we can now build the extension in any version of Visual Studio so long as the 2010 SDK is installed on the machine. That's still pretty limiting though because the SDK requires a full Visual Studio install to work. The next commit will fix by deploying reference assemblies with the source
This change will allow the RoundTripVSIX project to be loaded in any version of Visual Studio. This will be done without Visual Studio attempting to upgrade the project. The change really consists of two parts. The first is the setting of the MinimumVisualStudioVersion. This needs to be done once per version of Visual Studio beyond 2010. The MinimumVisualStudioVersion property doesn't affect the build in any meaningful way that I'm aware of. But the upgrade wizard does look for this when deciding whether or not an upgrade is required. The second change is to choose the SDK targets file based on the current version of Visual Studio. This is done by keying off the $(VisualStudioVersion) property to build up the $(VsSdkTargets) property. The name of this property isn't important (other than choosing one that Visual Studio isn't using). The import of the SDK is then switched to use this variable and be conditional on the SDK existing. The Conditional attribute is a must have here. If it is missing the upgrade wizard will flag this project for needing an upgrade There are still several problems with the project though. In particular it still identifies the Visual Studio assemblies it references by a non-strong name. This means a build in 2012 will bind to the 2012 version of the assemblies. These are built for the 4.5 framework and hence can't be used in a 4.0 project. This will result in a lot of build errors. It also has other problems building if the 2010 SDK isn't installed. The next commit will begin to take care of these problems
The first change we will make is to enable the deployment of this extension to any version of Visual Studio. This is a relatively simple process of updating the manifest to include the new versions of Visual Studio in the SupprotedProducts section. Once this change is added and the project rebuilt the resulting VSIX can be installed on any version of Visual Studio A quick note on Visual Studio versions 2010 = 10.0 2012 = 11.0 2013 = 12.0
This is a vanilla 2010 VSIX extension. It was created with the project wizard using the "Editor Margin" extension. At this point the VSIX is completely tied to Visual Studio 2010. It can only be edited in and deployed to that version. Any attempt to open this project in 2012 or 2013 will be met with a forced upgrade dialog. Installing to either of these will also fail. Over the next few edits this project will be updated such that it can be edited in and deployed to any version of Visual Studio