Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

Registering and Unregistering a VSIX Extension from the Command Line


:P
On this page:

vsixI've looked this up and hunted around for vague descriptions enough times that I'm finally writing down how to programmatically install VSIX extensions using the VSIX installer.

Problems with Installing a VSIX Interactively

To install interactively a VSIX extension, you can simply execute the .vsix file from Windows Explorer or even the Command Window as well as using a Shell Commands for launching programmatically  as .vsix is registered and automapped to the VSIXInstaller. Originally as part of an application I ship with a VSIX I simply used ShellExecute() to launch the installer.

This works, but it's very limited because:

  • The VISX always launches interactively
  • If the VSIX is already installed you get an error
  • No way to uninstall other than through Visual Studio

Using the VSIXInstaller

If you want to install and uninstall a VSIX extensions programmatically as part of an install script, you can use the VSIXInstaller.exe that is installed into the Visual Studio IDE folder. This file lives in:

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\VSIXInstaller.exe

and you can use it to both install and uninstall .vsix extensions with a bit more control than running the interactive installer.

Installing

Installing a VSIX is as easy as calling the installer with the full path to the .vsix file:

VSIXInstaller.exe /a "c:\webconnection\visualstudio\WebConnection-addin.vsix"

This simply runs the installation interactively bringing up the dialog and prompt from the user. If you'd rather just install the extension you can use the /q command switch which disables all prompts and simply installs.

The /a flag installs the VSIX in the admin area of Visual Studio - not quite sure what that means and I didn't see any real difference when I left it out – but all samples I've seen use it.

VSIXInstaller.exe /a /q "c:\webconnection\visualstudio\WebConnection-addin.vsix"

This does not solve the problem of updates however – if the extension is already installed, a new one is not automatically installed and the install fails. When the /q  switch is a failure fails quietly.

Since you can't update with the install step and there's no explicit update option, you have to effectively uninstall and reinstall the add-in.

Uninstall

