How to properly reference IKVM-created DLLs in depending projects properly?

[nico-csp]

Status Quo

• Project A references a JAR.
• During build, the DLL is created automatically; IkvmReference does the (good) job.

Next Level

• Project B depends on project A.
• Some of the classes in project A's JAR-DLL need to be returned into project B.

Issue

Visual Studio complains that references are missing. So what happends automatically to 100% in project A, obviously requires some hands-on in project B.

Best Solution?

What would be the best solution in that case?

Of course, I could simply create a direct reference to the file in project B. But it does not feel right. Isn't there some kind of automatics provided by IKVM? So that referencing project A is just enough?

[wasabii]

Got to add the reference to each project, just like normal assembly references. They are not transitive.

MavenReferences are.

[wasabii]

So here's the thing. We don't guarantee compatibility between any generated DLL and IKVM runtime. Between versions we may break that interface. In fact we are likely to do so for the foreseeable future.

We don't approve of uploading generated assembly to public nuget: it messee up dependencies. This is outlined in the README.

But if this is private nuget, with private JAR files, well then we don't care. But IkvmReference has no provisions for this. That said, you can probably get it working pretty automatically using IKVM.Net.SDK. I believe we added support for importing archives in that.

Also, DLLs aren't portable between Core and Framework.

[nico-csp]

I got your point and fully agree. Since the JAR files should only be used internally, we can accept the risk of broken interfaces in the future.

• We only would like to be able to use JAR files of our JAVA project directly in our .NET projects.
• However, it should be easy to set up in each .NET project; thus, it is out of question to modify each .csproj-file to mention all JAR files plus their dependencies.

It would be perfect to being able to create a package containing the JAR files, their dependencies and the reference to IKVM so that each .NET project is able to create the "JAR-DLLs" themselves using IKVM.

As far as I learned it so far (I might be terribly wrong), it is impossible as long as the JAR files cannot be uploaded to Maven repository.

The limitations of IKVM.Net.SDK as written in its readme make it impossible for us to use it either.

The solution, which seems to work in a first rough test was to directly include the generated DLLs in the .csproj file for having them included in the NuGet-package. Example for two JAR-DLLs:

	<ItemGroup>
	  <Content Include="bin\Release\DOTNETVERSION\jarlib1.dll">
	    <Pack>true</Pack>
	    <PackagePath>\lib\DOTNETVERSION</PackagePath>
	  </Content>
	  <Content Include="bin\Release\DOTNETVERSION\jarlib2.dll">
	    <Pack>true</Pack>
	    <PackagePath>\lib\DOTNETVERSION</PackagePath>
	  </Content>
	</ItemGroup>

replacing DOTNETVERSION by whatever is necessary.

Since IKVM-packages are referenced by version, I do not see a severe risk of broken interfaces.

The solution is not perfect (I don't like it much) -- but it works. We will use it unless pointed to alternatives, which might be better.

Thank you for your support, Jerome! :-)

[wasabii]

The limitations of IKVM.Net.SDK as written in its readme make it impossible for us to use it either.

Such as?

Since IKVM-packages are referenced by version, I do not see a severe risk of broken interfaces.

The problem ends up being version unification. Say you have three .NET projects: A, B and C. A depends on B and C. Imagine B depends on a Third Party Library (T). Imagine T uses IKVM. T however gets updated, and currently has a dependency on IKVM version 8.5.

Let's say C is your project. It generates your JAR files. It depends on IKVM 8.4.

Which version of IKVM should A use?

Standard Project/PackageReference unification will result in A depending on 8.5. Even though you told it to depend on IKVM 8.4, and you generated your JAR files against 8.4: at build time, project A will be upversioned to 8.5 because A depends on B depends on T depends on 8.5. So, 8.5 will be what is run, and it will be run using your 8.4 assemblies, which won't be compatible.

MavenReference takes care of this exactly how Project and PackageReference takes care of it: transitively communicating resolved versions across project/package boundaries, and applying unification rules, so that the version A runs will be 8.5. It then compiles assemblies, on the fly, for 8.5. Even if those assemblies are distributed by third party packages. Basically: everything gets recompiled for the actual version of IKVM that would be in use at runtime.

MavenReference results in every downstream project having it's OWN IkvmRefernce: thus, each project compiles a version of the JAR that is compatible with the version of IKVM that was resolved by Nuget after unification. The same as if you put IkvmReference in each project: each project would compile it's own: against it's own version of IKVM.

So it's not impossible to do what you're doing. But there's a very good reason we don't do it out of the box.

[wasabii]

This is why generally my recommendation would be to publish your jar files to an internal Maven repo. Same as you do your internal nuget packages. In fact, most nuget repositories people use support Maven just fine. Azure DevOps, GitHub packages, etc, all support publishing Maven packages.

[nico-csp]

At least in my current situation, it would not be a problem. But let me try the MavenReference tag.

I created a local Maven-Repository for testing. How can I make MavenReference picking up the JAR files from there?

There is a ~/.m2/settings.xml pointing to that local repository, but MavenReference does not seem to use it and looks in maven.org.

I have no experience with JAVA and Maven; so I am not sure, whether the issue is there or somewhere else. Could it be that I have to put something like a MavenRepository-Tag into my csproj file?

[nico-csp]

Ok, I searched in the code and found some hints to continue searching the internet and found #395. I will check that.

[nico-csp]

Ok, I created a local Maven-Repository-Directory, referenced it in the .csproj-File, put the JAR-files with appropriate BOM-files into that local directory structure and used MavenReference.

It works fine; my first tests did not succeed due to lack of knowledge about JAVA and Maven. Meanwhile I fixed all this issues here and there...

Thanks once more for your patience. Guess, we can really close this thread now. :-)