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

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?

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Sam Jost" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>

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

"Ken Slovak" <(E-Mail Removed)> wrote:
> 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?
>
> --
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
> Reminder Manager, Extended Reminders, Attachment Options
> http://www.slovaktech.com/products.htm
>
>
> "Sam Jost" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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
>>
>

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" <(E-Mail Removed)> wrote:
> 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?
>
> --
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
> Reminder Manager, Extended Reminders, Attachment Options
> http://www.slovaktech.com/products.htm
>
>
> "Sam Jost" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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
>>
>

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Sam Jost" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> 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

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...b;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" <(E-Mail Removed)> schrieb im Newsbeitrag
news:u$(E-Mail Removed)...
> 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.
>
> --
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
> Reminder Manager, Extended Reminders, Attachment Options
> http://www.slovaktech.com/products.htm
>
>
> "Sam Jost" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
>> 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
>

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Sam Jost" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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...b;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

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


"Ken Slovak" <(E-Mail Removed)> schrieb im Newsbeitrag
news:%(E-Mail Removed)...
> 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.
>
> --
> Ken Slovak
> [MVP - Outlook]
> http://www.slovaktech.com
> Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
> Reminder Manager, Extended Reminders, Attachment Options
> http://www.slovaktech.com/products.htm
>
>
> "Sam Jost" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> 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...b;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
>