问题
I want to find out what a dll does, so I added it to a c# project. When my code creates an instance of a class which is included from the dll I get this error message:
Retrieving the COM class factory for component with CLSID {D5BED98C-C4EE-4D41-A624-6CFD9106F31B} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
I already changed the platform target to x86.
I also tried to register the dll, however it seems to not have an entry point. What did I miss for that the dll content is not executable?
Edit: Here is my "code":
this.acfg = new ACFG_Info();
Thanks in advance!
回答1:
You are using a COM component. COM does many things automagically, the feature you are having a problem with here is its ability to find a DLL on disk, load it, locate the code that implements the class you create and create an instance of it. Sounds simple, and .NET certainly makes it look simple, but it is not. Finding the right DLL is never simple.
It bombs very early, it never got around to finding the DLL yet. To locate the DLL, COM looks in the registry to find details about the class. All it knows is a number, a unique one that identifies the class. Called the CLSID for short. That number was compiled into your program when you used the new operator to create an instance of the class. The error message tells you what that number looks like. It is a guid, otherwise the exact same animal as the System.Guid class.
A very good way to see how COM looks through the registry is by using the SysInternals' ProcMon utility. It records how a program uses the winapi to access the registry. There's usually a mountain of info in a trace produced by ProcMon, locate the interesting bits by searching the trace for the number that you see in the error message. You'll see it searching for the registry key and not finding it. Which ultimately makes your program bomb on the "Class not registered" error code.
"Registering" the class is an installation procedure that needs to be done once before a COM component becomes usable. A vendor that supplies the COM server typically supplies you with an install program so this is taken care of. It tends to be simple, running Regsvr32.exe is usually enough. But that stops being simple on a modern 64-bit operating system, lots of ways you'll get in trouble. Like forgetting to run the command prompt elevated (use "Run as administrator"). Or by using the wrong version of Regsvr32.exe, you need c:\windows\syswow64\regsvr32.exe, the 32-bit version of the program.
Or the installation procedure is more convoluted, the COM dll might have dependent DLLs that need to be installed first before it can work properly. Or it is actually an out-of-process server, an exe that needs to be registered by running it with the /regserver command line option. Or it was designed to operate only correctly by using a manifest in the client program. Etcetera, this can get complicated in a hurry.
If these troubleshooting hints do not get you anywhere then you'll need help from the vendor. They'll know exactly what's required, we can only guess at it here.
回答2:
I suggest using SpyStudio to see the flow of the COM creation.
来源：https://stackoverflow.com/questions/16999506/calling-a-constructor-of-a-dll-throws-comexception