LoadBehavior Registery Key Changes from 3 to 2

[Chris Newby]

I developed a managed Outlook Add-in using the Visual Studio 2003 Add-In
wizard. This Add-In is deployed *without* a runtime "shim". Essentially this
add-in adds a command bar button to mail item inspector windows. When this
button is clicked, a .Net windows form is opened which contains the actual
application.

Using the installer created by the VS2003 Add-In wizard, I am able to
install this add-in on my pc as well as the pc of all my users. The add-in
appears to work fine, the button shows up and everyone is happy.

But then after what appears to be an indeterministic amount of time the
button stops showing up on Outlook's mail item inspector window.

The add-in does not appear in the disabled items list, nor does it appear
under "Options->Other->Advanced Options->COM Add-Ins". However,
investigating the client registry at this point reveals that the
LoadBehavior registry settings for the add-in has changed from its original
"3" to "2". Manually changing this registry setting back to "3" and
restarting Outlook does not work as Outlook appears to reset the
LoadBehavior back to "2" during application startup.

This occurs on my development PC as well as all of my user PCs. On my
developer PC, the only other add-ins I have installed are NewsGator and MSN
Toolbar.

LoadBehavior is definately "3" when the add-in is initially installed. In
fact, uninstalling and reinstalling the add-in temporarily "fixes" the
issue, that is, the registry setting is "3" and the add-in loads as
expected. But then its just a matter of time (a few days usually) before the
add-in vanishes again.

I suppose there's another registry setting somewhere I'm missing that is
causing Outlook to block the loading of the Add-In?

Also, why and how does Outlook decide to start blocking an add-in in this
particular fashion?

Any other suggestions?

TIA//

[Ken Slovak - [MVP - Outlook]]

Usually an addin is blocked if it crashes Outlook, or Outlook thinks it did.
Some things like Norton's script stopper or scanning incoming/outgoing email
will crash Outlook some times and your addin might be getting blamed for it.

However, it's highly unusual for an addin to be blocked by Outlook and not
to show up in the disabled items list. You can see if there's a registry key
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Resiliency\DisabledItems
and if so delete it. That's how Outlook disables items.

Not being shimmed means your addin shares a global application namespace
with all other .NET addins that aren't shimmed. If one screws up they all
get disabled. That might be what's happening here.

In general you must correctly handle Outlook shut down, releasing all your
Outlook objects when Explorer.Close and/or Inspector.Close fire if there are
no other Inspectors or Explorers. Only then can the OnDisconnection event
fire when Outlook closes. Failure to do so will hang Outlook in memory. You
also must handle all errors and exceptions in your code.

I would first of all after checking those things disable all other addins in
Outlook to make sure your addin isn't getting blamed for another one's
problems.
--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm

Post by Chris Newby
I developed a managed Outlook Add-in using the Visual Studio 2003 Add-In
wizard. This Add-In is deployed *without* a runtime "shim". Essentially
this add-in adds a command bar button to mail item inspector windows. When
this button is clicked, a .Net windows form is opened which contains the
actual application.
Using the installer created by the VS2003 Add-In wizard, I am able to
install this add-in on my pc as well as the pc of all my users. The add-in
appears to work fine, the button shows up and everyone is happy.
But then after what appears to be an indeterministic amount of time the
button stops showing up on Outlook's mail item inspector window.
The add-in does not appear in the disabled items list, nor does it appear
under "Options->Other->Advanced Options->COM Add-Ins". However,
investigating the client registry at this point reveals that the
LoadBehavior registry settings for the add-in has changed from its
original "3" to "2". Manually changing this registry setting back to "3"
and restarting Outlook does not work as Outlook appears to reset the
LoadBehavior back to "2" during application startup.
This occurs on my development PC as well as all of my user PCs. On my
developer PC, the only other add-ins I have installed are NewsGator and
MSN Toolbar.
LoadBehavior is definately "3" when the add-in is initially installed. In
fact, uninstalling and reinstalling the add-in temporarily "fixes" the
issue, that is, the registry setting is "3" and the add-in loads as
expected. But then its just a matter of time (a few days usually) before
the add-in vanishes again.
I suppose there's another registry setting somewhere I'm missing that is
causing Outlook to block the loading of the Add-In?
Also, why and how does Outlook decide to start blocking an add-in in this
particular fashion?
Any other suggestions?
TIA//

