Visual Studio 2017 seems to have changed a lot of things in the extensibility area
https://docs.microsoft.com/en-us/visualstudio/extensibility/breaking-changes-2017
The previous recommendations regarding installing a VSIX from an MSI now seem obsolete (Deploying VSIX using MSI installer), but there seems to no information about how to do it now.
The VS2017 FAQ implies the VSIX installer can (should?) be kicked off manually, is this the recommender approach now?
vsixinstaller.exe /q /appidinstallpath:"c:\program files
(x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe"
/appidname:"Visual Studio" /logFile:
/skuName:Enterprise /skuVersion:15.0.25810.0
"KendoUI.Mvc.VSPackage.vsix"
It also requires that you know the path to vsixinstaller.exe. Where does this come from? (Update it seems the MS tool vsixbootstrapper will find vsixinstaller.exe and pass through your arguments to it, so no need to locate it directly).
Also you need to know all the versions of visual studio installed, which looks more complicated than it should be Programmatically finding the VS2017 installation directory.
Am I missing something or is this just really complicated now?
It's just really complicated now. Installing an extension can trigger VS Setup to install required workloads, which fails when both are happening via MSI. There's been discussion about how to make it work for WiX and the conclusion is that it's not possible to make it work safely without a change to how VSIXInstaller.exe works: http://lists.wixtoolset.org/pipermail/wix-devs-wixtoolset.org/2017-February/thread.html.
After some research I think currently we have these options:
- splitting the installation workload between the VS extension stuff and everything else: The extension goes into the Marketplace and is installed from within Visual Studio. It looks like this is the scheme MS is pushing everyone to. All the other stuff from your old MSI which cannot go into the extension must be deployed in some other ways, still. You could go ahead and implement some checks in your extension code to test if the other stuff is installed and lead the user to the MSI in case something is missing. This scheme is now used by the WIX tools themself in order to install their VS extension (from the gallery... uh: Marketplace). And still, the user must install an MSI separately...
- Use a custom method (custom action or the like) to locate the latest VS version / instance found. Use the corresponding VSIXInstaller.exe to install the extension from your MSI. Basically, this corresponds to the old fashioned way, as we loved it for years. Keep the following notes in mind, though: a) the VSExtension.VSIXPackage element in WIX is rather useless now: it does not detect the latest VS2017 instance (for some reasonable but not necessarily sufficient reasons, IMO). b) your extension should have the "Visual Studio core editor" as the only prerequisite. Bascially, it may depend on everything which is already installed at the time the VSIXInstaller is triggered. Otherwise, the installation will fail because of the reasons listed in Bob Arnsons answer. c) the VSIX installer now fails in quiet mode if some VS processes are (still) running. Make sure to have them all closed or run the VSIXInstaller in GUI mode to give the user the chance to wait for / exit them manually.
- Use VSIXBootstrapper.exe: the tool detects the latest VS version and uses its VSIXInstaller.exe in order to install into all instances found. However, the above problems remain so that the tool must not be triggered from an MSI but from a bootstrapper itself, in order to be free about your prerequisites! A sample WIX code is provided on the tools github page. Since with this approach the extension is installed by an
<ExePackage> you will have to think about a new strategy for uninstallment.
- Installing your extension the long and windy way. This includes:
- detecting all instances of Visual Studio: for all VS versions prior to 15 there are fixed registry entries, for 15 and up there is a COM API to query the instances from a custom action or custom install script.
- copy all required binaries into the (instance version specific) folders and
- perform respective registration into the Visual Studio instances.
I haven't looked deeper into option 4. For us option 3 was suficcient. VSIXInstaller provides some useful new command line switches, like /p /sp /f etc. which kind of allow one to perform the install in "quite" mode. This, of course, will fail if a required prerequisite is absent or if a blocking process cannot be shut down. Or when applied to an older VSIX installer (important for multi-instance installers!).
Note further, that VSIXInstaller.exe for VS2017 blocks also waiting for MSBuild to shut down. Our build scripts were testing the newly created installer ... which no longer works, sadly.
