Home Dashboard Directory Help
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 Carlos J. Quintero


Status: 

Closed
 as Fixed Help for as Fixed


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

Description

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
Sign in to post a comment.
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.
Posted by Carlos J. Quintero 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/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 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
Sign in to post a workaround.