PRB: Uninstaller does not remove commands of add-in if uninstalled from another user account

Author: Carlos J. Quintero (Microsoft MVP) Applies to: Microsoft Visual Studio 2005
Date: September 2011   Microsoft Visual Studio 2008
Updated: March 2013   Microsoft Visual Studio 2010
      Microsoft Visual Studio 2012

This article explains a problem that can happen when uninstalling an add-in if it is uninstalled from another user account.

More Information

When a Visual Studio add-in is loaded for the first time, typically it creates its commands, which the add-in should not delete when unloaded because keyboard bindings would be lost. Rather, the uninstaller of the add-in should delete them when the add-in is uninstalled. See the article HOWTO: Removing commands and UI elements during Visual Studio .NET add-in uninstallation.

However, the commands are created for the user account loading the add-in, they are not created for all users (at machine level). In fact, they are persisted in the following file:

  • Windows XP: Windows XP: "C:\Documents and Settings\<user>\Application Data\Microsoft\VisualStudio\<version>\<LCID>\CmdUI.PRF
  • Windows Vista and higher: C:\Users\<user>\AppData\Roaming\Microsoft\VisualStudio\<version>\<LCID>\CmdUI.PRF

where <version> is 8.0 (Visual Studio 2005), 9.0 (Visual Studio 2008), etc. and <LCID> is 1033 for English, 3082 for Spanish, etc.

A Visual Studio add-in can be installed for all users (requiring administrator privileges), or only for the user installing it (not requiring administrator privileges), as explained in the article HOWTO: Design a Visual Studio add-in to install and run on Windows Vista / 7.

Consider these scenarios:

Scenario 1

  • The developer using Visual Studio is not administrator (Visual Studio 2008 and higher doesn't require it, Visual Studio 2005 does).
  • She installs an add-in that is installed for all users, not for the current user. To do it, she must use another user account with administrator privileges.
  • Once installed, since the add-in is installed for all users, she can use the add-in with her user account. At this point the add-in creates its commands in her user profile.
  • She uninstalls the add-in with the user account with administrator privileges.
  • The uninstaller performs a custom action to delete the commands of the add-in with either of these approaches:
    • Executing the command-line devenv.exe /ResetAddin <myaddin> /Command File.Exit
    • Creating an instance of EnvDTE.DTE through automation (ex: CreateObject("VisualStudio.DTE.10.0")), iterating its DTE.Commands, and removing the ones that belong to the add-in.
  • With any approach, the uninstaller only removes the commands of the administrator user account, not the commands of the developer user account.

Some workarounds for this problem are:

  • Design the add-in to install for the current user (not requiring admin rights), so that only one user account is needed to install and use the add-in.
  • Make the user to execute the command-line devenv.exe /ResetAddin <myaddin> /Command File.Exit

Scenario 2

  • The developer using Visual Studio is administrator.
  • She installs an add-in that is installed for all users, so the installer and uninstaller require admin rights.
  • The uninstaller uses the MSI technology, which uses the LocalSystem account to perform actions that require admin rights (that is, it doesn't use the user account, even if it is administrator).
  • When the uninstaller uninstalls the add-in, if it perfoms the custom actions described in the scenario above with admin rights, it doesn't remove the commands of the user account because it is using the LocalSystem account.

Some workarounds for this problem are:

Related articles

Go to the 'Visual Studio Extensibility (VSX)' web site for more articles like this (Articles section)