Invoking Excel COM object with CLSID is either not valid or not registered

[RJN]

Hi

I'm invoking the excel object from ASP.Net application. My development
machine is Windows 2000 and MS Office is installed on my m/c. I have
added reference to the Excel COM object, I have given Access and launch
permissions to ASPNET user in DCOMCNFG and the identity set to launch
user. But I get the following error, moment I try to create the Excel
object: Dim oexcel As New Excel.Application

"COM object with CLSID {00024500-0000-0000-C000-000000000046} is either
not valid or not registered"

The same DCOM config settings work fine in Windows xp.

Also I have observed that (in xp), the excel objects are still in memory
even after the application is terminated and I could see multiple such
objects in task manager. I close the excel object by calling quit. How
do I destroy the objects?

Regards

rjn

 

[Alvin Bruney - ASP.NET MVP]

2 things. Use the depends utility that ships with visual studio to examine
the excel object in order to determine if a dependency is failing.

Unregister the excel object and re-register it then run depends on it.

--
Warm Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Professional VSTO 2005 - Wrox/Wiley 2006
Blog: http://msmvps.com/blogs/Alvin/

 

[Adrian Gallero]

Hi,

I don't know about the "not registered" question, but about the second:

Also I have observed that (in xp), the excel objects are still in
memory even after the application is terminated and I could see
multiple such objects in task manager. I close the excel object by
calling quit. How do I destroy the objects?

If you really need to use ole automation, in order to close Excel, you
need to free al Excel objects that you use, not only the application.
For example, if you are using a Range object, make sure that it is
released too. Any reference that is left will prevent Excel to close. I
am not sure, but if setting them to null does not help, you could try
by calling Marshal.ReleaseComObject on them.

I said "if you really need" because using OLE automation on the server
is not a very good idea. It is very easy to crash, to have security
issues, or just not close and keep the instances of Excel.exe growing
until the server runs out of memory.

From http://support.microsoft.com/kb/257757/en/
"
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."


I would recommend you to look at an alternative solution. My company
develops one, at www.tmssoftware.com/go/?flexcelnet and I think it is
one of the better options out there for creating files that "just
work", but there are a lot of other options too. Just google for them.
If you need to pay just one Excel license to deploy on a server, any
third party solution will be less expensive.

Well, I am not sure if this helps, but maybe it does.
Best regards,
Adrian.

 

[RJN]

Thanks for your replies. I could not find any dependency checker in
VS.Net 2003. As I said I have installed Office 2003, so I think the
installation would have installed correctly all the dependent files. So
should I add reference to an other COM object other than Excel library?

 

[David Duchrow]

Hallo,


I got the same problem a few days ago.
It was on a Win XP system with MS office 2003.

There were differend SLIDs for Excel.Application in the windows registry
(regedit) and in the dcom configuration (dcomcnfg).

The error message showed the SLID of the registry.

I modified the SLID in the registry to the SLID of dcomcnfg and it
worked.



With Kind regards,
yours David

 

[Guest]

Your first issue is about backwards compatability in .NET Interop, not
permissions.
Your second issue is probably permission related.
Please see the following articles which solve both issues, respectively:
1. "Achieving Backward Compatibility with .NET Interop: Excel as Case
Study" - http://www.devcity.net/Articles/163/1/article.aspx
2. "50 Ways to Kill Excel" -
http://www.devcity.net/Articles/239/1/article.aspx

--scott