Retrieveing COM class factory failure. error: 80040154

Retrieving the COM class factory for component with CLSID {AD37B7D5-B5A3-460A-8FFB-3C71984A4537} failed due to the following error: 80040154.

Exception details:

System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {AD37B7D5-B5A3-460A-8FFB-3C71984A4537} failed due to the following error: 80040154.

I'm using A C开发者_高级运维OM DLL in my ASP.NET Web Application. I have managed to successfully get it working on both my own dev machine and a build machine.

However when I try deploying the project to a different machine (Microsoft Windows Server 2003 R2) I get the above error.

I have registered the COM DLL using the regsvr32 command. It says the DLL was registered successfully.

I am developing the project in Visual Studio 2008 with ASP.NET version 3.5 and building my project to run on any CPU, each machine uses 64-bit Windows. I'm using IIS version 6.0.

(I have tried enabling IIS to run 32-bit applications, this caused the web application to be unavailable.)

I wrote a Windows script file to check weather the COM DLL was working or not on (i.e. independent from the project). This script worked fine on both my build machine and my own dev machine.

However it did not run properly on the machine I'm having trouble with (Microsoft Windows Server 2003 R2). What I had to do was to run the script from the command line using the following command (which I found here):

C:\WINDOWS\SysWOW64\wscript.exe COMtest.js  

The wscript file works succesfully when ran in this way.

I presume it has something to do with the version that the COM DLL was built for.

Do I need to enable some settings in my Visual Studio project?

(Please note I have not built the COM DLL myself. Someone else has built it and given it to me.)

---

It is COM's FileNotFound error. In this case it is very likely to be a bitness problem. The registry keeps COM registration for 32-bit and 64-bit servers separate. Strongly indicated by it working when you run wscript.exe from the syswow64 directory, that's the home for 32-bit executables. A 64-bit process won't be able to find the 32-bit server in the registry. Nor will it be able to use it. Repro that by running c:\windows\system32\wscript.exe

You will first have to build the x64 version of the COM server so a 64-bit process can use it. Then you will have to register it with the 64-bit version of Regsvr32.exe, the one in c:\windows\system32, not syswow64. If you still have trouble then use SysInterals' ProcMon utility to find out where the process is looking in the registry and file system.

Or get IIS to run in 32-bit mode. That's another question that needs different tags.

---

I fixed this problem by creating a COM+ application for the dll.

---

I received the 80040154 error when using a third party .dll file. In the end I found that the error was the result of trying calls that were prohibited by the API - Visual Studio led me to think they would be fine. Therefore, one answer maybe to check that your API calls are correct with the dll documentation i.e. RTFM!

Thought I would add this as it may save somebody some valuable time.