There is a third-party COM server DLL I need to include in my ASP.NET Core project. Adding via the Add > COM Reference worked fine and I end up with a COM > Interop.ThirdPartyServer under the Dependencies.
In my code I want to create an instance of one of the classes but it keeps failing with "Class not registered" even though it is.
I used
using ThirdPartyServer;
Type widgetType = Type.GetTypeFromProgID("ThirdPartyServer.Widget");
IWidget myWidget = (IWidget)Activator.CreateInstance(widgetType);
But I am seeing a "80040154 Class not registered" error.
I am sure it is registered, as I had to find the ProgID from the registry as it's not shown anywhere in the disassembled type library. In any case, I re-ran regsvr32 ThirdPartyServer.dll and that seemed to work with no errors, as it is a 32-bit DLL.
CodePudding user response:
The 0x80040154 aka REGDB_E_CLASSNOTREG or "Class not registered" error usually means ... well, that the class is ... not registered. But the exact reason can be a bit complex.
COM clients and COM servers that run both in-process need to run with the same bitness, so both in x86 or both in x64. So:
If a COM client runs as x86, it talks to the x86 side of the registry, so the COM server must registered in the x86 side of the registry (regsvr32, regasm, custom reg code, etc. must run as x86).
If a COM client runs as x64, it talks to the x64 side of the registry, so the COM server must registered in the x64 side of the registry (regsvr32, regasm, custom reg code, etc. must run as x64).
Note 1: for out-of-process communications x86 clients or servers can talk to x64 servers or clients. That's one benefit of COM.
Note 2: the .NET "Any CPU" compilation feature allows to use the exact same binary for x86 and x64 but this binary still needs to be registered in the needed registry side, or in both registry sides if x86 clients and x64 clients support is needed.
