error CS0100: The parameter name '__value' is a duplicate"

[ams-tschoening]

Not sure if this is related to #1 or something completely different, but after applying PR #2 I get an additional, but new error:

Schweregrad Code    Beschreibung    Projekt Datei   Zeile   Unterdrückungszustand
Fehler      ILT0014: Fehler beim Kompilieren des Interop-Quellcodes. Fehlerdetails finden Sie im Buildprotokoll.    Ams.Oms.Poc         

Some log file obj\x86\Release\ilc\ilclog.csv contains additional details:

"Message",Normal,"obj\x86\Release\ilc\intermediate\Ams.Oms.Poc.McgInterop\PInvoke.g.cs(3649,10): error CS0100: The parameter name '__value' is a duplicate"

The log contains multiple such statements, because the mentioned file contains multiple errors like the following:

// Signature, MapViewOfFile, [fwd] [return] [EETypeRva:0x000419B0] System_IntPtr____w64 int, [fwd] [in] [EETypeRva:0x000434A4] Microsoft_Win32_SafeHandles_SafeFileHandle__System_Private_CoreLib____w64 int, [fwd] [in] [EETypeRva:0x000419B0] int__int, [fwd] [in] [EETypeRva:0x000419B0] int__int, [fwd] [in] [EETypeRva:0x000419B0] int__int, [fwd] [in] [EETypeRva:0x000419B0] System_IntPtr____w64 int, 
[global::System.Runtime.InteropServices.McgPInvokeMarshalStub("IKVM.OpenJDK.Core, Version=8.1.7234.0, Culture=neutral, PublicKeyToken=null", "sun.nio.ch.FileChannelImpl", "MapViewOfFile")]
public static global::System.IntPtr MapViewOfFile(
            global::Microsoft.Win32.SafeHandles.SafeFileHandle__System_Private_CoreLib __value, 
            int __value, 
            int __value, 
            int __value, 
            global::System.IntPtr __value)

Using the same name __value multiple times clearly doesn't make much sense. This error is interesting because the generated code perfectly well fits to what the error message of #1 says and the function in this case is a native function which I didn't need to comment because it didn't trigger the error of #1, even though it looks pretty the same:

@DllImportAttribute.Annotation(value = "user32.dll", EntryPoint = "RegisterClipboardFormat")
private native static int _RegisterClipboardFormat(String format);

vs.

@DllImportAttribute.Annotation(value="kernel32", SetLastError=true)
private static native IntPtr MapViewOfFile(SafeFileHandle hFileMapping, int dwDesiredAccess, int dwFileOffsetHigh, int dwFileOffsetLow, IntPtr dwNumberOfBytesToMap);

The CN1-fork commented that whole stuff as well.

So it might be that this error and #1 have the same root cause, that IKVM tries to generate code which doesn't compile properly somewhere simply because using the wrong argument names. The original source code doesn't use those wrong names and I didn't find an obvious place where __value might come from as well.

OTOH, there are some differences, like can be in the following screenshots without and after applying the PR #2:

vs.

With applying the PR the compilation seems to get one step further, which means that without the PR #1 can't happen at the same stage like this issue from my understanding. Simply because the file of this issue PInvoke.g.cs doesn't exist yet.

[ams-tschoening]

There seems to be a workaround by not changing any code at all: The settings of the Release-build contain a checkbox if to use the .NET native toolbox for the build, which is enabled by default. By disabling that the build succeeds without any code change and is as fast as the Debug-build again. Before changing that, the Release-build took a lot longer as well.

Don't know what that means regarding actually calling native code, if that fails or not, because my app doesn't use those. I guess it would fail, depending on if it works in Debug or not. Additionally, I'm not sure if the Windows store accepts such a modified Release-build, but as UWP-apps aren't forced to use native code at all, I guess there's a good chance things are going to work.

[ams-tschoening]

[...]Additionally, I'm not sure if the Windows store accepts such a modified Release-build[...]

It sadly doesn't:

Package acceptance validation error: This package wasn't built for submission to the Store. Make sure you're uploading a Release build with the .NET Native tool chain enabled.

One can find many results regarding that topic and it seems that one simply needs to be compatible with the native toolchain and there's no workaround for that, regardless if the code is actually used or not.

The appli­cations are automatically compiled to native code before they reach consumer devices.

https://docs.microsoft.com/en-us/archive/msdn-magazine/2015/windows-10-special-issue/microsoft-net-net-and-universal-windows-platform-development#what-is-net-native

A good rule of thumb is to test your app this way periodically throughout development to make sure you identify and correct any issues that might come from the .NET Native compiler. There should be no issues in the majority of cases; however, there are still a few things that don’t play so nicely with .NET Native. Four-plus dimensional arrays are one example. Ultimately, your customers will be getting the .NET Native compiled version of your application, so it’s always a good idea to test that version throughout development and before shipping.

https://docs.microsoft.com/en-us/archive/msdn-magazine/2015/windows-10-special-issue/microsoft-net-net-and-universal-windows-platform-development#debug-versus-release-compile-configuration

Looks like one needs to fix those problems in IKVM somehow... In the best case I'm able to simply comment the code not needed or make other DLLs not depend on the failing IKVM.OpenJDK.SwingAWT-DLL anymore or stuff like that.

[wasabii]

I'm going to close this one, because whatever issue it was talking about seems no longer relevant.