[6.1] Code Pruning Changes which Resources are Obfuscated

[kevinmmccormick]

In our project we use a lot of reflection (primarily due to databinding in Windows Forms) so we decided to disable Code Pruning in SmartAssembly (adding the DoNotPrune to many of our classes became tiring and we have very little prunable code). We are using SA 6.1. We are not using Resource Compression/Encryption.

Upon disabling pruning, we noticed that another part of our code that picks up resources via Reflection stopped working.

We compared a pruned+obfuscated EXE with an obfuscated-only EXE and noticed that in the pruned EXE, *some* resources were not renamed/obfuscated, while in the obfuscated only EXE, *all* of the resources were renamed/obfuscated.

We also compared using DLLs and it seemed to have the same behavior: when pruning was enabled, some of the resources were obfuscated, but with pruning disabled, all of the resources were obfuscated. Here's the tough part: there doesn't appear to be any pattern to which resources are obfuscated, and which ones aren't.

We're not entirely sure why this is occurring, and we're kind of at a loss to figure out what to do.

[Brian Donahue]

If SmartAssembly has to rename a type, then it has to rename the resources for that type to match - ie if a type names Form1 is renamed, then Form1.resx has to be renamed too. So it is not obfuscating the resources, it's renaming them to match the name of the type which uses them.

In executables, everything can be renamed and internalized. With DLLs, however, the behavior is different because of course renaming will break all the entry points and render it useless. So SA will not rename any methods or properties that have the "public" access modifier declared on them.
_________________
Brian Donahue
Technical Support
Red Gate Software Ltd.
44 (0)870 160 0037 ext 8521
US and CAN 1-866-RED GATE ext 8521