Carlos Quintero (Microsoft MVP) blog

Visual Studio Extensibility with Add-ins

The strange case of no ext_ConnectMode.ext_cm_UISetup phase fired, not even once

Continuing today with some tests about the The OnConnection method and ext_ConnectMode.ext_cm_UISetup of Visual Studio add-ins of my last post, I created a sample add-in using the code of the first sample (temporary UI) of my article HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in, and later I changed my mind to use the ext_ConnectMode.ext_cm_UISetup phase using the second sample. To my surprise, the ext_ConnectMode.ext_cm_UISetup phase was never fired, not even once, despite the fact that debugging the add-in should fire it each time because of the /resetaddin command-line flag in the Start Options of the Debug tab of the project properties window.

Opening a command prompt window to use devenv.exe /resetaddin MyAddin.Connect caused no effect too. So, I started to get paranoid about the VS 2008 SP1 that I installed some weeks ago. Could it be possible that it broke the behavior somehow? Unfortunately no, the cause was other: in order to Visual Studio calls the OnConnection method of your add-in with the ext_ConnectMode.ext_cm_UISetup phase, your add-in registration must specify that it wants "CommandPreload", a flag in the registry (COM registration) or tag in the .AddIn file (XML registration). Otherwise Visual Studio doesn't bother to load add-ins that haven't requested the ext_ConnectMode.ext_cm_UISetup phase. When you use the add-in wizard to create an add-in project, the page 4 of 6 has a checkbox:

"Yes, create a "Tools" menu item. By default this will cause the Add-in to load when the button is clicked unless the Add-in is set to load on startup of the host application."

that you must check for the wizard to set that "CommandPreload" flag. I totally forgot this flag and it happens that since I always delete the whole code of the Connect class generated by the add-in wizard because I don't like the code that it creates, most of the time I don't bother to check that checkbox to delete less code... so, if you change your mind about whether you want ext_ConnectMode.ext_cm_UISetup phase or not in your add-in, it is not enough to change the code of your OnConnection method, you need to pay attention to that flag, either to get the ext_ConnectMode.ext_cm_UISetup phase, or to optimize your add-in preventing to load it for a phase that it won't use...

Published Tue, Oct 14 2008 5:14 by carlosq

Comments

# re: The strange case of no ext_ConnectMode.ext_cm_UISetup phase fired, not even once@ Tuesday, October 14, 2008 11:11 AM

One question: Is it not same as specifying <CommandPreload>1</CommandPreload> in .AddIn file? I guess, even if you forget to check the check box, you can specify 1 here (in .AddIn file). I have not tested though.

Thanks.

by Utkarsh

# re: The strange case of no ext_ConnectMode.ext_cm_UISetup phase fired, not even once@ Tuesday, October 14, 2008 3:55 PM

Yes, you can add that XML tag in the .AddIn file without running the add-in wizard to create a new project, I'm sorry if I was not clear about that.

by carlosq

# Visual Studio Links #78@ Thursday, October 16, 2008 7:36 AM

My latest in a series of the weekly, or more often, summary of interesting links I come across related to Visual Studio. Channel 9 Stuff: Anders Hejlsberg and Guy Steele- Concurrency and Language Design The Concurrency Runtime- Fine Grained Parallelism

# Registry path clarification@ Monday, February 16, 2009 12:37 AM

I've spent whole day trying to understand why CommandPreload value in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Addins\MyAddin.Connect" does not work.

There is another key defining wheither fire ext_cm_UISetup or not! And it's defined for every user on the system:

"HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\PreloadAddinState"

Either delete value with your plugin name, or set it to 1, and you'll get your UISetup phase!

Leave a Comment

(required) 
(required) 
(optional)
(required)