| 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 |
Introduction
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)
|
