No compatible export signature was found in DLL - one more time

[tesla20000]

Context:

Visual Studio 2022 Windows 11 -64 latest version of J2534-Sharp

Two projects in same machine:

• one of them with Net Framework 4.8 - all works OK ( this project was created 2 years a go with older version of framework)
• next project, new test project is created from scratch with net framework 6.0 (also tested 7.0) on VS2022 and Win11-64. And then normally start WARNING : -> Warning | NU1701 | Package 'J2534-Sharp 1.0.0-CI00036' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework 'net7.0-windows7.0'. This package may not be fully compatible with your project.

Debug/Release same problem - connection is not possible with same hardware, because:

System.MissingMemberException HResult=0x80131512 Message=No compatible export signature was found in DLL C:\Program Files (x86)\PEAK-System\PCAN-PassThru API\04.04\x64\PCANPT32.dll Source=J2534-Sharp StackTrace: at SAE.J2534.APIFactory.GetAPI(String Filename) at PassThruXXXX.ConnectionManager.initialiseChannel(Enum protocolId) in C:\Users\xxx\source\repos\PassThruXXXX\PassThruXXXX\ConnectionManager.cs:line 158

This exception was originally thrown at this call stack: [External Code] PassThruXXXX.ConnectionManager.initialiseChannel(System.Enum) in ConnectionManager.cs

Issue #22 mention same problem, but @autokent never inform about how was solved with details. I just suspect, that after getting problem was changed by him net framework version to 4.x . For me - minimum version that I can install is .NET 5.0 - with same result - same exception on connection probe.

For me this happen, when is called: APIFactory.GetAPI(passThru).GetDevice();

[BrianHumlicek]

I'm not sure this is an issue with .NET flavors. 2534Sharp appears to be executing, and throwing an exception when 2534Sharp can't find all the specified functions within the target unmanaged driver. They are referened by name vs. by number, so maybe that has something to do with it? Either that or the call to Kernal32.dll is borked. You say this works when using .NET 4.8, can you confirm that it worked with the EXACT same PCANPT32.dll?

Brian

[tesla20000]

In VS2022 we have the ability to create, among others, two types of c # desktop projects, Windows Forms App.

One type is .NET Framework, the other is Windows Forms App. The .NET Framework type builds a project based on .NET 4.8, and the default - Windows Forms App project type builds a new project in the CORE environment - ie, .NET 5.0/6.0/7.0 -> . Your device question according PEAK PassThru API - YES - this was the same DLL used. I understand where such suspicions come from ;) However, yesterday when setting up a new project with selection: Windows Forms App (.NET Framework) i created a project with .Net4.8 and it helped me solve problem. Everything works for your code as long as .NetFramework is used, and attempts to .Net6.0 (Core) -> Fail. This is my final answer - how I fixed my problem.

So it's up to you to decide whether you will rebuild your library to .Net Core or not in the future ;) Users of this repo can safely use your J2534-Sharp lib for projects up to version 4.8, not for . net core 5.0 and above.

Regards.

[prj]

Works perfectly with PCAN DLL with .net core 3.1 and 5.0. Also PCAN DLL is really not the benchmark by which to measure anything, their J2534 implementation is lacking to say the least.

Your issue is most likely related to trying to use 64 bit DLL. I strongly recommend against doing that, use 32 bit DLL. Very few devices even provide a 64 bit dll, and of those that do few actually work right.

There is zero benefit to using a 64 bit DLL with J2534.

[BrianHumlicek]

prj's comments about about the 64bit DLL sounds very likely as the cause for the issue. I didn't think about that.

As for migrating to .NET standard, I have thought about it, but keeping up with the relatively short term support of .NET 5+ concerns me. .NET 4.8 currently has an indefinite lifetime, whereas .NET 5+ longterm support releases have 18 months at most I think.

Brian

[tesla20000]

I checked everything again. It turns out that a project created with .net 4.8 uses a dll like below:

And the project created with .net 6.0/7.0 uses dll as below.

Both dll versions are installed together with one installer from PEAK Can.

@prj was right. After changing the project settings from Any CPU to x86, the .NET7.0 project started working as well. The connection to the hardware was established without exception.

[prj]

Yup. Been there, done that, got the T-shirt ;) I was sure that was the problem from the beginning. Glad it works for you now!