OLE automation no supported in IIS 6.0??

[jsteph]

Hi All,
I hope this is the right forum, I have a question about automation in VB/ASP for OLE servers such as Access, Excel, Word, etc. I would like some opinions to see if I'm understanding Microsofts current position on OLE.

Here is a quote from kb article:

http://support.microsoft.com/kb/257757/

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.

Am I seeing this right? They've given up on OLE automation unless it's 'interactive', ie, when a user is sitting there at the console? They talk about 'deadlock', but the KB article was more specific to the security ramifications, and I stumbled upon it when finding that some Word and Excel automation that used to run fine, stopped dead with errors in ASP pages on a new Windows 2003 server, due to the new security model. All of this worked flawlessly on IIS 5.0.

It's been my understanding that, while OLE automation can be and is used often in interactive situations, (such as macros in Excel), but that a prime use of this was to automate some task in an ASP page, or VB program or .dll, that does some stuff 'automatically'--ie, that's how I would define 'automation'.

Do you agree that it seems as though they're backpedaling on OLE itself due to the fact that they see too much complexity in the security of an OLE app?
Thanks,
--Jim

 

[Sheco]

Many people have reported serious problems using ASP to automate Office applications.

Specificially, multiple instances of Excel and/or WinWord continue running after IIS has completed processing the ASP that spawned them.

You can't see these programs running because they have no user interface, but they are visible in the Task Manager and they eat up system resources, eventually slowing the server to a crawl.

This problem happens even when you "close" the application using the proper methods explosed by the Office COM objects.

 

[jsteph]

Sheco,
Yes, I've noticed the list of Excel.exe in task manager, and I've since put the Excel automation in a VB 6.0 .dll, called from the asp page, that stopped that issue, as well as many other automation issues. But I hate going the extra step, and having the IIS server fall into dll-hell.

But what gets me is the 180 contradiction in the same sentence--'Unattended, Non-interactive' is what automation is all about. Seems to me, why automate something if somebody's got to sit there at the console...
--Jim

 

[Sheco]

You can mitigate the DLL hell a little bit by going to Control Panel -> Administrative Tools -> Component Services.
Use this tool to define a COM+ application (MTS package) for your DLL. Then in VB project for the DLL turn on "Binary Compatibility" in the project property sheet.

Once you have this done you can reload/restart the COM+ package containing the DLL instead of restarting IIS.

 

[jsteph]

Sheco,
Once the com+ app is made, how does one link the wep app to it?

I'm using classic ASP, and have been selecting the .dll via the Project/References menu in visual interdev. Would the COM+ app show up there in the list, or is it still selected by choosing the same .dll and the COM part is automatically done just by the fact that one has defined the COM+ and added that dll to it?
--Jim