Below is list of usages of legacy interop.

• Usage of BINDING.call_assembly_entry_point

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 68 in 730dac2

    await BINDING.call_assembly_entry_point(assemblyName, emptyArray, 'm');

  • this one is most problematic because it uses eval() which is CSP blocker
• Usage of BINDING.js_string_to_mono_string in invokeJSFromDotNet

  • aspnetcore/src/Components/Web.JS/src/Boot.WebAssembly.ts

    Line 124 in 730dac2

    return resultJson === null ? 0 : BINDING.js_string_to_mono_string(resultJson);

  • aspnetcore/src/Components/Web.JS/src/Boot.WebAssembly.ts

    Line 138 in 730dac2

    return BINDING.js_string_to_mono_string(resultJson);

  • this is potentially just dead code, if the user code doesn't use the obsolete IJSUnmarshalledRuntime
  • but I don't fully understand jsCallDispatcher and invokeJSJson use-cases
• usage of BINDING.unbox_mono_obj and BINDING.conv_string in readStringField which is part of renderBatch

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 127 in 730dac2

    const unboxedValue = BINDING.unbox_mono_obj(fieldValue as any as System_Object);

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 138 in 730dac2

    decodedString = BINDING.conv_string(fieldValue as any as System_String);

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 142 in 730dac2

    decodedString = BINDING.conv_string(fieldValue as any as System_String);

  • this is problematic from GC safety, for which we do have stop-gap solution.
  • this is probably not a problem for CSP as there is no bind/invoke and no eval()
• MonoHeapLock.stringCache is pointer hazard

  • aspnetcore/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts

    Line 139 in 730dac2

    currentHeapLock.stringCache.set(fieldValue, decodedString);

  • because BINDING.conv_string is already caching interned strings by their pointer (because they never move on GC)
  • any other strings do move and could be even collected, so the pointer could be pointing at different object and produce a) invalid value or b) crash even in single threaded app
  • this is problematic from MT GC safety, for which we do have stop-gap solution.

All of the uses prevent users trimming legacy interop dead code with <WasmEnableLegacyJsInterop>false</WasmEnableLegacyJsInterop>