[netcore beta] Trying to export methods -> call them from Java - am I doing something wrong?

Hello there, I'm still hoping that I'm just doing something wrong when configuring the solution, but I'm not making any progress.

I have a student project where I shall implement some kind of plugin system to integrate .NET into a monolithic Java product. After implementing a prototype with RGiesecke's nuget package, it somehow broke (not finding il(d)asm.exe anymore) and I'm now trying to implement the same thing with your extended solution - and targeting netcore instead of framework.

Problem:

When trying to execute a C# method from Java, there's an Invalid memory access error.

Exception in thread "main" java.lang.Error: Invalid memory access
    at com.sun.jna.Native.invokeInt(Native Method)
    at com.sun.jna.Function.invoke(Function.java:426)
    at com.sun.jna.Function.invoke(Function.java:361)
    at com.sun.jna.Library$Handler.invoke(Library.java:265)
    at com.sun.proxy.$Proxy0.Test(Unknown Source)
    at bla.bli.blub.dlltest.DllTest.main(DllTest.java:14)

When my configuration still worked with RGiesecke's package, the setup below worked (though, target was framework). Now when trying to do this with your extension for netcore projects, there seems to be a problem. I tried to provide all the info I have to reproduce this issue below and also attached the projects here: Lib.zip JavaExample.zip

If you need more information, please let me know.

Now to my code:

C# .NET Core Library project ("Lib")

namespace Lib
{
    public class LibClass
    {
        [DllExport]
        public static int Test(int input)
        {
            return 40 + input;
        }
    }
}

Java Maven project

import com.sun.jna.Library;
import com.sun.jna.Native;

public class DllTest {
    public static void main(String[] args) {

        ILib libClass = Native.load(
"path\\to\\project\\Testing\\Lib\\bin\\x64\\Debug\\netcoreapp3.0\\Lib",
                ILib.class);

        int result = libClass.Test(2);
        System.out.println(result);
    }

    public interface ILib extends Library {
        public int Test(int input);
    }
}

with the Maven dependency

<dependency>
    <groupId>net.java.dev.jna</groupId>
    <artifactId>jna-platform</artifactId>
    <version>5.5.0</version>
</dependency>

Steps to configure the solution:

- add nuget package (1.7-beta) to C# project
- place DllExport.bat into solution folder
- execute command "DllExport.bat -action Configure"
- check the project "Lib\Lib.csproj"
- select "x64" radio button
- check "PE Check IL code"
- check "Use our IL Assembler (...)"
The other values were left on their defaults.

Thanks for the report and especially for the demo projects!

@DevSnobo, I already voiced about Invalid memory access, for example, here: https://github.com/3F/DllExport/issues/26#issuecomment-278075949

Thus please check this out!

Also I remember some problems exactly with JNA implementation, but I don't remember where I wrote about this. Hmm, here's other related issue anyway: https://github.com/3F/DllExport/issues/30

I'll try to inspect your files later. But before, can you also try something:

Try to check it with C/C++ project just to isolate JVM/JNA/... problems.
Try with .NET Framework target platform to specify .NET Core problems in 1.7-beta release.
Try with unchecked option "Use our IL Assembler (...)" to exclude problems with my custom assembler on coreclr
And the same items but for x86 architecture.

Thanks!

Thanks for your reply! I will try to work my way through your list today.

For a start, changing the platform to x86 did result in an

UnsatisfiedLinkError: (...) "%1 is not a valid Win32 application."

Next I tried unchecking the option "Use our IL Assembler", but the result after changing back to x64 and rebuilding resulted in ildasm.exe not being found. (trying the same with x86 resulted in the UnsatisfiedLinkError again)

Now I got to test this with a simple .NET Framework project:

exact same method and naming
x64 platform
configured with DllExport, the options x64 and "Use our IL Assembler" checked

Result: it works, the method returns 42

It seems to me there is a problem in the 1.7-beta release. Would you agree to this?

Many various problems from your case. Are you sure that you have all required .NET Core components? What used VS version by the way?

Can you show result for the following command below. Installed .NET Core 3 for VS 16 should contain this workload:

vswhere -requires Microsoft.NetCore.Component.SDK

