Add trimming annotations to DotNetObjectReference #41610
Conversation
DotNetDispatcher has some unbounded reflection against DotNetObjectReference Types that the trimmer can't understand. Adding trimming annotations to tell the trimmer to preserve the public methods on the TValue of DotNetObjectReference instances, so the JSInvokable methods won't be trimmed. See dotnet/maui#6965
src/JSInterop/Microsoft.JSInterop/src/Infrastructure/DotNetDispatcher.cs
Outdated
Show resolved
Hide resolved
TanayParikh
added
feature-blazor-jsinterop
|
Related: #38044 |
|
FYI the PR that re-enables trimming analysis on the solution found a number of trimming warnings in JSInterop. Not sure if related to reported trimming related runtime errors. |
|
Looking through the warnings on #41683 (comment), those are different warnings. This one was being suppressed on the whole DotNetDispatcher class. I am removing the suppression with this PR. |
Remove the breaking change to only allow methods on the TValue type of IDotNetObjectReference. If a caller provides a base class to the TValue of DotNetObjectReference, and a derived type as the actual instance, only the base class's methods will be preserved. This allows for the current behavior to be preserved, at the cost of not being fully trim-compatible. In order to make it fully trim-compatible, we will need to introduce a new API that can be made trimming compatible.
| _cachedMethodsByAssembly.Clear(); | ||
| _cachedMethodsByType.Clear(); | ||
| _cachedConvertToTaskByType.Clear(); |
There was a problem hiding this comment.
Unrelated to this change - but that's where I noticed this. These caches will effectively disable support for unloadable (collectible) assemblies - since they hold a string reference to the Type. Would be really nice if we didn't introduce more hurdles in this space in the new frameworks.
There was a problem hiding this comment.
@vitek-karas that's fair, but at the same time its a trade-off between perf and correctness on a very concrete scenario. Do we have a design/proposal on how to deal with these two concerns that we could apply across all frameworks?
In any case, that's something we should discuss outside of this PR, but if we come up with a reasonable design for it, I think we would incorporate it.
|
Any more feedback here? Or is this good to merge? |
|
@eerhardt I think it is good to merge. To be fair, I am not an expert in the trimming area, but as far as I understand, the changes make sense. |
ghost
added this to the 
DotNetDispatcher has some unbounded reflection against DotNetObjectReference Types that the trimmer can't understand. Adding trimming annotations to tell the trimmer to preserve the public methods on the TValue of DotNetObjectReference instances, so the JSInvokable methods won't be trimmed.
See dotnet/maui#6965
cc @vitek-karas