Repository navigation
Remove DynamicDependency from ValueType in browser builds #47909
Description
By removing global [DynamicDependency(DynamicallyAccessedMemberTypes.PublicMethods, "System.Runtime.InteropServices.JavaScript.JSFunctionBinding", "System.Runtime.InteropServices.JavaScript")] attribute from System.ValueType we could keep only marshaling support for types that are used. The attribute needs to be used today because there is no reference to the assembly from managed code.
Activity
pavelsavara commentedon Jul 11, 2022
The landscape changed and the
ValueTypenow points to public typeJSFunctionBindingwhich points to internalJavaScriptExports. The situation is bit better because theJavaScriptExportscontains only methods which need to be reachable from JavaScript.In scenarios which use interop code directly, like projects with Console, HTTP client or WebSocket client naturally use JSFunctionBinding from the generated
[JSImport]code.But we still have the legacy interop code, which depends on many things in the
JavaScriptExportsclass. So at least for now, I don't think we could get rid ofDynamicDependencyonValueType.14 remaining items
vitek-karas commentedon Oct 31, 2022
Disabling trimming in the assembly is probably too much - all you need is to keep all the JSExport methods (and everything they depend on), the rest of the assembly should be trimmed as anything else.
I don't think we have anything in the linker which would do this currently. Even
AssemblyMetadata("IsTrimmable", "false")is undefined as far as I know - dotnet/linker#2991.I still think that assemblies should not be able to "root" themselves in the app - it's kind of a bad precedent. But the only other approach would require some kind of build-time tool which scans assemblies for the JSExport attribute and adds them to the "Roots" some other way. Which is equally bad.
I think this is up to you @pavelsavara to define the desired behavior - is you think that the best approach is to automatically root all JSExport methods (and probably without a way for the user to revoke that decision), then we will need to introduce some new feature into the linker to do this - either dotnet/linker#2991, or something else.
pavelsavara commentedon Oct 31, 2022
Let pause and have this issue collect community feedback for few months. I have no data if it really happens in user apps.
pavelsavara commentedon Oct 31, 2022
How does the
[UnmanagedCallersOnly]deal with the same issue ? Or any[ComVisible(true)]export ?marek-safar commentedon Oct 31, 2022
Yep, I agree this is not JS problem only but AFAIK we don't have a reliable way how to keep method (or even field) even if it's not used beyond
DynamicDependencywhich is not suitable here. Our workaround is not to trim user assembly at all where such scenario with JSExport occurs most often.I'd also not mix this with the concept of how to trim libraries in general, which is a similar but different problem.
vitek-karas commentedon Oct 31, 2022
Currently native hosting and COM are not supported with trimming, so we didn't even try to solve this.