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

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.

C# .Net App On Windows XP Fails Shell32 Code for Renaming Shortcut

I have a situation where I have a windows Desktop APP in .Net C# that must on both Windows 7 and Windows XP rename a shortcut. I have it working in Windows 7 but on XP this fails.
.Net 4.0 Client Profile and Extended is installed on XP and all other parts of the applciation are functioning on XP. The project has a reference Interop.Shell32 (MIcrosoft Shell Controls and Automation through COM Interop rahter than pinvoke) and the code is simply the following:
var shl = new Shell32.Shell();
argStrLnkPath = System.IO.Path.GetFullPath(argStrLnkPath);
var dir = shl.NameSpace(System.IO.Path.GetDirectoryName(argStrLnkPath));
var itm = dir.Items().Item(System.IO.Path.GetFileName(argStrLnkPath));
itm.Name = "My Shortcut Name";
The above works in 7 but not XP. The following versions of the Shell32.dll exist:
Win7 Shell32.dll version 6.1.7601
WinXP Shell32.dll version 6.00.29.6242
When I spy the XP shell32dll in the object browser, the same objects exist, so the functionalty should be there (unless I'm not seeing something important).
My project is set to build as x86 platform for both machines. For the reference, I have tried the Embed Interop Types as True and also copy local as False.
I have an msi installer but is there something I need to do on the target XP machine? And should I copy Local? Any ideas on the propper way to get this working?
I have run the code on that XP Machine and receive the following from teh Event Viewer:
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.InvalidCastException
Embed Interop Types for Reference = True: The stackTrace for this error is:
Unable to cast COM object of type 'System.__ComObject' to interface type 'Shell3
2.Shell'. This operation failed because the QueryInterface call on the COM compo
nent for the interface with IID '{866738B9-6CF2-4DE8-8767-F794EBE74F4E}' failed
due to the following error: No such interface supported (Exception from HRESULT:
0x80004002 (E_NOINTERFACE)).
Embed Interop Types for Reference = False: The stackTrace for this error is:
Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.IO.FileNotFoundException

Issue Solved! I hadn't realized that when you make those types of COM Interop inclusions, they must have a Setup Project (msi installer if going on another system). Also, another caveat is that if you have already created a setup project, you must Add > project Output again. This will automatically pull all of those interop inclusions in under the Detected Dependencies folder. This solved my issue.

Unable to load DLL VistaDb20.dll because of an invalid access to memory location (HRESULT: 0x800703E6)

I have a project that was built in Visual Studio 2005 in C#. I created an installer for the Windows application (in VS2010) and it installs and works fine on Windows XP SP3. I tried installing it on Windows 7 32-bit and it says installation is successful but when I try to open the application I receive this error message:
A fatal error has occurred. Unable to load DLL 'VistaDb20.dll': Invalid
access to memory location. (Exception from HRESULT: 0x800703E6)
People suggested I run this in the command line:
regsvr32 VistaDb20.dll
I get the error message:
The module "VistaDb20.dll" was loaded but the
entry-point DllRegisterServer was not found.
Make sure that "VistaDb20.dll" is a valid DLL or OCX
file and then try again.
So then I tried regasm VistaDb20.dll /tlb:VistaDb20.tlb using the .NET Framework Assembly Registration Utility 2.0.50727.4927 and get error:
RegAsm : error RA0000 : Failed to load 'VistaDb20.dll' because it is not a valid .NET assembly.
I am not sure how to get my application running on Windows 7 with this .dll problem. Any help would be appreciated. This application and the database was created using VistaDB 2.1
I guess I can't change the actual dll since I did not create it but maybe I have to change some properties of the dll in Visual Studio?

I had this error while trying to registering my VB .NET assembly using RegAsm command:
RegAsm : error RA0000 : Failed to load 'VistaDb20.dll' because it is not a valid .NET assembly.
I solved the problem buy executing RegAsm of the right .NET Framework.
I mean you should use the tools of the same Framework that you make as target in your advanced options of compilation (VS2010).

According to this your problem is that this DLL is not compatible with DEP. You'll need to disable DEP to workaround this but in the long term you should try to wean yourself off this particular dependency.

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.