[Chris Newby]

Ken thanks very much for the response.

The add-in I currently have installed on my own PC is currently failing to
load. It is not showing up in the diabled items list nor do I see a registry
key called "Resiliency\DisabledItems". What kind of value might I search for
to determine what key(s) my version of Outlook is using? (I'm using 2003
11.8010.6568 SP2).

Also I didn't see any public events on the Inspector interface for handleing
"Close". I did see "Deactivate", is that the same thing?

TIA//

Post by Ken Slovak - [MVP - Outlook]
Usually an addin is blocked if it crashes Outlook, or Outlook thinks it
did. Some things like Norton's script stopper or scanning
incoming/outgoing email will crash Outlook some times and your addin might
be getting blamed for it.
However, it's highly unusual for an addin to be blocked by Outlook and not
to show up in the disabled items list. You can see if there's a registry key
HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Resiliency\DisabledItems
and if so delete it. That's how Outlook disables items.
Not being shimmed means your addin shares a global application namespace
with all other .NET addins that aren't shimmed. If one screws up they all
get disabled. That might be what's happening here.
In general you must correctly handle Outlook shut down, releasing all your
Outlook objects when Explorer.Close and/or Inspector.Close fire if there
are no other Inspectors or Explorers. Only then can the OnDisconnection
event fire when Outlook closes. Failure to do so will hang Outlook in
memory. You also must handle all errors and exceptions in your code.
I would first of all after checking those things disable all other addins
in Outlook to make sure your addin isn't getting blamed for another one's
problems.
--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm

Post by Chris Newby
I developed a managed Outlook Add-in using the Visual Studio 2003 Add-In
wizard. This Add-In is deployed *without* a runtime "shim". Essentially
this add-in adds a command bar button to mail item inspector windows. When
this button is clicked, a .Net windows form is opened which contains the
actual application.
Using the installer created by the VS2003 Add-In wizard, I am able to
install this add-in on my pc as well as the pc of all my users. The
add-in appears to work fine, the button shows up and everyone is happy.
But then after what appears to be an indeterministic amount of time the
button stops showing up on Outlook's mail item inspector window.
The add-in does not appear in the disabled items list, nor does it appear
under "Options->Other->Advanced Options->COM Add-Ins". However,
investigating the client registry at this point reveals that the
LoadBehavior registry settings for the add-in has changed from its
original "3" to "2". Manually changing this registry setting back to "3"
and restarting Outlook does not work as Outlook appears to reset the
LoadBehavior back to "2" during application startup.
This occurs on my development PC as well as all of my user PCs. On my
developer PC, the only other add-ins I have installed are NewsGator and
MSN Toolbar.
LoadBehavior is definately "3" when the add-in is initially installed. In
fact, uninstalling and reinstalling the add-in temporarily "fixes" the
issue, that is, the registry setting is "3" and the add-in loads as
expected. But then its just a matter of time (a few days usually) before
the add-in vanishes again.
I suppose there's another registry setting somewhere I'm missing that is
causing Outlook to block the loading of the Add-In?
Also, why and how does Outlook decide to start blocking an add-in in this
particular fashion?
Any other suggestions?
TIA//

[Ken Slovak - [MVP - Outlook]]

Any version of Outlook that can disable addins uses the same key.

Close is a method of Inspector, as is Deactivate and they are different. You
should see Close or something is wrong.

.NET addins can also be disabled for lots of other reasons. Security is the
primary problem, setting trust and so on. There are also others, such as
wrong framework versions and lack of the proper runtimes but if the problem
is on your own computer I'd be looking at the security settings.
--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm

Post by Chris Newby
Ken thanks very much for the response.
The add-in I currently have installed on my own PC is currently failing to
load. It is not showing up in the diabled items list nor do I see a
registry key called "Resiliency\DisabledItems". What kind of value might I
search for to determine what key(s) my version of Outlook is using? (I'm
using 2003 11.8010.6568 SP2).
Also I didn't see any public events on the Inspector interface for
handleing "Close". I did see "Deactivate", is that the same thing?
TIA//