How to prevent Outlook add-in from being disabled?

[Vidya]

We have an Outlook 2003 addin written in VSTO 2005. We deploy into HKLM so
there is no manual way to disable the addin using Outlook Tools menu. In
production mode, the addin still gets disabled sometimes. We have found out
that one of the ways that user can disable the addin is by killing the
Outlook process while it is still loading. We have implemented ways to make
the addin start up faster and there is not much we can do there.

Are there other ways in which the addin can be disabled? If so, how can we
prevent the addin from being disabled? We implement ThisAddin_Startup and
ThisAddin_Shutdown methods and these are enclosed in try..catch blocks.

Thanks

 

[keremskusmezer]

We had the same problem, therefore we also distribute a signed otm
file with our VSTO Addins For Outlook.

In the Application_Startup Event of the Application object inside our
otm file,
we check the registry entries for particular addins and if the addin
has been disabled , we change the registry settings correspondingly to
the normal state and force a restart in outlook with Application.Quit
command.

Public Function CheckOutlookAddins(SourceApplication As Application)
Dim csfKey As String
csfKey = RegRead(HKEY_CURRENT_USER, "Software\Nowhere\NoWhereAddin",
"CheckReinstall")
If csfKey = "1" Then
On Error GoTo Cleanup
Set generalApplication = SourceApplication
Dim outlookApplication As Application
Set outlookApplication = SourceApplication
Dim correctionResult As Boolean
Dim addinCount As Integer
Dim foundAddin As COMAddIn
addinCount = outlookApplication.COMAddIns.Count
For i = 1 To addinCount
If outlookApplication.COMAddIns(i).Description = CSFDescription
Then
Set foundAddin = outlookApplication.COMAddIns(i)
If Not foundAddin.Connect Then
On Error Resume Next
foundAddin.Connect = True
If Err.Number <> 0 Then
Err.Clear
Set foundAddin = Nothing
End If
On Error GoTo Cleanup
Exit For
Else
Exit For
End If
End If
Next

