-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Default IsDynamicCodeSupported feature switch to true for CoreCLR #80398
Comments
Tagging subscribers to this area: @dotnet/area-system-reflection-emit Issue DetailsWith #80246, we added a feature switch for 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 We could enable this by setting This issue is to track enabling this for trimmed CoreCLR applications. It is blocked by #96539.
|
@eerhardt is this still relevant for 8.0? |
This issue has been marked |
Moving to v9; assuming #96539 won't be done in v8. |
With #80246, we added a feature switch for
RuntimeFeature.IsDynamicCodeSupported
. Previously when you published a trimmed CoreCLR app,RuntimeFeature.IsDynamicCodeSupported
was 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
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.
The text was updated successfully, but these errors were encountered: