2

这个问题几乎解释了它。我们有一个 WinRT (Metro) 应用程序包,我们在每次构建后都使用 Dotfuscator 对其进行混淆。由于 Dotfuscator 重命名的方式,我们现在需要手动重命名我们从代码隐藏中按名称调用的任何控件。如果我们不这样做,我们会得到一个 NullReferenceException。这有点烦人,但我们已经成功地跟上了它并捕获了所有这种情况,但这非常耗时,而且我们总是有机会错过一个。

我想做的是能够创建一些单元测试来测试我创建的视图中的事件功能,但这只有在我可以在混淆版本中完成时才有效。我知道我们可以调试已部署的应用程序包,甚至可以调试混淆的应用程序包(因为我们在项目中有 .pdb 文件)。

如果有人对此或 Dotfuscator 有任何经验并且知道这样做的更好方法,我很想得到一些意见。从理论上讲,我还可以创建一个读取我们当前的“参考”Dotfuscator 项目的测试,并将其与代码隐藏中的所有命名控件进行比较,但这似乎是一个要编写的测试的恶魔,我不期待不得不这样做完全解析代码隐藏。它可能像在整个 XAML 文档中搜索 [x:Name"*"] 属性一样简单(对于简单的不同定义),然后在后面的代码和 Dotfuscator 项目文档中搜索加星标的值,幸好只是 XML。

您可以在这方面提供的任何帮助将不胜感激。我已经在 PreEmptive 支持论坛上创建了一个主题。我正在使用 Dotfuscator Professional(不是 App Store 版本),并且已更新到最新版本 4.10。

*编辑 25/4/13 所以最后,虽然@ianschol 的建议很有帮助,但现在我实现了上面概述的解决方案:-
枚举控件的字段
-确定哪些字段是属性,哪些是命名控件-读
入.xaml.cs
- 查找名称引用的所有字段,保存它们

注意:然后我使用了一些正则表达式来过滤掉 .cs 文件本身中声明的字段,因为它们是不必要的。

- 读入 Dotfuscator 项目文件
-Parse Descendants。如果控件的名称出现在引用列表中,则断言它有一个具有给定名称属性的后代元素。

4

1 回答 1

1

解决您的问题的最有效和可重用的技术可能是编写一个帮助程序类来处理读取属性名称映射,并提供一个“GetProperty”方法供您的单元测试使用。这样,如果混淆名称失败,您可以封装尝试非混淆名称的回退行为,从而省去担心是否打开属性名称混淆的麻烦。目前没有 PreEmptive 构建的解决方案或工具来执行翻译,但构建起来应该很简单。

或者,您可以设置一个不会在 Dotfuscator 中混淆属性名称的构建,并将其用于测试。就个人而言,我觉得辅助对象更易于使用,但它也在您的代码库中引入了构建系统工件。

于 2013-04-23T15:26:38.000 回答