Programmatically enable Add-ins

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I would like to know how to enable Add-ins programmatically when Outlook
crashes for some reason.I tried two ways of doing it, but invain.

I tried a way by deleting the registry entries under
HKCU\Software\Microsoft\Office\11.0\Resiliency, but this requires to restart
the Outlook for addin to be enabled manually.

Other way is I tried to handle the issue in
IDTExtensibility::OnBeginShutdown() method, but when Outlook crashes the
control does not come here.So i cannot handle it here.
Are there any other ways to handle this issue ?

Thanks
Balaji
 
If the addin has been disabled by Outlook there isn't any other way.
 
Maybe you can program to delete the extend.dat file located in C:\Documents
and Settings\username\Local Settings\Application Data\Microsoft\Outlook .
 
That won't help. That merely will cause Outlook to rebuild its list of
Exchange extensions and has nothing to do at all with COM addins.
 
balaji chandan said:
I would like to know how to enable Add-ins programmatically when Outlook
crashes for some reason.I tried two ways of doing it, but invain.

I tried a way by deleting the registry entries under
HKCU\Software\Microsoft\Office\11.0\Resiliency, but this requires to
restart
the Outlook for addin to be enabled manually.

Other way is I tried to handle the issue in
IDTExtensibility::OnBeginShutdown() method, but when Outlook crashes the
control does not come here.So i cannot handle it here.
Are there any other ways to handle this issue ?

The question you should be asking yourself is, what is your AddIn doing to
make Outlook crash? Usually the cause is that some object isn't being
released because it has a reference to some other object, or some other
object has a reference to it.


-Mark
 
Hi Balaji,

eventually helps the following code snippet:

Dim addIn As COMAddIn

For Each addIn In Application.COMAddIns
addIn.Connect
Next

Christian
 
Hi,
If such a crash occurs, i want to handle it.
I think we may not be able to handle all crash scenarios for Addins as
they reside inside Outlook.
So i wanted to handle it programatically to enable my Addin.

Thanks
Balaji
 
What wasn't helpful? If you don't put part of the preceding thread in your
post no one has a clue as to what you're talking about. If you mean deleting
extend.dat wasn't helpful that is to be expected, it won't do anything for a
disabled addin and has nothing to do with COM addins at all.
 
Hi,
If such a crash occurs, i want to handle it.
I think we may not be able to handle all crash scenarios for Addins as
they reside inside Outlook.
So i wanted to handle it programatically to enable my Addin.

They occur inside of Outlooks address space, but they are likely caused by
your AddIn's failure to release everything it has referenced and/or
allocated.

I usually add a call to OutputDebugString in each of the AddIn's shut-down
event handlers, and run a debugging port listener to monitor it. You should
see OnBeginShutdown, OnDisconnection and Terminate fire; if any of them
don't, your code has failed to release something, and that's what's causing
Outlook to crash, and that's why Outlook fingers your code as the culprit,
and disables it.

Ask yourself: does Outlook crash if my AddIn is not installed?.

If the answer is 'yes' then remove any other AddIns to eliminate them as
source of the problem, and if it still crashes with no AddIns, reinstall
Office, or do whatever else it takes to get Outlook stable all by itself
before continuing your project -- because trying to develop and test
software in a corrupted environment is just plain dumb.

If the answer is 'no' that should tell you something important, that you've
obviously overlooked, and are now attempting to discount...

So I'll spell it out for you once again: your AddIn is causing Outlook to
crash, because it's not releasing everthing it's using, and thus failing to
shut down correctly. Fix that problem, and Outlook will cease to crash.

-Mark
 
Although I have gotten crashes that are in Outlook's namespace that were
related to automation errors that throw the exception but it can't be
handled in the addin code. Those are the worst to try to figure out, like
when directly calling methods in the MAPI.DLL's from my code, those just
return exceptions usually with different numbers each time that only show up
as "COM exception" or something equally informative especially in managed
code.
 
Back
Top