C# add in corrupting Reminders regularly

  • Thread starter Thread starter Josh Einstein
  • Start date Start date
J

Josh Einstein

I have an add in mostly developed in C# and I'm using the events of the
Application.Reminders collection to provide my own UI for the reminder
functionality. This works very well except that quite often, the reminders
folder seems to get hosed. I first noticed this because occasionally
reminders would fail to fire at all. If I restart Outlook a couple times it
fixes it or if I start Outlook with the /cleanreminders switch it fixes it.

Also I have verified the corruption using OutlookSpy.

Does anyone have any experience using managed code against the Reminders
collection? For COM interop, it is recommended never to call
Marshal.ReleaseComObject but is this one of those rare occasions where I
should?
 
First of all, are you sure that it's your code that's corrupting the hidden
Reminders folder?

There are a lot of things that can do that. PDA synching is a very common
cause of that. Some versions of various synch software do that, the worst
was some BlackBerry versions that actually created more than 1 Reminders
folder (Reminders, Reminders1, Reminders2, etc.) which succeeded in totally
confusing the heck out of Outlook.

Just working with the Reminders collection should not do anything harsh to
Outlook.

A general rule for all Outlook programming with the interop is to release
all your objects and call Marshal.ReleaseComObject and explicitly call the
garbage collector. The lack of definitive finality in when objects released
does cause Outlook to remain in memory when shut down.
 
Hey Ken thanks for responding. Especially because I know you're the resident
expert on reminders. I am positive that it's my code doing it because I have
reproduced it several times without ActiveSync running or any external
automation. There's still only 1 Reminders folder, but when I use OutlookSpy
to inspect the contents when it's in this state, one or more of the items do
not show any values which leads me to believe it is an item inside the
reminders folder and not the reminders folder itself that is getting
corrupted.

From what I understand, it has been the general recommendation of Microsoft
not to call ReleaseComObject in most cases. I know I've had to do it with
the Note inspector but so far that was all. I don't have a problem with
Outlook hanging around in memory but I wonder if maybe having a live
reference to Reminders or any of the individual Reminder objects (I keep
them around in the Tag property of a ListViewItem) when Outlook is closed
could be causing the problem. It seems like Outlook tears down my AppDomain
a few seconds after the last Explorer object closes. At this time, I still
have a reference to Reminders and any of the individual Reminder objects
that IsVisible = true.
 
I may have fixed the problem by no longer hanging onto the RCW for the
individual Reminder objects. At least, I can't seem to make it corrupt the
reminders anymore since doing that. I can create a managed class that holds
all of the relevant data I need from the Reminder. Hopefully this fixes it.
I will stress that the beta testers keep an eye out.

Now, were you able to stop Outlook from playing the reminder sound on every
reminder? :) Even tho I cancel the BeforeReminderShow event, it's still
playing the sound for every reminder which is a bit annoying. But that's the
least of my concerns.
 
Releasing your objects in the last Explorer.Close event is critical so
things can close properly for sure.

The sound can't be controlled from the Outlook object model. It will fire no
matter which event you subscribe to, it fires before BeforeReminderShow.

I'm sneaky, I just disable the entire Outlook reminders service and replace
it with my own, so I control everything from the sound to a reminders window
opening up and everything else.
 
Back
Top