VS 15 and SDK 2 probably this:

vswhere -requires Microsoft.Net.Core.Component.SDK

'vswhere' tool can be found now inside Visual Studio\Installer folder on your machine

Also! Try to check your case via any C/C++ project instead of java. Because it more like JNA problems. I'm not sure, but I just don't remember this problems for my tests with native C++

Please don't worry if you can't. I'll definitely review this problem later, just no time today. Thank you again for the detailed info. I really appreciate it!

It seems to me there is a problem in the 1.7-beta release.

1.7 will provide first .NET Core support. 1.6.x and less releases provides only .net framework support. See details in related issue and PR about the first beta release.

On 25.11.2019 12:21, Robin Fritz wrote:

Thanks for your reply! I will try to work my way through your list today.

For a start, changing the platform to x86 did result in an

|UnsatisfiedLinkError: (...) "%1 is not a valid Win32 application." |

Next I tried unchecking the option "Use our IL Assembler", but the result after changing back to x64 and rebuilding resulted in ildasm.exe not being found. (trying the same with x86 resulted in the UnsatisfiedLinkError again)

Now I got to test this with a simple .NET Framework project:

exact same method and naming

x64 platform

configured with DllExport, the options x64 and "Use our IL Assembler" checked

Result: it works, the method returns 42

It seems to me there is a problem in the 1.7-beta release. Would you agree to this?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/3F/DllExport/issues/125?email_source=notifications&email_token=AAYYT7MRZKLS63LFQI6VAO3QVOKILA5CNFSM4JQSHX52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFBWH3I#issuecomment-558064621, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYYT7PH35C6EKZDAKFYQZLQVOKILANCNFSM4JQSHX5Q.

Thank you for taking the time to reply!

I have Visual Studio Professional 2019 (VS 16) installed.

Command output here:

Visual Studio Locator version 2.7.1+180c706d56 [query version 2.3.2200.14893]
Copyright (C) Microsoft Corporation. All rights reserved.

instanceId: cb55b3bc
installDate: 11/11/2019 11:43:37
installationName: VisualStudio/16.3.9+29509.3
installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional
installationVersion: 16.3.29509.3
productId: Microsoft.VisualStudio.Product.Professional
productPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv.exe
state: 4294967295
isComplete: 1
isLaunchable: 1
isPrerelease: 0
isRebootRequired: 0
displayName: Visual Studio Professional 2019
description: Professional IDE best suited to small teams
channelId: VisualStudio.16.Release
channelUri: https://aka.ms/vs/16/release/channel
enginePath: C:\program files (x86)\microsoft visual studio\installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service
releaseNotes: https://go.microsoft.com/fwlink/?LinkId=660893#16.3.9
thirdPartyNotices: https://go.microsoft.com/fwlink/?LinkId=660909
updateDate: 2019-11-20T10:15:56.9560767Z
catalog_buildBranch: d16.3
catalog_buildVersion: 16.3.29509.3
catalog_id: VisualStudio/16.3.9+29509.3
catalog_localBuild: build-lab
catalog_manifestName: VisualStudio
catalog_manifestType: installer
catalog_productDisplayVersion: 16.3.9
catalog_productLine: Dev16
catalog_productLineVersion: 2019
catalog_productMilestone: RTW
catalog_productMilestoneIsPreRelease: False
catalog_productName: Visual Studio
catalog_productPatchVersion: 9
catalog_productPreReleaseMilestoneSuffix: 1.0
catalog_productSemanticVersion: 16.3.9+29509.3
catalog_requiredEngineVersion: 2.3.2283.19382
properties_campaignId: 318456033.1561541929
properties_channelManifestId: VisualStudio.16.Release/16.3.9+29509.3
properties_nickname: 2
properties_setupEngineFilePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe

Currently, I can't check with a C/C++ project since I'm writing this at work. Maybe in the next few days, but you'd probably be faster. I have very little experience with C/C++ and even less with calling managed code.

I appreciate your help a lot

I see. Thank you for the new details. Looks like .NET Core workload is ok.

Anyway this week I allocated my little time for Conari support (my other related OS project). Its release was already delayed in past due to DllExport 1.7-beta. So I have no plan to change priority again. Later, I'll try to inspect this via JNA. As I said, at least native c++ was ok for me in 1.7-beta. But something strange is happening.

