这个问题很好地解释了这一点。我们有一个WinRT (Metro)应用程序包，我们在每次构建后都使用Dotfuscator进行混淆。由于Dotfuscator进行重命名的方式，我们现在需要手动重命名我们从Codebehind按名称调用的任何控件。如果不这样做，就会得到NullReferenceException。这有点烦人，但我们已经成功地跟上了它，并捕获了所有此类实例，但它非常耗时，而且我们总是有可能错过一个。
我想做的是能够创建一些单元测试来测试我创建的视图中的事件功能，但这只有在我可以在混淆版本中做到这一点时才有效。我知道我们可以调试已部署的应用程序包，甚至调试混淆的应用程序包(因为我们在项目中有.pdb文件)。
如果有人对这个或Dotfuscator有任何经验，并且知道更好的方法，我很乐意得到一些输入。理论上，我也可以创建一个测试，读取我们当前的"参考"Dotfuscator项目，并将其与代码隐藏中的所有命名控件进行比较，但这似乎是一个需要编写的测试，我根本不希望解析代码隐藏。它可能很简单(对于不同的简单定义)，就像在整个XAML文档中搜索[x:Name"*"]属性，然后在背后的代码和Dotfuscator项目文档中搜索带星号的值一样简单，值得庆幸的是，Dotfuscator项目文档只是XML。
如果您能提供任何帮助，我将不胜感激。我已经在先发制人的支持论坛上创建了一个主题。我使用的是Dotfuscator Professional(不是App Store版本)，并已更新到最新版本4.10。
*编辑25/4/13所以最后，虽然@ ianschool的建议很有帮助，但现在我实施了上面概述的解决方案:
枚举控件的字段
-确定哪些字段是属性，哪些是命名控件
-阅读. example .cs
查找所有按名称引用的字段，保存
注意:然后我使用一些Regex来过滤掉.cs文件本身声明的字段，因为它们是不必要的。
-在Dotfuscator项目文件中读取
解析后代。如果控件的名称出现在引用列表中，则断言它有一个具有给定name属性的子元素。
解决您的问题的最有效和可重用的技术可能是编写一个助手类来处理读取属性名称映射，并提供一个"GetProperty"方法供单元测试使用。这样，您就可以封装回退行为，在混淆后的名称失败时尝试未混淆的名称，从而省去了担心是否打开属性名称混淆的麻烦。目前还没有一个preemptive构建的解决方案或工具来执行转换，但它应该是直接构建的。
或者，您可以在Dotfuscator中设置一个不会混淆属性名称的构建，并将其用于测试。就我个人而言，我觉得helper对象更容易使用，但它也在代码库中引入了构建系统工件。