Replies: 1 comment 1 reply
-
Is there a specific problem that is being solve in this case? Light up scenarios are relatively common in .NET - one assembly that branches based on environment. The JIT optimizes these paths and elides untaken paths like I don't know the best way to create platform specific builds, but that sounds like a good discussion for dotnet/runtime. Feel free to tag me and I can alert others. |
Beta Was this translation helpful? Give feedback.
-
@AaronRobinsonMSFT
I figured while I have your attention, I'd ask this other question that you might have some idea for.
I am trying to figure out a way to produce platform/OS specific assemblies for IKVM. That is, IKVM.Java would come in three versions: Windows, Linux and OS X. This is pretty easy to do for the Core RT, since .deps.json seems to work properly to include runtimeTargets RID based assemblies.
Framework however. Any ideas?
I thought through whether it would be possible to have a module initializer in IKVM.Runtime that loads the proper IKVM.Java. Can't work, since IKVM.Java is loaded before IKVM.Runtime in most cases. I thought that it might be possible to use something like Type Forwards, but this can't work because there's no way to stick a hook anywhere to load the right assembly before the Type forwards end up trying to load the target assembly.
My last remaining idea is to inject a module initializer into every IKVM application. But, this requires ... doing that. Which I could accomplish in the happy path of using the IKVM NuGet package. Could have MSBuild targets that are transitiive through to the end user app and insert the module initializer. But, that is pretty complicated, requires explicit support for different languages (F# comes to mind, etc).
Any ideas on your end?
Beta Was this translation helpful? Give feedback.
All reactions