我的雇主在我们所有的.Net制作软件上使用Dotfuscator。因此，我们绝对禁止使用任何内置数据绑定或任何反映属性/函数名称的东西 - 因为dotfuscator会更改它们，因此任何立即绑定并且不可挽回地破坏。
我一直在脑子里推翻这个逻辑，它开始受到伤害。 必须是一种避免这种僵局的方法，它的范围太宽，而且根本没有明显的解决方案可以逃脱我们。
那么，如何用混淆反思？有什么诀窍？据推测，必须有足够智能的商业混淆器来解决问题。我们的版本有哪些选项？
答案 0 :(得分：3)
我们对Dotfuscator进行了一些改进，这些改进应该有助于缓解与数据绑定相关的问题。 2008年3月在4.3.100版本中添加了智能混淆功能，以静态分析程序集并自动排除已知会导致运行时错误的重命名/删除项。我们一直在扩展和增强这一功能，今天的Dotfuscator围绕标准数据绑定方案工作，通常没有最小的额外配置。
即使Smart Obfuscation没有捕捉到您的每个场景，也可以通过使用自定义排除规则（包括RegEx模式匹配类型）来定义自定义规则以排除某些类型或继承层次结构的属性。您还可以使用System.Reflection.ObfuscationAttribute属性修饰项目，以确保在通过Dotfuscator运行时将其排除在重命名或删除之外。
如果从XAML标记绑定到代码隐藏中的类型，则最后几个版本支持重命名XAML / BAML以匹配后面的代码。当标记中的符号与代码定义不匹配时，这可以改善整体强化并消除整个问题。
我建议使用类似于您希望在应用程序中使用的数据绑定的几个简单的概念验证应用程序，并通过Dotfuscator运行它们以查看它处理它们的程度。如果您发现Smart Obfuscation未自动排除数据绑定目标的任何情况，请将其发送至support@preemptive.com。我们一直在寻找定义明确的方案来改进产品。
答案 1 :(得分：0)
混淆器的工作是打破源代码中可见的关系，使得它们在生成的可执行代码中不再明显。 Reflection依赖于诸如“这段代码所请求的属性是由该段代码定义的属性”之类的关系。因此，混淆和反射不能很好地相互作用就不足为奇了。
重命名属性只是混淆的零度。一个非平凡的混淆器也会做一些事情，比如将属性拆分为两个，这样在源代码只提到属性P的地方，一些运行时代码将使用P1，而一些运行时代码将使用P2，并且会有足够的它们之间的分配使得属性在需要时具有正确的值，但也有寄生分配，以便它们在不需要时不具有正确的值。这不仅仅是P已被重命名：不再是属性P.
我不知道为什么你认为反思和混淆是“广泛而基本的”：在宏大的编程方案中，反思和混淆都是相当罕见的，并且它们的使用之间没有相关性，所以我不知道我想很多人都试图同时拥有这两者。
缺乏反思只是混淆成本的长项列表中的一项。如果决定使用混淆的人不是安全专家，请尝试将其混淆，使得混淆的成本非常高，而且肯定会被低估。