在 .NET Core 2.0 中使用 COM 对象

Question

So, a client has a COM object written in C from 2007 that validates an encrypted session cookie. This currently works fine with older versions of .NET using the following.

var validate = Activator.CreateInstance(Type.GetTypeFromProgID("Company.Validate"));

---

The new implementation will be entirely in C# . I've extracted validation logic to a .NETCore class library, which we in turn reference in our ASP.Net Core project.

1. I've tried 32-bit & 64-bit versions, as well as IIS settings.

2. I've decompiled the COM object and referenced that instead, it works locally, but not on the development server, where I receive the following error:

   Retrieving the COM class factory for component with CLSID {EDC43BC6-5ECD-4501-AEB3-64A17180A13D} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

3. The COM is registered both locally and on the development server.

4. Activator.CreateInstance does not work in either environment.

5. The registered COM ID and ProgId is the same both locally and on the development server.

---

Q: What am I missing, or is this not going to work? Has anyone had any success with similar challenges? Am I overlooking anything?

Answer 1

You can't use COM with .NET Core. COM is Windows-only and everything in .NET Core must be cross-platform. You can however run your ASP.NET Core application on the full framework, and then you can use the COM library. In other words, running the full framework doesn't preclude you from being able to still use ASP.NET Core. You simply will only be able to deploy to Windows, because of the full framework/COM dependency. Technically, you only need to use .NET Core if you're planning to deploy to something like a Mac or Linux. Otherwise, just stick to what you know.

Answer 2

The required registry keys were never created. I had to manually add about 15 keys, for the Class, Interface, and Type. I believe this is because the COM had never been marshaled or invoked (because that wouldn't work) so the Class ID, AppID and registry mapping's had to be entered manually.

Answer 3

I've run into this recently, trying to instantiate an x86 coclass. Turns out that Visual Studio starts the first dotnet.exe which appears in the system path, no matter what architecture is actually configured. In my case, an x86_64 variant of dotnet.exe was started as a host, which in turn can't create any x86 coclass instances.

Try to load your project into the apropriate variant of dotnet.exe by hand and see if this helps.

Edit: This issue is discussed in more detail at https://github.com/dotnet/core/issues/901

Answer 4

As I can't comment yet.... You can use regsvr32 MyComLibrary.dll to add all the neccessary registry keys for you. See https://helpdeskgeek.com/how-to/register-dll-file-in-windows/