Error MSB4057 ("the target 'ResolveIkvmRuntimeAssembly' does not exist in project")

[nico-csp]

Background

Originally posted in https://github.com/ikvmnet/ikvm/discussions/453#discussioncomment-7751379

Newer versions of IKVM are raising MSB4057, when a Maven repository is referenced.

Versions

IKVM V8.6.4 was ok, V8.7.4 shows this symptom.

Frame Conditions

A JAR file is referenced using a Maven reference (either local directory or remote server).

Observation

mvn Works

I tried to download the JAR file in question by calling mvn directly in terminal. It works.

ikvm Does Not Work

Even after downloading the package (so that it is avail in ~/.m2/repository/), building of the project fails with exceptions within IKVM. For all the following tests, packages are already downloaded into previously mentioned directory.

The symptoms differ, depending on whether I am configuring my private repo using <MavenAdditionalRepositories> or not (settings.xml always contains the URL, though).

Using <MavenAdditionalRepositories>

When <MavenAdditionalRepositories> is used, I am getting

for each project, which depends on the IKVM-project, which should provide the JAR. The latter mentioned project has error MSB4057 ("The target 'ResolveIkvmRuntimeAssembly' does not exist in project"; freely translated from German by me).

The result stays the same, even when I remove bin and obj directories in that project.

No <MavenAdditionalRepositories> (URL only in settings.xml)

It seems that only https://repo1.maven.org/maven2 is scanned by IKVM.

There are two identical warnings and two errors in the project:

• WARNING (appears twice): Could not find artifact xxxx in central (https://repo1.maven.org/maven2/)
• ERROR: Missing artifact descriptor for xxxx
• ERROR:

  DependencyResolutionException: Could not find artifact xxxx in central (https://repo1.maven.org/maven2/)
  bei org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(RepositorySystemSession session, DependencyRequest request)
  bei IKVM.Maven.Sdk.Tasks.MavenReferenceItemResolve.ResolveCompileDependencyGraph(IkvmMavenEnvironment maven, RepositorySystemSession session, IList`1 repositories, IList`1 items) in C:\w\ikvm-maven\src\IKVM.Maven.Sdk.Tasks\MavenReferenceItemResolve.cs:Zeile 254.
  bei IKVM.Maven.Sdk.Tasks.MavenReferenceItemResolve.ResolveReferences(IList`1 repositories, IList`1 items) in C:\w\ikvm-maven\src\IKVM.Maven.Sdk.Tasks\MavenReferenceItemResolve.cs:Zeile 193.
  bei IKVM.Maven.Sdk.Tasks.MavenReferenceItemResolve.Execute() in C:\w\ikvm-maven\src\IKVM.Maven.Sdk.Tasks\MavenReferenceItemResolve.cs:Zeile 151.
  ArtifactResolutionException: Could not find artifact xxxx in central (https://repo1.maven.org/maven2/)
  bei org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(RepositorySystemSession session, Collection requests)
  bei org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(RepositorySystemSession session, DependencyRequest request)
  ArtifactNotFoundException: Could not find artifact xxxx in central (https://repo1.maven.org/maven2/)

Version History

Tested with a local repository directory. This one works (older versions, before update):

This one works, too:

As soon as I upgrade IKVM, it breaks (MSB4057):

[wasabii]

So, the lock0 message. That's what I'm working on now. And I think it's the last issue. Got tracing enabled, and I see:

Linking native method: sun/nio/ch/FileDispatcherImpl.lock0(Ljava/io/FileDescriptor;ZJJZ)I, class loader = null, short = Java_sun_nio_ch_FileDispatcherImpl_lock0, long = Java_sun_nio_ch_FileDispatcherImpl_lock0__Ljava_io_FileDescriptor_2ZJJZ, args = 30
UnsatisfiedLinkError: sun/nio/ch/FileDispatcherImpl.lock0(Ljava/io/FileDescriptor;ZJJZ)I

This only happens when running on win-x86. So what's happening here is the native function lookup for sun/nio/ch/FileDispatcherImpl.lock0. Taking a look at the symbol table for nio.dll for win-x86, I see that the function has a stdcall suffix of @36, actually. Not @30, as would be indicated by the calculated argument length.

So there's our issue. But where is the extra six bytes coming from. It's beacuse in JNIFrame:GetFuncPtr, we're adding sizeof(jboolean) to sp for the two boolean arguments of the native method. jboolean being defined in C# to sbyte. So we're missing 3 bytes per boolean. jboolean is typedefed to unsigned char in C. Which is normally 1 byte. Except in stdcalls, where it gets aligned to 4 bytes. So there's our missing 3 bytes.

[wasabii]

Should be solved in 8.7.3, which is building now.

[wasabii]

IKVM.Maven.SDK 1.6.3 also released.

[wasabii]

The issue here was that the MSBuild you were running was running in 32bit mode on Windows. And there was some errors in IKVM 8.7 regarding looking up native JNI functions on win-x86. stdcall suffix.