You can use the VSIX installer to uninstall an extension. In order to do this you need to know the Identifier which is a generated ID that gets stored in the VSIX manifest file. To find the identifier you can unzip your VSIX file (it's just a renamed .zip file) and look in the manifest file and there should be a Identifier key like this one:

<Identity Id="WebConnection_Addin.Rick Strahl.7c985797-3089-440a-a54c-b0125720263d"
                 Version="1.02.3" Language="en-US" Publisher="Rick Strahl" />

The ID is what you need as the identifier when you run the

vsixinstaller  /q /a /u:"WebConnection_Addin.Rick Strahl.7c985797-3089-440a-a54c-b0125720263d"

VSIX InstallerCommands

BTW, if you want to see all the options of the VSIX installer just run it without a commandline which pops up a messagebox with option flags. The full syntax is:

VSIXInstaller.exe [/quiet] [/norepair] [/admin] [/skuName:name /skuVersion:version] [/logFile:filename] </uninstall:vsixID | vsix_path>

all command options shortcut by first letter. The key one are /q which disables all UI and quietly fails if it doesn't work which is great for scripted installs and /u to uninstall.

I'm not sure what the /admin switch does – I think it has something to do with where the extension registers. The main thing with this switch is be consistent in using the same switch for install and uninstall. Also not quite sure about the /norepair option which seems to indicate that if not specified will update the addin. I haven't seen this work – in my tests the installer always fails when installing and the add-in exists already.

Updating an Extension

So, since there is no update support how do you update an extension?

In my particular application users frequently update the application and as part of the installer I need to Update the Visual Studio Extension (an Add-in) I provide. As far as I can tell the VSIX installer doesn't allow for updates – it fails if the extension is already installed. So the only way to update an extension is to uninstall it then reinstall it. You can just run the two commands successively and allow some time inbetween. If you use the /q switch both install and uninstall process are pretty quick.

In my old application the install script does something like this:

lcVsVersion = "14.0"
IF (lcVersion > "2014")
lcinstaller =  GetSpecialFolder(0x0026) + "Microsoft Visual Studio " + pcVsVersion + "\Common7\IDE\vsixinstaller.exe" 
IF FILE(lcInstaller)
    WAIT WINDOW "Uninstalling Visual Studio " + lcVsVersion + " Add-in..." nowait
    CreateProcess(lcInstaller,[/q /a /u:"WebConnection_Addin.Rick Strahl.7c985797-3089-440a-a54c-b0125720263d"],,.T.,5000)
    WAIT WINDOW "Installing Visual Studio " + pcVsVersion + " Add-in ..." nowait
    CreateProcess(lcInstaller,[/q "] + FULLPATH("VisualStudio\WebConnection-Addin.vsix") + ["])
    WAIT clear
ENDIF    

which uses options on CreateProcess to wait for completion of the process before running the next operation.

In .NET you can use Process.WaitForExit() to wait for Process completion before moving on:

var process = Process.Start(...);
process.WaitForExit();

Extension Location

Just as an aside, extensions installed end up the AppData Visual Studio configuration either in Local (as shown) or Roaming profile depending on how your network environment is set up. The folder is a random file name generated by the installer:

ExtensionsFolder

Note that you can effectively uninstall an extension simply by removing the folder which is kind of nice to know, but it might take a little sleuthing to find the right folder since the folder name doesn't match any id associated with your add-in.

Summary

Visual Studio's infrastructure remains a big pain when it comes to administering features. The biggest problem is a lack of decent documentation around this topic. But, it's getting better. I recently had to ugprade an old VS 2005 created add-in to the new VSIX model, and the process is loads and loads easier than it used to be – especially all the fanfare around hooking up menu options. But there's still a lot of ways to go to make add-ins easier to author and manage.

I hope this is helpful for some of you. I know I'll be referring back to this page frequently myself.

Posted in Visual Studio  

The Voices of Reason


 

Mads Kristensen
March 01, 2016

# re: Registering and Unregistering a VSIX Extension from the Command Line

Thanks for writing the post. We need more posts and articles about Visual Studio extensibility. If you haven't already seen it, then take a look at Extensibility Tools 2015 which makes it a lot easier to write VSIXs https://visualstudiogallery.msdn.microsoft.com/ab39a092-1343-46e2-b0f1-6a3f91155aa6

hannes cmarits
May 12, 2017

# re: Registering and Unregistering a VSIX Extension from the Command Line

Cool aritcle! Thanks for sharing. The update problem should be solved by increasing the version number.


Rick Strahl
May 12, 2017

# re: Registering and Unregistering a VSIX Extension from the Command Line

@hannes - yup, but that doesn't always work. In my case I have a dev tool that installs an extension and you can uninstall the tool independently of the addin. Now if the user uninstalls my tool, then reinstalls and the addin hasn't rev'ed it fails which is sad. The installer should be smart enough to either detect that the component is already there with the same version and just silently go on or otherwise provide a silent fail option in that can be trapped somehow, but neither is available.


Manjeet Singh
May 19, 2017

# re: Registering and Unregistering a VSIX Extension from the Command Line

Is there an option to detect if an extension is already installed? If we pass the uninstall flag, and the extension is not installed already, it will throw an exception / installer will fail


Yair Ofer
June 14, 2017

# re: Registering and Unregistering a VSIX Extension from the Command Line

This was VERY helpful. thanks !!! Two things I think I can add: The 1st is an observation regarding the /a flag In my tests I saw that the files are dumped in 2 different places if the flag is used or not with /a the files are placed in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions without /a the files are placed in C:\Users\Administrator\AppData\Local\Microsoft\VisualStudio\14.0\Extensions

The 2nd is that if you uninstall from command line, the files are not removed from the file system until you actually run Visual Studio


Phil Miller
June 16, 2017

# re: Registering and Unregistering a VSIX Extension from the Command Line

The /a option installs the extension as an administrative-user extension, making that extension available to all users. I found this useful if you have a standard image for your developers - you can have your IS team install with this switch to make the extension available for anyone.

Link to a MS article that sheds some light on this: https://msdn.microsoft.com/en-us/library/ee814429(v=vs.100).aspx


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024