Wasm: Add hard coded mappings for mono js interop compatibility #8306
Conversation
MichalStrehovsky
left a comment
MichalStrehovsky
left a comment
There was a problem hiding this comment.
Looks good otherwise! Glad to hear you're making progress with Uno!
| @@ -0,0 +1,54 @@ | |||
|
|
|||
There was a problem hiding this comment.
src/BuildIntegration might be a better spot for this - I think eventually we'll need the dotnet build integration to do something with this file.
There was a problem hiding this comment.
moved to BuildIntegration/WebAssembly, or you'd rather not have the subdirectory?
| @@ -0,0 +1,49 @@ | |||
| using System; | |||
There was a problem hiding this comment.
Could you add copyright header?
| </PropertyGroup> | ||
|
|
||
| <ItemGroup> | ||
| <PackageReference Include="Microsoft.JSInterop" Version="3.1.0" /> |
There was a problem hiding this comment.
Is this used? Or do we expect this to be used?
If not, we might be able to just throw the InternalCalls into CoreLib.
There was a problem hiding this comment.
Dont need it for this at least, so have removed.
| // Hard coded InternalCall mappings for mono interoperability | ||
| if (callee.IsInternalCall) | ||
| { | ||
| var ecmaType = callee.OwningType as EcmaType; |
There was a problem hiding this comment.
Nit: casting to MetadataType might be better - we don't need anything specific to EcmaTypes here and MetadataType would also work if we end up needing this for things that are not backed by physical IL on disk (EcmaType represents just the types that exist in IL assemblies on disk - MetadataType is more general and includes things the compiler created out of thin air).
| var coreRtJsInternalCallsType = _compilation.TypeSystemContext | ||
| .GetModuleForSimpleName("CoreRT.WebAssembly.MonoBridge") | ||
| .GetKnownType("CoreRT.WebAssembly.MonoBridge", "InternalCalls"); | ||
| callee = coreRtJsInternalCallsType.GetMethod(callee.Name, null); |
There was a problem hiding this comment.
| callee = coreRtJsInternalCallsType.GetMethod(callee.Name, null); | |
| callee = coreRtJsInternalCallsType.GetMethod(callee.Name, callee.Signature); |
There was a problem hiding this comment.
Bah, never mind. I just looked what Mono is doing and the sig doesn't matter to them.
I guess messing up the sig will lead to fun debugging time.
There was a problem hiding this comment.
Seems like the right thing to do, will change.
| if (metadataType != null && (metadataType.Namespace == "WebAssembly.JSInterop" && metadataType.Name == "InternalCalls" || metadataType.Namespace == "WebAssembly" && metadataType.Name == "Runtime")) | ||
| { | ||
| var coreRtJsInternalCallsType = _compilation.TypeSystemContext | ||
| .GetModuleForSimpleName("CoreRT.WebAssembly.MonoBridge") |
There was a problem hiding this comment.
Sorry - didn't notice this earlier. We have a convention here that these kinds of libraries are called "System.Private.*".
This is hardcoded in some places, like here:
Lines 10 to 13 in 9fd5738
This makes sure they get properly packaged and binplaced for the dotnet integration.
Can you name this to something like System.Private.WebAssembly?
2 participants
This PR provides hard coded mappings to a new assembly to enable CoreRT to be a drop in replacement regards the JS interop for mono based frameworks. It follow the discussion at #8303
So far I've just tried to bring up Uno (https://github.com/unoplatform/uno) and this is one of the blockers. I've added a new project to provide an implementation for the mappings, but maybe that would be better outside of CoreRT, in another GitHub repo, and just some instructions added to the docs? Because I'm not sure what direction is best for that, I've not attempted to package this new assembly into nuget.
closes: #8303