2

I'm porting a .Net framework projet to .Net 5. This project uses an external library which seems to be compiled against .Net Framework 2 (I see mscorlib 2.0 in the references in dotPeek). I don't have the sources of this dll, and rewriting it from scratch is not possible.

I've seen here that .Net core offers some compatibility shims, and if the apis are covered, it may load alright.

I have loaded the assembly in the .Net Portability Analyzer which gives me these results

.NET,Version=v5.0 .NET Core,Version=v3.1 .NET Standard + Platform Extensions,Version=v2.0 .NET Standard,Version=v2.1
100 100 62.5 100

In the details section I can see the missing target members for the .Net standard 2.0 and that everything is supported for the other platforms.

Target member .NET,Version=v5.0 .NET Core,Version=v3.1 .NET Standard + Platform Extensions,Version=v2.0 .NET Standard,Version=v2.1 Recommended changes
T:System.Runtime.InteropServices.TypeLibTypeAttribute Supported: 5.0+ Supported: 2.0+ Not supported Supported: 2.1+
M:System.Runtime.InteropServices.TypeLibTypeAttribute.#ctor(System.Int16) Supported: 5.0+ Supported: 2.0+ Not supported Supported: 2.1+
T:System.Runtime.InteropServices.ImportedFromTypeLibAttribute Supported: 5.0+ Supported: 2.0+ Not supported Supported: 2.1+ Remove usage.
M:System.Runtime.InteropServices.ImportedFromTypeLibAttribute.#ctor(System.String) Supported: 5.0+ Supported: 2.0+ Not supported Supported: 2.1+ Remove usage.
T:System.Runtime.InteropServices.TypeLibVersionAttribute Supported: 5.0+ Supported: 2.0+ Not supported Supported: 2.1+
M:System.Runtime.InteropServices.TypeLibVersionAttribute.#ctor(System.Int32,System.Int32) Supported: 5.0+ Supported: 2.0+ Not supported Supported: 2.1+

If I interpret this correctly, my dll should run fine in my .Net 5 project. I have copied my dll in the project directory, set it to copy to the output directory and added it in the references.

Now when the code runs, I get an exception :

Retrieving the COM class factory for component with CLSID {51A3A6E0-1414-11D7-BD2E-08004608C318} failed due to the following error: 80040154 Classe non enregistrée (0x80040154 (REGDB_E_CLASSNOTREG)).

After more searches I set the target platform to x86 instead of Any CPU, but the exception remains.

Do you have any ideas to make this work ?

Nicolas C
  • 752
  • 5
  • 18
  • Have you registered the COM dll by running `regsvr32` from an administrator command-line? – Matthew Watson Oct 19 '21 at 08:21
  • Your error seems to be not due to assembly incompatibility with net5. Looks like the library try to use COM object, which is not registered. The easiest way to check this hypothesis is to run .net framework version of the app and check if the problem persist. – Serg Oct 19 '21 at 08:27
  • Indeed I tried with a .Net Framework project and I get the same error. I tried running regsrv32 on the dll but it is not a COM object so I get the error The module 'mydll.dll' was loaded but the entry-point 'DllRegisterServer' was not found. Make sure that 'mydll.dll' is a valid DLL or OCX file and then try again – Nicolas C Oct 19 '21 at 08:41
  • .NET 5 (or above, and any .NET Core versions) and .NET Framework should *basically* be considered as completely separate universes; it is **not expected** that they can talk to each-other, *except* when the ".NET Framework" library has been actually been explicitly built against .NET Standard as the shared language. That isn't the case here, so: personally I would have zero expectation of this working. How big is the dll here? Is decompiling it for reverse engineering a possibility (noting also the legal implications if this is 3rd-party work)? – Marc Gravell Oct 19 '21 at 08:41
  • 1
    You've got an interop assembly, automatically generated from the COM component's type library. You cannot register it with regsvr32, it is merely .NET glue to make the component usable in a .NET program. Finding the actual component is required to get ahead, be sure to use the author/vendor's installer to get it properly deployed onto your machine. – Hans Passant Oct 19 '21 at 10:04

1 Answers1

1

So Hans Passant was right (cheers), this is an interop assembly, and the issue was with the related COM compenent.

Once the COM component was correctly registered, the interop assembly started working correctly, in the .Net Framework project but also in the .Net Core project, so the compatibility shims kicked in correctly and the api calls are relayed from .Net Core to the Interop assembly and to the COM component.

I'm a bit flabbergasted that the compatibility goes all this way down, but it's good news.

Nicolas C
  • 752
  • 5
  • 18