Excel.exe does not leave memory when called from Web Service

[John Bailo]

I wrote a c# web service that creates an Excel spreadsheet. Even
though I follow all the formal procedures for closing the app and
finalizing, an instance of Excel still remains in memory. Is this a
problem? With that instance of Excel.exe eventually go away because of GC?

I follow the procedures described here:

http://blogs.geekdojo.net/richardhsu/archive/2003/11/14/281.aspx

I converted this app to a console app, and in this case Excel.exe does
leave the task list. But when run as a web method, Excel.exe stays
there with IUSR_ as the owner. I'm trying to get rid of this
instance once the method ends.

 

[Willy Denoyette [MVP]]

I wrote a c# web service that creates an Excel spreadsheet. Even though I follow all the
formal procedures for closing the app and finalizing, an instance of Excel still remains
in memory. Is this a problem? With that instance of Excel.exe eventually go away
because of GC?

I follow the procedures described here:

http://blogs.geekdojo.net/richardhsu/archive/2003/11/14/281.aspx

I converted this app to a console app, and in this case Excel.exe does leave the task
list. But when run as a web method, Excel.exe stays there with IUSR_ as the owner.
I'm trying to get rid of this instance once the method ends.

This is the result of using Office products with automation at the server side, these
applications were not designed and are not supported in such scenarios.
More detailed info:
http://support.microsoft.com/default.aspx/kb/257757

Willy.

 

[John Bailo]

This is the result of using Office products with automation at the
server side, these applications were not designed and are not supported

Yes, I know.

But Microsoft does not leave me with options other than buying some
expensive 3rd party component.

I simply want to write data from a database to an Excel file.

Is there a way this can be done?

Why is it so impossible?

 

[Guest]

I understand this isnt a Visual Studio group ... but are you using Visual
Studio 2005 for your developement? VSTO (Visual Studio Tools for Office) is
included with the Team Edition. I think you have to buy VSTO separately if
you have VS Pro. I use VSTO with code behind when need be and it's very nice
and simple to use. It's what you need. Check it out.

PWA

 

[Willy Denoyette [MVP]]

I understand this isnt a Visual Studio group ... but are you using Visual
Studio 2005 for your developement? VSTO (Visual Studio Tools for Office) is
included with the Team Edition. I think you have to buy VSTO separately if
you have VS Pro. I use VSTO with code behind when need be and it's very nice
and simple to use. It's what you need. Check it out.

No it's not, what the OP is trying to achieve has nothing to do with VSTO.

Willy.

 

[Guest]

I've encountered this problem; it usually come about when:

1. When using automation , you do not call Application.Quit
2. You call Application.Quit but did not take care to end other objects
below the hierarchy of the Application object before calling Quit.

 

[John Bailo]

Is there a way this can be done?

Here's a thread that documents this same problem exactly:

http://www.vbforums.com/showthread.php?t=396405

His solution is to use GetWindowThreadProcessID to find and kill the
hanging Excel.exe.

I like it!

 

[John Bailo]

Is there a way this can be done?

Here's a more define article:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PageIndex=1&SiteID=1&PostID=1010842

It confirms that others are having this problem/issue even when writing
orthogonal code to close Excel.