Develop Reference

Retrieving the COM class factory for components with CLSID - Class not registered

I am trying to run my Windows Application (winForm) on a PC (OS Win7, 64 Bit) but it showing me this error or exception:
Retrieving the COM class factory for components with CLSID
{00853A19-BD51-419B-9269-2DABE57EB61f} failed due to the following
error: 80040154 Class not registered (Exception from HRESULT:
0x80040154 (REGDB_E_CLASSNOTREG)).
I google and found that I should need to Build for x86 (Althought current window is 64 bit). I did this but getting the same error. After that now I trying to install zkeeper dependency but getting this error:
The Module D:\TheSDK\zkemkeeper.dll" may not compatible with the
version of windows that you are running. Check if the moduel is
compatible with an x86 or x64 version of regsvr32.exe
Here is batch file (Dependency SDK installer) :
cd /d %~dp0
if /i "%PROCESSOR_IDENTIFIER:~0,3%"=="X86" (
echo system is x86
copy .\*.dll %windir%\system32\
regsvr32 %windir%\system32\zkemkeeper.dll
) else (
echo system is x64
copy .\*.dll %windir%\SysWOW64\
regsvr32 %windir%\SysWOW64\zkemkeeper.dll
)
Update: Even I try to run and install manually both regsvr of system32 and 64 and still getting same error.

I don't know what was the problem but maybe it was related to .Net framework. After installing the developer pack of .Net Framework 4.5.2. I deleted my SDK and register all the dependency (DLL) again. Then, it worked.

This error occurs because the com dll Zmkeeper.dll was not able to register. In some cases, it might need to be registered along with a typeLib file. Also, there could perhaps be some custom installer action performed if it goes through an installer. Seems like a demo version installation solved the problem. checkout this issue mentioned here

What has to be done to resolve 80040154 Class not registered execption

I am facing the following error only when i try to run the project on a target machine
[ERROR] ExecuteTestScriptsOnSAP_GUI: Retrieving the COM class factory
for compo nent with CLSID {B90F32AD-859E-4EDD-BFAE-C9216849520C}
failed due to the foll owing error: 80040154 Class not registered
(Exception from HRESULT: 0x8004015 4 (REGDB_E_CLASSNOTREG)).
It seems to work fine on my development machine.
I am trying to launch SAP gui 7.40 from my project and it has a reference to Interop.SAPFEWSELib.dll
The above .dll file was built when sapfewse.ocx was first added as a dependency to the project.
Can anyone please guide me as to what can be done to resolve this issue?

I can't comment yet and so can only respond in an answer.
It could be that that the control sapfewse.ocx that you are consuming via Interop.SAPFEWSELib.dll is not registered on your target machine.
Check the registry HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID and locate the class for B90F32AD-859E-4EDD-BFAE-C9216849520C on your dev machine. The InProcServer32 key should tell you the path of the registered component. Ensure that this component is deployed and registered on your target machine.
Hope that points you in the right direction.

If you're on a 32bit OS machine then
"C:\Windows\System32\regsvr32.exe" /i "Path to OCX"
Or 64 bit then "C:\Windows\SysWOW64\regsvr32.exe"
If you double click the .ocx on the target machine, it should prompt you to select a program to complete the action with. Browse to the relevant regsvr32.exe and it will then register it for you.
But it looks as if your ocx comes from a third party SDK? as it resides in c:\program files (x86)\sap\frontend\sapgui\ on your dev machine. Have you installed this SDK on your target machine? If not.. do so and this will install and register the component for you.

Reference Microsoft.Office.interop.access.dao.dll cause error C#

I have an application which connect to access 2003.
I'm facing a problem with insert bulk of rows to access, so i came to an solution by using DAO (Microsoft.Office.interop.access.dao.dll) to improve performance of this process as follow this link
Retrieving the COM class factory for component with CLSID {XXXX} failed due to the following error: 80040154
But when i open the connect to access by using
using DAO =Microsoft.Office.interop.access.dao.dll;
....
new DAO.DBEngine();
this line gave me an error:
System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {CD7791B9-43FD-42C5-AE42-8DD2811F0419} failed due to the following error: 80040154
My application is 32 bit and i running the program in a machine with Win xp 32 bit too, It work fine until i start using DAO
I have try many thing that i came up when google, but nothing help, like this:
Error in create access database?
--
More info:
After install
AccessDatabaseEngine.exe
the problem go away, so i think it must be something like the dll can't register, and then after install the package, somehow it's registered DAO dll.
But i can't not install anything in production server, so i need a way to manual register the dll, or something like that, to let the application work without install AccessDatabaseEngine.exe package
Please give me any advice

WORKAROUND:
The possible workaround is modify your project's platform from 'Any CPU' to 'X86' (in Project's Properties, Build/Platform's Target)
ROOTCAUSE
The VSS Interop is a managed assembly using 32-bit Framework and the dll contains a 32-bit COM object. If you run this COM dll in 64 bit environment, you will get the error message.

InvalidCastException: Unable to cast COM object of type x to interface type y

