-
Notifications
You must be signed in to change notification settings - Fork 419
Don't hide strings on methods where Exclude = True and ApplyToMember = True. #216
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
base: master
Are you sure you want to change the base?
Conversation
…ilyOrAssembly-property of FieldDefinition (now behaves like the method check. - InheritMap now also generates groups for virtual methods of props (set, get) and events (add, remove). - The group info is used to find out if any virtual method in the group belongs to a public type and therefore should be skipped. e.g. public interface implemented by internal class or vice a versa.
Solved my issue with stack overflow on .NET Core with small stacks due to massive creation of variables for constants in very large methods. Thx |
Filters are usually used to control the API surface on what should be changed or remain. Hiding strings, however, does not change API surface. So, it is optional to attach a filter to string hiding. Thus, at this time no plan to accept this pull request. |
The issue at hand here is that very very large assemblies will contain so much constant strings, the number of possible fields in a class is exceeded. Accepting this pull request will significantly lower the number of fields required. |
Does this topic work? |
@PatrickHofman please include PR in dot-blur form. |
|
Currently method bodies which have Exclude = True on them are still obfuscated.
This pull request will exclude method bodies when Exclude = True and ApplyToMember = True.
More on the repro for the problem this fixes.
Unobfuscated class:
This is now obfuscated as:
While it should preserve the strings since Exclude = True and ApplyToMembers = True.