Closed Kojoley closed 1 year ago
Those files are not supposed to be distributed alongside the tools. The tools don't consume the code within them.
Instead, the tools are passed options pointing to the runtime libraries you want to compile against during an invocation of the tools using the -reference and -runtime arguments.
Think of them like the C compiler not automatically including a version of glibc that you must use, but you being forced to link against a libglibc, or libc, or whatever, of whatever version you might want, during an invocation of the C compiler or linker.
This is to preserve the capability of mismatching the tools and the runtime. It is conceivable that a user might want to generate an assembly that links against an older version of IKVM.Runtime, for instance. Or, might want to use the .NET Core 3.1 version of the tool to generate a .NET Framework version of a library (cross compile from Linux/Mac targeting Windows).
It was the easiest and straightforward way to fix 'Run' button in VS.
I understand. But it also results in the inclusion of IKVM.Runtime and IKVM.Java (and a few other things, such as the native libraries) as referenced assemblies in the ikvmc executable's dependency graph, which isn't correct as ikvmc does not in fact reference those assemblies.
I run ikvmc from Visual Studio by configuring the Debug arguments to include the same contents as you would include if you were running it from outside Visual Studio: --reference, --runtime, etc..
Without this VS does not put dlls near the exe and run command fails.