0

I am working with some COM libraries which allow me to connect to the IBM PCOMM API. I am trying to obtain a list of connections, from an object called AutConnList(). The code looks like this:

using AutConnListTypeLibrary;
using AutOIATypeLibrary;
using AutPSTypeLibrary;

public static List<string> GetSessions()
{
    var sessions = new List<string>();

    AutConnList connectionList = new AutConnList();
    connectionList.Refresh();

    for (int i = 1; i <= connectionList.Count; i++)
    {
        IAutConnInfo sessionInfo = (IAutConnInfo)connectionList[i];
        sessions.Add(sessionInfo.Name);
    }

    return sessions;
}

I compile the code to both .NET Framework (4.6) and .NET Core (3.0) as it is intended as a library used by many different programs. The multi-compiling is done by adding the following line to the .csproj file:

<TargetFrameworks>netcoreapp3.0;net46</TargetFrameworks>

The method works as intended, when consumed from .NET Framework applications, but when I try to consume it from .NET Core, I get the following exception:

Retrieving the COM class factory for component with CLSID {9DF30780-6F18-11D0-910D-0004AC3617E1} failed due to the following error: 80040154 Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)).

I have tried solutions from different posts about similar issues (like this), but without luck. Also, I haven't found any other posts, where the problem only occurs in a specific framework.

I dont know if it has anything to do with the differences in referenced assemblies, but the error code doesn't really suggest that?

enter image description here

Have anyone encountered similar issues, and if so, how did you solve it?

Jakob Busk Sørensen
  • 5,599
  • 7
  • 44
  • 96
  • 2
    It has nothing with .NET references, it's only a COM registration issue. Either the COM "server" is not registered, or it's not registered in the corresponding registry (to simplify: if COM client is 32-bit, COM server must be registered in 32-bit registry, if COM client is 64-bit, COM server must be registered in 64-bit registry) – Simon Mourier Mar 02 '20 at 13:49
  • @SimonMourier that makes sense. But it still doesn’t make sense, why the code works in .NET Framework, but not in .NET Core? – Jakob Busk Sørensen Mar 02 '20 at 16:41
  • 2
    Well, the problem is still a registration issue, and basically anything can happen between "the code works in .NET framework" and "the code works in .NET Core". You can use ProcMon tool from sysinternals, filter on the process, and monitor registry access to see what's going on. – Simon Mourier Mar 02 '20 at 16:52
  • @SimonMourier thanks, I'll see if I can get that to work, and see if it can teach me anything... – Jakob Busk Sørensen Mar 02 '20 at 19:27

0 Answers0