With #80246, we added a feature switch for RuntimeFeature.IsDynamicCodeSupported. Previously when you published a trimmed CoreCLR app, RuntimeFeature.IsDynamicCodeSupported was hard-coded to true, so any logic switching on that property was eligible to be trimmed. For example:
|
RuntimeFeature.IsDynamicCodeSupported ? |
|
new ReflectionEmitCachingMemberAccessor() : |
|
new ReflectionMemberAccessor(); |
When you publish a CoreCLR trimmed app, the ReflectionMemberAccessor class could be trimmed. Now that we have a feature switch, the property is no longer a constant.
We could enable this by setting featuredefault=true in the ILLink.Substitutions.xml file, but that runs into the issue described in #96539.
This issue is to track enabling this for trimmed CoreCLR applications. It is blocked by #96539.
With #80246, we added a feature switch for
RuntimeFeature.IsDynamicCodeSupported. Previously when you published a trimmed CoreCLR app,RuntimeFeature.IsDynamicCodeSupportedwas hard-coded totrue, so any logic switching on that property was eligible to be trimmed. For example:runtime/src/libraries/System.Text.Json/src/System/Text/Json/Serialization/JsonSerializerOptions.cs
Lines 599 to 601 in b900a09
When you publish a CoreCLR trimmed app, the
ReflectionMemberAccessorclass could be trimmed. Now that we have a feature switch, the property is no longer a constant.We could enable this by setting
featuredefault=truein the ILLink.Substitutions.xml file, but that runs into the issue described in #96539.This issue is to track enabling this for trimmed CoreCLR applications. It is blocked by #96539.