i have a asp.net project that reads the excel file and retrieves its data using Microsoft excel 16 object library and Microsoft office 16 object library .. every thing is fine on developing machine and i can read the data ...... but after i published the website and upload it on somee.com for free hosting ... the part that i upload the excel goes well but in reading data part i got this error
System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
i searched for the cause and i think the problem is about excel library that may not supported by host or something like that ... thank you if you help me to figure it.
You're breaking the cardinal rule of Office Automation -- don't do it on a server. Period.
It is possible to install Office on a server, and it's even possible to manually register some things to get it to do just enough to make your web application work once or twice while you're testing. But as soon as that application is moved into a production environment, it's going to start failing -- consistently or intermittently -- and can even cause your web application to hang entirely. Office is a set of applications, not a set of data manipulation libraries. Everything about it is designed as if a user is running it from within an interactive session - it creates windows for a lot of operations, and it is inherently multi-process. Your server is running in a non-interactive session, and the rules for window management are different under this scenario. There's really no way to make Office automation safe in a server application, especially a server that's hosting multiple applications/sites and/or is high-traffic.
The "correct" way to do this is to use a library that treats Office documents purely as data structures. A library that does this can read and manipulate the data in the document without invoking Office to do so. An analogy would be XML documents -- you use an XML API like .NET's XmlDocument or XDocument to read data from files, manipulate it in memory and store it back to disk. This is very different than trying to automate the operations that a user would perform with some visual XML editor application.
I would recommend you check out the Open XML SDK, a library provided by Microsft for exactly this purpose. All Office 2007+ documents are stored in an open format called Open XML. This library is coded around the specifications for that file format.