I have some C# code written on machine #1 using Visual C# Express 2010. The code is dependent on some COM objects that are registered DLLs. It compiles and runs fine on machine #1. The COM objects are installed from a program called BostonWorkstation, which is installed on machines #1 and #2.
Machine 1:
Code written on.
Visual C# 2010 Express installed.
The "BWS" DLLs are registered.
The program runs just fine.
Has .NET versions: v4.0, v4, v3.5, v3.0, v2.0
32bit
Machine 2:
The "BWS" DLLs are registered.
The program errors with System.InvalidCastException (below).
Visual C# 2010 Express not installed.
Has .NET versions: v4, v3.5, v3.0, v2.0, v1.1
32bit
Machine 3:
The "BWS" DLLs are not registered.
Visual C# 2010 Express installed.
The program errors (as expected) with: System.Runtime.InteropServices.COMException (...): Retrieving the COM class factory for component with CLSID {...} failed due to the following error: 80040154 Class not registered (...)
32bit
When I try to run that program (compiled on machine 1) on machine #2 which also has the same exact registered DLLs, but the program fails to run. I also tried running it on machine #3, which doesn't even have the DLLs and that gets a different error as expected.
The runtime error on machine 2:
1 Unable to load BostonWorkstation, error: System.InvalidCastException: Unable to cast COM object of type 'System.__ComObject' to interface type 'BostonWorkStation70.BostonWorkStation'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{8C8144EF-ADB7-48FD-A5BB-6E55B8382B3E}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
at TestBWS.LoginForm() in C:\Documents and Settings\user\My Documents\Visual Studio 2010\Projects\project1\TestBWS\CodeFile1.cs:line 67
(The Visual Studio folder reference is just the compile time path)
Checking the registry on machine 1 I found this:
HKEY_CLASSES_ROOT\Interface{8C8144EF-ADB7-48FD-A5BB-6E55B8382B3E}
with a default REG_SZ value of BostonWorkStation
The code:
using BostonWorkStation70; //line 1
...
try
{
bwsLogin = new BostonWorkStation(); //line 67
}
catch (Exception e)
{
Console.WriteLine("1 Unable to load BostonWorkstation, error: " + e);
System.Console.ReadLine(); //pause the debug window
return false;
}
I have tried running ProcMon to compare the machines Process logs, but there are thousands of entries for just this program and I'm not seeing any missing references offhand. I ran a compare, but a successful Process log has 5x as many lines.
From what I understand, running the program on machine 2 has it creating the BWS object as a generic System.__ComObject (instead of BostonWorkStation70.BostonWorkStation) and I don't know why. The DLLs etc are definitely correct on machine 2, otherwise I'd be getting that Class not registered error on runtime.
Why will the compiled program not run on machine 2? All the dependent COMs/DLLs are on it.

if that error message is coming from machine #2, the one you said "Visual C# 2010 Express not installed."
why is it running from the default visual studio projects folder?
C:\Documents and Settings\user\My Documents\Visual Studio 2010\Projects\project1\TestBWS\CodeFile1.cs:line 67
You may have other problems....

Have you registered your COM object class from the library using regsvr32.exe on second machine?
To check that I'd search the registry on first and second machines looking for all possible {8C8144EF-ADB7-48FD-A5BB-6E55B8382B3E} string entries. If search results are different then it's probably the case.

If the BostonWorkstation components are unmanaged - open them up in dependency walker to make sure that all their dependent dlls are present.
Odds are they are unmanaged components and make use of the MSVCRT 10. In which case you will need to install the VS 2010 CRT on machine 2.

Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)

I'm creating a windows service on a windows 2003 machine, using dsofile to modify custom properties on a bunch of documents. This works fine until I install the service on a win2k8 machine where it gives me the following error:
ERROR [2010-09-06 13:17:12,317] An
unknown error occured:
System.InvalidCastException: Unable to
cast COM object of type
'DSOFile.OleDocumentPropertiesClass'
to interface type
'DSOFile._OleDocumentProperties'. This
operation failed because the
QueryInterface call on the COM
component for the interface with IID
'{58968145-CF01-4341-995F-2EE093F6ABA3}'
failed due to the following error:
Error loading type library/DLL.
(Exception from HRESULT: 0x80029C4A
(TYPE_E_CANTLOADLIBRARY)).
All my projects are set to run as x86, and Ive used procmon to monitor the files requested without any clues.. Anyone have any ideas on how to solve this?

Since you have mentioned that you are running a service under Win2008,
The first clue is, is the DSO File dll component part of Office, what version? is that installed?
I am not sure if a service can access such a office component running as a system account user which could be open to malicious exploits whilst running under said account as a service...
TYPE_E_CANTLOADLIBRARY should be as a result of the first option given...

I had a similar problem and I solved it due to the explanation by Geoff Darst - MSFT.
I adjusted his original answer to fit your interface IID:
Sounds like you have a problem with your typelib registration.
Presumably, the Com interop layer is hitting the registry to try to
locate the typelib. It would start by looking under
HKCR\Interface{58968145-CF01-4341-995F-2EE093F6ABA3}\Typelib. The
default value should refer to the guid for the typelib that defines
the interface in question: which should be located under the following
key: HKCR\Typelib{what found in the aforementioned Interface key}.
There should be a version subkey and then a 0 subkey, and a win32
subkey under that. The default value of the win32 key should point to
the right typelib.