'Everything Running Fine Exit Loop
If foundAddin Is Nothing Then
Dim processResult As CreationStates
processResult = ProcessRegistryKeys()
Select Case processResult
Case CreationStates.CreationSuccess
If Not CheckOutlookAddinsStandalone(SourceApplication,
False) Then
CheckOutlookAddinsStandalone SourceApplication, True
End If
Case CreationStates.DllIsMissing
MsgBox ("Addin Dlls Missing. Registry Key Will Be
Disabled")
RegWrite HKEY_CURRENT_USER, "Software\Nowhere
\NoWhereAddin", "CheckReinstall", "0"
Exit Function
Case Else
GoTo Cleanup
End Select
Else
CorrectAddinStructure SourceApplication, foundAddin
End If

Exit Function

Cleanup:
Set outlookApplication = Nothing
Set generalApplication = Nothing
Set foundAddin = Nothing
MsgBox GetCurrentLanguageFromParameters & Err.Description
End If
End Function

 

[keremskusmezer]

Do you have Threading Exception Handler or Application Exception
Handler installed?

 

[Ken Slovak - [MVP - Outlook]]

If Outlook has "hard disabled" an addin the only way to get it re-enabled
without the user re-enabling it from the Disabled Items dialog is to delete
the resiliency key in the registry when Outlook is not running or force a
restart. Merely changing the LoadBehavior value is not sufficient. And
deleting the resiliency key is not a good thing since it will also re-enable
any other disabled addins.

In addition, distributing an OTM file is also not the best way to go, that
overwrites any OTM file the user may have. If your code did that to my
Outlook VBA project I'd rip it out and never install it ever again.

You should handle all exceptions and use defensive programming where
possible to avoid any exceptions, that's the way to not get disabled.




We had the same problem, therefore we also distribute a signed otm
file with our VSTO Addins For Outlook.

In the Application_Startup Event of the Application object inside our
otm file,
we check the registry entries for particular addins and if the addin
has been disabled , we change the registry settings correspondingly to
the normal state and force a restart in outlook with Application.Quit
command.

Public Function CheckOutlookAddins(SourceApplication As Application)
Dim csfKey As String
csfKey = RegRead(HKEY_CURRENT_USER, "Software\Nowhere\NoWhereAddin",
"CheckReinstall")
If csfKey = "1" Then
On Error GoTo Cleanup
Set generalApplication = SourceApplication
Dim outlookApplication As Application
Set outlookApplication = SourceApplication
Dim correctionResult As Boolean
Dim addinCount As Integer
Dim foundAddin As COMAddIn
addinCount = outlookApplication.COMAddIns.Count
For i = 1 To addinCount
If outlookApplication.COMAddIns(i).Description = CSFDescription
Then
Set foundAddin = outlookApplication.COMAddIns(i)
If Not foundAddin.Connect Then
On Error Resume Next
foundAddin.Connect = True
If Err.Number <> 0 Then
Err.Clear
Set foundAddin = Nothing
End If
On Error GoTo Cleanup
Exit For
Else
Exit For
End If
End If
Next

'Everything Running Fine Exit Loop
If foundAddin Is Nothing Then
Dim processResult As CreationStates
processResult = ProcessRegistryKeys()
Select Case processResult
Case CreationStates.CreationSuccess
If Not CheckOutlookAddinsStandalone(SourceApplication,
False) Then
CheckOutlookAddinsStandalone SourceApplication, True
End If
Case CreationStates.DllIsMissing
MsgBox ("Addin Dlls Missing. Registry Key Will Be
Disabled")
RegWrite HKEY_CURRENT_USER, "Software\Nowhere
\NoWhereAddin", "CheckReinstall", "0"
Exit Function
Case Else
GoTo Cleanup
End Select
Else
CorrectAddinStructure SourceApplication, foundAddin
End If

Exit Function

Cleanup:
Set outlookApplication = Nothing
Set generalApplication = Nothing
Set foundAddin = Nothing
MsgBox GetCurrentLanguageFromParameters & Err.Description
End If
End Function

 

[Ken Slovak - [MVP - Outlook]]

An addin gets disabled for one of 2 reasons. Either it has unhandled
exceptions, or it's running in the same AppDomain as another application
that has unhandled exceptions.

VSTO takes care of the AppDomain by loading your addin into its own
AppDomain. The rest is your defensive programming to first prevent
exceptions and then to handle any that still might arise.

 

[Vidya]

Thanks Ken. Thats the approach we are trying to follow now (exception
handling in code). We are not able to put try..catch blocks in event handlers
though, especially the ones that have an Execute statement on a button or
menu item. The Execute statement won't run if its within a try..catch block.
Any idea why? Are we missing something?

thanks
vidya

 

[Vidya]

We dont use an otm file but we have a script to reenable the disabled addin
using Windows logon script. This is handled by our system admins. We also
parse the binary value in the resiliency key to read the entry corresponding
to our add-in and delete just that entry. It works. We are also looking into
creating another add-in in Outlook that might simply check for the registry
entry and reenable the original add-in. But these steps are after the fact
and does not prevent the add-in from getting disabled again in the future.

Thanks for your input though.

 

[Vidya]

No, what is this? Where can I get it? I googled, but couldnt find anything.
I have normal exception handling that .NET provides.

thanks

 

[Ken Slovak - [MVP - Outlook]]

I haven't tried calling Execute on a button inside a try...catch block so I
have no idea about that, but in other event handlers you can't do certain
things and the normal workaround is to enable a timer and set a flag at the
end of the event handler code. When the timer fires it's disabled and the
flag checked and if set you then call the code you want, in your case the
Execute call. That might work for you.

 

[Ken Slovak - [MVP - Outlook]]

I'm not sure exactly what events Kerem was referring to but I usually put
one or two general event handlers like that into my code as catch-alls.

One I use is AppDomain.CurrentDomain.UnhandledException(). The other if I'm
doing a lot of thread manipulation is to add a
System.Threading.ThreadExceptionEventHandler() to my code.

 

[keremskusmezer]

I'm not sure exactly what events Kerem was referring to but I usually put
one or two general event handlers like that into my code as catch-alls.

One I use is AppDomain.CurrentDomain.UnhandledException(). The other if I'm
doing a lot of thread manipulation is to add a
System.Threading.ThreadExceptionEventHandler() to my code.










- Show quoted text -

AddHandler System.AppDomain.CurrentDomain.UnhandledException,
AddressOf HandleUnHandledExceptions
AddHandler System.Windows.Forms.Application.ThreadException, AddressOf
HandleUnHandledExceptions

I am also refering to the same events

 

[Vidya]

Ken,
We are trying to add these two event handlers in our outlook addin. Our
addin doesnt have any UI, except for some message boxes. It traps attachment
events and Send events and does some validation on attachments. We were
trying to put those event handlers in ThisAddin_Startup. ThreadException
handler doesnt seem to work in this. The unhandled exception handler does.
Does it sound right? We also have a background processing thread that does
not access any OOM stuff. How do we catch exceptions from a background
thread? (we have some try..catch)

Thanks
Vidya

 

[Ken Slovak - [MVP - Outlook]]

I don't know if VSTO is preventing that or does its own thread handling
exceptions. I wouldn't worry about it at this time unless you find your
existing exception handlers aren't sufficient.