Is a COMException of 0x80040154 always 'Class not registered'?

Question

Does a System.Runtime.InteropServices.COMException of 0x80040154 always mean that the class isn't registered? I'm getting a COMException which says "Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following error: 80040154." It's trying to load Interop.Domino.dll which is a reference I got from the COM tab of Add Reference called "Lotus Domino Objects" which points to domobj.tlb in the Notes program folder.

I wrote the code years ago - it's the only thing I've ever done with interop and it's fair to say that I never really got to grips with it.

I'm seeing this error again after moving the code to a 2008 R2 server (so it's x64). It was written on XP and run on 2003 (both x86). In order to diagnose the problem, I built a Win7 x86 (because there's no R2 x86) box and it worked. I also built a 2003 x64 box and it fails with the same error, so it looks like it's caused by moving to x64 architecture. Is there something I should do when doing interop to get x86 COM DLLs to work on x64 machines?

Solution 1

I had the same problem trying to build and run a .NET application on Windows 7 x64 that called interop.domino.dll, which is 32 bit only.

To resolve, I recompiled the .NET application to run specifically as x86 when run on x64 operating systems.

I was using Visual Studio 2010 Express Edition which is trickier to target specifically for x86 platforms than the paid for versions.

The solution was:

1. Click TOOLS > OPTIONS > PROJECTS AND SOLUTIONS
2. Check the box "Show advanced build configurations" and click OK
3. Click TOOLS > SETTINGS > check EXPERT SETTINGS to see the build configuration manager
4. Click BUILD > CONFIGURATION MANAGER select the platform dropdown to X86 and click CLOSE
5. Now rebuild the project

Solution 2

There's an IBM technote that indicates that the Domino COM classes are not supported on a 64-bit OS. See https://www-304.ibm.com/support/docview.wss?uid=swg21454291 So it seems like even by compiling the code to run as x86 (as per mpownie's answer), you're still taking some chances.

Solution 3

Pay attention to register of 32-bit components using the correct register (C:\Windows\SysWOW64\regsvr32.exe).
If you have already registered up with the 64-bit version, unregister each dll with the same version.

More help you find here Team is Going from XP32 to XP64 for .NET Development - Any Gotchas?

Good luck