| Author: |
Carlos J. Quintero (Microsoft MVP) |
Applies to: |
Microsoft Visual Studio 2005 |
| Date: |
April 2008 |
|
Microsoft Visual Studio 2008 |
| |
|
|
|
Introduction
This article explains some considerations to take into account while designing
and creating a Visual Studio add-in to be run on Windows Vista.
While on Windows XP by default every user is an administrator (although you can
create "standard" users) Windows Vista introduces a new feature named User
Account Control (UAC) which causes that by default even administrators run as
standard users. When they perform some action that requires admin rights (such
as modifying a file in the folder C:\Program Files or writing to the HKEY_LOCAL_MACHINE hive), the
operating system prompts for an "elevation prompt" if the application was designed so
(otherwise the application fails with the "Access denied" error or the calls are performed against a virtualized file system or registry if the administrator configured it so). Since most
developers are administrators and add-ins are intended for developers, it
could be that your add-in worked on Windows XP but it doesn't work on Windows
Vista.
You can learn more about the UAC feature in the following pages:
Understanding and Configuring User Account Control in Windows Vista
UAC: Standard
User Changes
More Information
To make your add-in work fine on Windows Vista you should follow these design decisions:
1) The installer
- If your software is commercial, most customers will expect to be able to
install it in the C:\Program Files folder. Since this requires admin rights,
your setup must check for admin rights before executing.
- Since it will be more common in the future that organizations don't allow their
developers to be administrators as they don't allow IT workers (developer tools are evolving to not require admin rights), chances will be that the person installing the
software (an IT administrator) and the person using it (the developer) will be
different. So, the add-in must be installed for all users (not for the
current user). Otherwise, once the administrator logs off and the developer
logs in, he won't see the add-in in Visual Studio.
The most suitable folder to install the XML .AddIn registration file for all
users is:
-
Windows XP: "C:\Documents and Settings\All Users\Application
Data\Microsoft\VisualStudio\8.0\Addins" (9.0 for Visual Studio 2008)
-
Windows Vista: "C:\ProgramData\Microsoft\VisualStudio\8.0\Addins"
(9.0 for Visual Studio 2008)
Note: do NOT hardcode those locations since they can change for each
operating system.
Your setup can use CSIDL_COMMON_APPDATA to retrieve the "Application Data"
or "ProgramData"
folder and then concatenate the remaining string ("Microsoft\VisualStudio\"). See the article
INFO: Default .AddIn file locations for Visual Studio
add-ins.
- Only violate the previous rules allowing the add-in to install without
admin rights and for the current user if your software is not commercial. Notice
that without admin rights, the software can be installed only in some folder of
the user (such as C:\Users\<user> on Windows Vista), which would be weird for a
commercial product.
- Configure the add-in to load on startup (when Visual Studio is loaded) in the
XML .AddIn registration file (LoadBehavior tag with the value 3) because since
this file is in a restricted folder (for all users), the developer will not be able to change it
and chances are that he will want the add-in loaded on startup. This has two
implications:
- The add-in is loaded on startup for all the developers that
share the computer: in most cases the computer is not shared, but if not,
chances are that all developers will want or need the add-in loaded on startup.
- The developer, lacking admin rights, cannot change that setting. If some time
he needs to run Visual Studio without the add-in (to diagnose a problem or
similar), Visual Studio 2005 and higher allows to hold the Shift key while the
IDE is loaded to not load add-ins. Furthermore, Visual Studio 2008 allows to use
the devenv.exe /SafeMode command-line switch to not load add-ins or packages (in Visual
Studio 2005 this command-line switch only disables packages, not add-ins).
2) The add-in
- The add-in should not require admin rights at all, it should not issue
elevation prompts and it should not require virtualized file systems or registry
stores.
- Do not store settings that must be writable in the installation folder
(C:\Program Files). Use a per-user folder such as:
-
Windows XP: "C:\Documents and Settings\<user>\Application Data\"
-
Windows Vista: "C:\Users\<user>\Roaming"
Note: do NOT hardcode those locations since they can change for each
operating system.
Your setup can use CSIDL_APPDATA to retrieve it.
You can provide initial settings in the installation folder and make your add-in
to copy them to the per-user folder when it is loaded if they don't exist there
already.
- Do not store settings that must be writable in the HKEY_LOCAL_MACHINE hive.
While your installer can write there settings common for all users, the
add-in should use the HKEY_CURRENT_USER hive instead to write per-user settings.
- As long as you follow the last two rules, you won't get "Access denied" errors,
you won't need elevation prompts or virtualized file systems or registry stores.
Related articles
Go back to the 'Resources for Visual Studio .NET extensibility' section for more articles like this
You can code, design, locate code and document your apps much faster using VB.NET, C#, C++ or Visual J#:  
|
