Search

Standard user unable to load/unload COM-based add-ins registered for all users with the VS 2008 Add-in Manager on Windows Vista by MVP CarlosQ

Closed
as Fixed Help for as Fixed

0
Sign in to vote
0
Sign in to vote
Sign in
 to vote
Type: Bug
ID: 365846
Opened: 9/3/2008 12:32:55 AM
Access Restriction: Public
0
Workaround(s)
0
User(s) can reproduce this bug
In the following circumstances:

- Windows Vista with UAC activated
- VS 2008 SP1 runs as standard user even if you are an administrator (the default, you would have to use the "Run As Administrator" context menu otherwise)
- COM-based add-in (not .AddIn XML-based add-in)
- Add-in registered for all users (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Addins)
- When the standard user tries to load such add-in not marked to load on startup through the Add-In Manager, it doesn't load and if you go back to the Add-In Manager the checkbox is still unchecked.
- When the user tries to unload such add-in marked to load on startup through the Add-In Manager, it doesn't unload and if you go back to the Add-In Manager the checkbox is still checked.

That doesn't happen for .AddIn XML-based add-ins registered for all users, only for COM-based add-ins registered for all users.
Details (expand)
Product Language
English

Version

Visual Studio 2008 Service Pack 1
Operating System
Windows Vista
Operating System Language
English
Steps to Reproduce
- Create a COM-based add-in for VS 2008 SP1 on Windows Vista. The add-in doesn't need to create commands or buttons, we will only need to check the behaviour of the Add-In Manager.
- Build it and register it for COM (regasm.exe /codebase myaddin.dll)
- Register it for all-users using the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Addins. Do NOT use an AddIn XML file.
- Open VS 2008 SP1. Notice that by default VS is run without an elevation prompt, as a standard user.
- Go to the Tools, Add-In Manager and check that the add-in appears registered.
- Click the first column to load the add-in if you marked not to load it on startup, or to unload it if you marked it to load on startup
Actual Results
- If you go back to the Add-In Manager, the state (loaded/unloaded) of the add-in has not changed.
Expected Results
- The add-in should load/unload as requested, as happens correctly with .AddIn XML-based add-ins registered for all users.

Notice that while a standard user (not admin) is unable to change the Load on Startup checkbox of add-ins registered for all users since is a machine-wide change and therefore the checkbox is disabled in such circumstance, IT IS OK for him to load/unload add-ins even lacking admin rights, and in fact it works for .AddIn XML-based add-ins registered for all users.
TAP Code (if applicable)
 
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey. [Details]

 

File Attachments
0 attachments
Sign in to post a comment.
Posted by Microsoft on 9/3/2008 at 9:06 PM
Thanks for your feedback. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Posted by Microsoft on 6/4/2009 at 5:30 PM
Hi Carlos,

Thanks again for bringing this to our attention. We did some debugging and discussed the scenarios and basically, when VS decided to move to not require admin priviledges to launch and run, we remove the ability to register global objects.

If you run VS as an admin, then you can still have that ability and it will function like it did back in VS 2005.

We evaluated this and have concluded that this behavior is by design.

(Feel free to continue this discussion on the VSX discussion alias if you want to chat more)

-Quan
Posted by MVP CarlosQ on 6/8/2009 at 10:42 PM
FWIW, I think that the problem happens because with COM add-ins Visual Studio tries to store the state of the add-in (loaded/unloaded) in the LoadBehavior registry entry: if the add-in is marked to load on startup (value 1), when the add-in is loaded the value is changed to 3 and when it is unloaded it changes back to 1. When the COM add-in is registered for all users (using the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\m.n\Addins) this value change works as long as VS is running as admin (which was the case until VS 2008). However, since VS 2008 runs as a standard user by default, it fails to change the value and it seems this failure is not ignored and VS 2008 fails to load/unload the add-in.

Notice that:

- The LoadBehavior value should be used only to store the load behavior of the add-in (as the name implies!), which can be a behavior for all-users or for the current user (depending on the kind of registration of the add-in).

- The LoadBehavior value should NOT be used to store the load/unload state of the add-in. Apart from the semantics of the names (a separate LoadState value would be appropriate), the state of the add-in is a per-user setting (the add-in can be loaded in VS for a user session, and unloaded for the session of another user on the same computer). Being a per-user setting, it should not use the HKEY_LOCAL_MACHINE hive.

And after all, maybe it is not needed to store the load/unload state of the add-in anywhere: for example, if VS crashes the value is not reverted and the next time that VS is loaded, it may think that it is already loaded.

And finally, I have not tested it, but I am quite sure that if the add-in uses XML-registration Visual Studio does NOT try to change the LoadBehavior value in the XML file when the add-in is loaded/unloaded, because when the file is located in one folder for all users (which would require admin rights to modify), VS 2008 succeeds loading/unloading the add-in even with a standard user (which means that it doesn't try to modify the value, or at least that it ignores the failure but loads/unloads the add-in anyway).

I hope this helps.
Posted by Microsoft on 6/19/2009 at 8:35 AM
Hi,
Thank you for reporting this.
We're investigating this issue and will try to provide a fix for Beta 2.
© 2010 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement