Answering a question in the MSDN VSX forum today, I have learned another change caused by the new VSIX installer (VSIXInstaller.exe) of Visual Studio 2017 that it is worth documenting here.
As you know, in Visual Studio 2015 only one edition (Community, Professional or Enterprise) could be installed on the same machine. Two or more editions couldn’t coexist at the same time. Given that the Enterprise edition includes the features of the Professional edition and that the Community edition is basically the Professional Edition (without some feature such as CodeLens), the VSIX manifest of your extension could target the “Pro” edition and as such it would be installable on any edition (Community, Professional or Enterprise):
Normally a .VSIX file is installed just double-clicking it, so that the VSIXInstaller.exe application is launched. But if you want to install an extension programatically, the VSIXInstaller.exe application offers a few command-line switches:
Notice the /skuName:<name> option: it allows to specify the exact edition (Enterprise, Premium, Pro, Community, etc.) of Visual Studio where you want to install the extension. Which value you would need to use? It happens that for Visual Studio 2015, you can use “Pro” and the extension will be installed happily not only on Visual Studio 2015 Professional, but also on Visual Studio 2015 Community or (Updated March 1, see comments section) Visual Studio 2015 Enterprise. For example, installing my MZ-Tools extension on Visual Studio 2015 Enterprise edition with this command line works perfectly:
vsixinstaller.exe /skuName:Pro /skuVersion:14.0 “<path>\MZTools8VSPackage.vsix”
(notice that it recognizes my Enterprise edition as Professional edition).
However, the same is not true for VS 2017. Using this command line to install it on my Visual Studio 2017 Enterprise edition:
vsixinstaller.exe /skuName:Pro /skuVersion:15.0 “<path>\MZTools8VSPackage.vsix”
causes this error:
The following command-line is required, targeting specifically the Enterprise edition:
vsixinstaller.exe /skuName:Enterprise /skuVersion:15.0 “<path>\MZTools8VSPackage.vsix”
So, this is another implication of the new modular setup of Visual Studio 2017 for VSX developers. You can query the installed VS 2017 editions with a new Setup API (sample included).
Hi Carlos,
I think you will actually not be able to install the extension in VS2015 Community with the /skuName:Pro. In VS2015 the “universal” sku value is Community. The /skuName:Pro will work with all previous VS versions instances though. 🙂
Regards,
Momchil
Fixed, thanks!
Hi Carlos,
A small question – I realized that location of vsixinstaller.exe is also important to install extensions programatically. Typically, VS 2013’s vsixinstaller.exe will not show VS 2015 as an environment on vsix file.
So till VS 2015, I used to look for environment variable VS140COMNTOOLS – which will use VS 2015’s vsixinstaller.exe to install extension on VS 2015 or lower) , VS120COMNTOOLS – to install extension on VS 2013 or lower and so on..
Now, with VS 2017, how will that shape out considering there is no such environment variable. Shall I just do a file look up o n hard coded path for VS 2017 vsixinstaller.exe?
See VSIX Installer Bootstrapper: Sample code and utilities to get installed Visual Studio 2017 editions programmatically
Thanks Carlos – this worked 🙂
Another issue I am facing is in detecting if an extension is already installed on VS 2017. I am working on a custom installer which provides options to install / install for all users and uninstall the extension. Uninstall option is enabled only when the custom installer detects if extension is installed on any VS IDE available on user’s machine. This detection is done using Microsoft.VisualStudio.ExtensionManager.dll’s IInstalledExtension interface.
But this dll and interface seems to be changed in VS 2017. So the detection logic is failing to detect if the extension is already installed on VS 2017
Please suggest if there is a way to detect if an extension is already installed on VS 2017
Hi,
I am not familiar with changes in the IInstalledExtension interface.
Try posting on MSDN forum (https://social.msdn.microsoft.com/Forums/vstudio/en-US/home?forum=vsx) and https://gitter.im/Microsoft/extendvs
Thanks for pointing me to the correct forum. I appreciate this
Carlos, can you take a look at my question at https://social.msdn.microsoft.com/Forums/vstudio/en-US/dc8ba70b-0faf-4a16-96a4-1c57dac3e7a7/cant-get-olemenucommandservice-asynchronously-when-implementing-iasyncloadablepackageinitialize?forum=vsx please! This time stuck with Visual Studio 2019 support!
Hi,
Is there any way by which Productivity Power Tools 2017/19 can be installed in for all users, i.e. in some where in common folder not in user profiles?