Microsoft Does Not Support Automation?

  • Thread starter Thread starter jabailo
  • Start date Start date
J

jabailo

I came across this article while researching a VB6 430 error:

INFO: Considerations for Server-Side Automation of Office
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257757

"Microsoft does not currently recommend, and does not support,
Automation of Microsoft Office applications from any unattended,
non-interactive client application or component (including ASP, DCOM,
and NT Services), because Office may exhibit unstable behavior and/or
deadlock when run in this environment."

Huh?

This is entirely the reason I would want to use interop and one of the
main selling points of MS Office would be to automate processes in a
batch mode.

Can someone tell me how I can write an automated email handler without
doing Outlook automation?
 
¤
¤ I came across this article while researching a VB6 430 error:
¤
¤ INFO: Considerations for Server-Side Automation of Office
¤ http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257757
¤
¤ "Microsoft does not currently recommend, and does not support,
¤ Automation of Microsoft Office applications from any unattended,
¤ non-interactive client application or component (including ASP, DCOM,
¤ and NT Services), because Office may exhibit unstable behavior and/or
¤ deadlock when run in this environment."
¤
¤ Huh?
¤
¤ This is entirely the reason I would want to use interop and one of the
¤ main selling points of MS Office would be to automate processes in a
¤ batch mode.
¤
¤ Can someone tell me how I can write an automated email handler without
¤ doing Outlook automation?

The Office applications were not designed with server-side automation in mind - just client side or
desktop automation. The threading model does not adequately support concurrent access.

Not sure what the functionality is of your automated email handler but there are probably other ways
to handle this.


Paul
~~~~
Microsoft MVP (Visual Basic)
 
John,

I cant answer your specific question as emails not my thing, but the problem
you alude to is very related to running Office on web servers, which is a
very tricky thing to do as you need to control the instantiation of it,
given its single threaded and web apps are by their very nature multi
threaded. The instance of office gets itself deadlocked very easy with
rogue processes left open and its often quite unstable.

What I have done in the past is to to make all jobs queue, so you only have
a sinle instance of office (word/excel/ppt) running and a single thread
passing it work and readin the queue, passing jobs one after the other.
With this thinking when you design your app you should be able to create
your handler without any issues.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director
 
I would also throttle requests through to a single instance. I actually go
so far as to communicate through a SQL server database, having tables stand
in for message queues, leaving COM out of the mix completely. It works fine.
Be careful, though, for the usual assortment of dialog boxes, alerts, other
processes trying to open within your Office session, etc.
 
"John Timney said:
John,

I cant answer your specific question as emails not my thing, but the problem
you alude to is very related to running Office on web servers, which is a
very tricky thing to do as you need to control the instantiation of it,
given its single threaded and web apps are by their very nature multi
threaded. The instance of office gets itself deadlocked very easy with
rogue processes left open and its often quite unstable.
Click to expand...

<Snip>

In addition, you should NEVER install Outlook on a server running
Exchange server ... very bad things can happen.

Depending on what your email requirements are:

1. You could use CDO to do most email type things.
2. You could use ADO to hook directly into your Exchange servers to
manipulate email and public folder content.
 
Back
Top