By the way, what about JNI ?! Can you also try it instead of JNA?

Anyone else, please also feedback about JNA and JNI with .net core projects. Thanks!

On 25.11.2019 16:07, Robin Fritz wrote:

Thank you for taking the time to reply!

I have Visual Studio Professional 2019 (VS 16) installed.

Command output here:

|Visual Studio Locator version 2.7.1+180c706d56 [query version 2.3.2200.14893] Copyright (C) Microsoft Corporation. All rights reserved. instanceId: cb55b3bc installDate: 11/11/2019 11:43:37 installationName: VisualStudio/16.3.9+29509.3 installationPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional installationVersion: 16.3.29509.3 productId: Microsoft.VisualStudio.Product.Professional productPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\devenv.exe state: 4294967295 isComplete: 1 isLaunchable: 1 isPrerelease: 0 isRebootRequired: 0 displayName: Visual Studio Professional 2019 description: Professional IDE best suited to small teams channelId: VisualStudio.16.Release channelUri: https://aka.ms/vs/16/release/channel enginePath: C:\program files (x86)\microsoft visual studio\installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service releaseNotes: https://go.microsoft.com/fwlink/?LinkId=660893#16.3.9 thirdPartyNotices: https://go.microsoft.com/fwlink/?LinkId=660909 updateDate: 2019-11-20T10:15:56.9560767Z catalog_buildBranch: d16.3 catalog_buildVersion: 16.3.29509.3 catalog_id: VisualStudio/16.3.9+29509.3 catalog_localBuild: build-lab catalog_manifestName: VisualStudio catalog_manifestType: installer catalog_productDisplayVersion: 16.3.9 catalog_productLine: Dev16 catalog_productLineVersion: 2019 catalog_productMilestone: RTW catalog_productMilestoneIsPreRelease: False catalog_productName: Visual Studio catalog_productPatchVersion: 9 catalog_productPreReleaseMilestoneSuffix: 1.0 catalog_productSemanticVersion: 16.3.9+29509.3 catalog_requiredEngineVersion: 2.3.2283.19382 properties_campaignId: 318456033.1561541929 properties_channelManifestId: VisualStudio.16.Release/16.3.9+29509.3 properties_nickname: 2 properties_setupEngineFilePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe |

Currently, I can't check with a C/C++ project since I'm writing this at work. Maybe in the next few days, but you'd probably be faster. I have very little experience with C/C++ and even less with calling managed code.

I appreciate your help a lot

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/3F/DllExport/issues/125?email_source=notifications&email_token=AAYYT7KARY3ZLXZUC7OMIADQVPEX5A5CNFSM4JQSHX52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFCKLCI#issuecomment-558146953, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYYT7JPI2F5MRMSI6TPCYTQVPEX5ANCNFSM4JQSHX5Q.

Well, the problem due to incorrect processing in my coreclr IL Assembler and more like others official MS versions that implements resolving of System.Private.CoreLib on the assembly stage for the PE module.

This is what I'm talking about, in #90 I already voiced about various base for system Object and this is it:

PE_dotnet_AssemblyRef_0x000A_coreclr_ilasm

As we can see, the correct number is 0x0006 (I mean, of course, only current assembly above) because AssemblyRef encoded into the low 2 bits of the number due to ECMA-335:

If e is a coded index that points into table ti out of n possible tables t0, ...tn-1, 
then it is stored as e << (log n) | tag{ t0, ...tn-1}[ti] using 2 bytes if the maximum 
number of rows of tables t0, ...tn-1, is less than 2^(16 – (log n)), 
and using 4 bytes otherwise.

In general, I confirm the bug.

We need to fix related processing in IL Assembler for our DllExport. I'll try to fix this week, maybe next. More probably I already know where to look this part of logic. Follow the news.

New version of my IL Assembler is just released. Now we can process this case via optional rebasing of the System Object in assembly!

I've already checked this case manually via 4.700.2 and all works like a charm. Soon I will implement the use of this new feature in our DllExport.

Please test applied solution through latest beta releases.

3F / DllExport