Basically I just need to know the difference between these 2 CLSID's. I have server, clean install, newly imaged with office. In DCOM under Excel Application I have an APPID of {00020812-0000-0000-C000-000000000046}. I've set specific Identity and launch permissions for this AppID.
When I run my app which is converting a Excel file, I get:
Error: Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 8000401a The server process could not be started because the configured identity is incorrect. Check the username and password.
I looked up that CLSID ID, it is also an Excel Application GUID. This is not what is listed in DCOM though. So I think I have a conflict here? Possibly different versions of office or x86 vs x64 archs competiting with each other on the same box perhaps?? Im not sure how Im supposed to set an Identity User on {00024500-0000-0000-C000-000000000046} since it is not the one listed in DCOM. I have looked around but haven't found much on this subject. Any help would be greatly appreciated.
While I was willing to accept the answer below as interop is bad automation for server based applications/services. I know this is true. It turns out in my case I had a bad dcomperm.exe utility I had gotten from somewhere. I was having issues getting the Windows 7 .NET 4.0 SDK to install so instead of fighting that issue, I grabbed a compiled DcomPerm from the web somewhere. Bad idea. This morning I found a way around the SDK install issue. I was then able to compile my own DcomPerm.exe tool from the SDK reference (C:\Program Files\Microsoft SDKs\Windows\v7.0\Samples\com\fundamentals\dcom\dcomperm). This tool worked. No more identity error.
I wasn't getting an error with the old DcomPerm tool either, but somehow it was not wiring everything up correctly. Obviously with Interop being kind of a touchy, non enterprise solution, this all makes sense.
You need to use components designed for the server-side execution (for example, such as Aspose provides) or just use the Open XML SDK in case of open XML files (.xslx and etc.), see Welcome to the Open XML SDK 2.5 for Office for more information.
As was mentioned in comments earlier, 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, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.