closing outlook after client error

[Sam Jost]

Hi folks,

I'm running outlook via com, importing and changing lots of public data.
Sometimes I hit some boundary and get an exception a client task has failed.
Thats not the problem I want to ask about.

The problem is: after I got this exception I try to gracefully close outlook
using
outlookNamespace.Logoff();
outlookApp.Quit();

It does not close. Well, the main window does close, but outlook stays in
taskbar and task manager, and I can't get it to close other then to kill the
process. Outlook keeps saying it is busy with some task to exchange (probly
the failing one) and wont budge.


My question is: how do I (gracefully) get outlook to stop the failed client
task, close the connection and quit?

it does quit nicely whenever I don't get a client exception, but it must be
possible to somehow gracefully close outlook when I have hit an exception,
not?

thanks,
Sam

 

[Ken Slovak]

Is this from an EXE or a service and what language are you using? What
version of Outlook?

If a service, find some other way to do it. Outlook cannot be run from a
service.

If from .NET explicitly call the garbage collector.

Otherwise provide more details on your setup and maybe show some of your
code. You are handling any possible errors?

 

[Sam Jost]

Hi Ken,

I'm calling outlook 2003 from a c# console program, no service (but good to
know it would not work from one).

The garbage collector I could try, thanks - but shouldn't the .net runtime
dispose of objects when quitting the program?

The source I'm using:

--
Outlook.Application outlookApp = new Outlook.Application();
Outlook.NameSpace outlookNamespace = outlookApp.GetNamespace("mapi");
outlookNamespace.Logon("", "", true, true);
Outlook.MAPIFolder outlookKontaktFolder = outlookNamespace.PickFolder();
try
{
foreach (EinKunde kd in kunden.Values)
{
Outlook.ContactItem newItem =
(Outlook.ContactItem)outlookKontaktFolder.Items.Add("IPM.Contact");
// set fields in new item
newItem.Close(Outlook.OlInspectorClose.olSave);
}
}
finally
{
outlookNamespace.Logoff();
outlookApp.Quit();
}
--

After the 250 new object the client session will close, Logoff and Quit will
be called, the program will end, but outlook will stay active and can't be
closed.

Sam

 

[Sam Jost]

Hi Ken,

surprise, today on blogs.msdn.com I stumbled upon some posts, one of these
said the correct way to close a com app is using

System.Runtime.InteropServices.Marshal.ReleaseComObject(outlookApp);

This will close Outlook gracefully even after an error and is the correct
way to do it - and it did work on my case.

thanks,
Sam

 

[Ken Slovak]

Yes, that would do it. You always have to explicitly release all your
Outlook objects and usually call the garbage collector so Outlook can close
when you want it to.

Also, when using .NET languages you have to be aware of that 250 connections
limit that aren't released unless and until you close the application or
explicitly release the objects and call the garbage collector. That 250
limit is unique to the .NET languages.

 

[Sam Jost]

Hi Ken,

calling the garbage collection should not be necessary (I did it, but an MS
blog-post insisted it should not be done here).

We are both talking about the same 250 items restriction as posted here?
http://support.microsoft.com/default.aspx?scid=kb;en-us;830829

This is unique to .NET languages? maybe 'cause of managed memory?

Dang, I should have tried to release every single new object I add, now you
mention it it seems so obvious.

I just tried it, used
ReleaseComObject(newItem);

on every added item after I was done with it, worked like charm.

thanks, your comment just made a blind man see light again!!!!

Sam

 

[Ken Slovak]

No matter what some MS blog says you really should call the garbage
collector if you care when Outlook shuts down (if at all). That's especially
the case for COM addins.

That article is related to the 250 limit issue. What really happens is not
an Exchange problem but one that's limited to .NET languages. For example,
due to a lack of a compelling .NET Outlook story, bugs and slow code
execution I code all my addin using VB6. I never have to worry about that
250 limit or calling the garbage collector. If I set an object = Nothing
it's released right away because of VB's deterministic finality. In .NET
that doesn't exist.

The article is misleading because the cause of the problem is not too many
messages but that .NET languages open an RPC channel to Exchange for each
item that's accessed. In a loop that can add up very quickly and the open
RPC channels aren't reused or released. So you run into the default limit of
250 open RPC channels at one time. In VB6 that never happens.

 

[Sam Jost]

Hi Ken,

no, really, my c# code does run nicely without any hitches or glitches or
uncanny behaviour now that I properly free the every Com object I create.
Without calling garbage collection or stuff.

I strongly believe, and so far always have been right, that manually calling
the garbage collector is wrong and doing it is trying to mask some other
mistake I made.

The 250 items limit is not per se a .net problem, but a problem with not
properly disposing of objects.

The problem is unlike VB6 .NET does not automatically take care of these
objects, I need to do it myself.

So if properly disposed there is no problem anymore.

uh, lost the thread, what where we talking about?

Ah, yes, but it still is a bit slow at adding new items.

Sam