Dotfuscator 已知问题有哪些
除了稍微降低执行速度之外,使用 Dotfuscator 社区版是否存在任何已知问题?
在使用 dotfuscator 之前我应该更改代码中的任何内容吗?
我不确定,但是一旦客户报告了在使用 dotfuscator 发布之前不会发生的奇怪行为,所以我给客户提供了相同版本,但没有使用 dotfuscator,一切都恢复正常。
提前致谢。
Are there any known issues to using the Dotfuscator community edition except for it slowing down the execution speed a little bit?
Is there any thing that I should change in my code before using the dotfuscator?
I am not sure but once a client reported a strange behavior that was not happen before a release with dotfuscator, so I give the client the SAME release but without a dotfuscator and every thing return to normal.
Thanks in advanced.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果您使用Dotfuscator Community Edition(仅支持重命名),则不会对性能造成任何影响。遗憾的是,社区版中不包含可能对性能产生负面影响的转换,例如控制流混淆和字符串加密。
然而,正如 Stecya 所解释的那样,重命名可能会破坏各种在运行时而不是在静态分析期间确定行为的场景。就在我的脑海中,可能会破坏的场景包括使用反射(直接或间接地使用 Enum.Parse)、在非代码文件(例如 XAML)中引用代码以及自动序列化(没有显式地命名数据成员)。
If you are using Dotfuscator Community Edition (which only supports renaming), there will not be any hit to performance. Transforms that can negatively impact performance such as control flow obfuscation and string encryption are unfortunately not included in the Community Edition.
As Stecya explained however, renaming can break all sorts of scenarios where the behavior is determined at run-time instead of during static analysis. Just off the top of my head, scenarios that can break include using reflection (either directly, or indirectly by for example using Enum.Parse), having code references in non-code files (such as XAML), and automatic serialization (without explicitly naming data members).
您应该小心使用 dotfuscator,并仅混淆需要隐藏的部分。
例如,如果您使用反射,混淆可能会破坏代码
You should carefully use dotfuscator, and obfuscate only that parts that need to be hidden.
For example obfuscation may break code if you are using Reflection