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

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

On Jul 21, 11:09*pm, Vidya wrote:
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

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

On Jul 21, 11:09*pm, Vidya wrote:
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

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


wrote in message
...
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

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Vidya" wrote in message
...
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

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

"Ken Slovak - [MVP - Outlook]" wrote:

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


wrote in message
...
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

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.

" wrote:

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

On Jul 21, 11:09 pm, Vidya wrote:
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

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

thanks

" wrote:

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

On Jul 21, 11:09 pm, Vidya wrote:
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

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]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Vidya" wrote in message
...
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

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Vidya" wrote in message
...

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

thanks

" wrote:

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