Вопрос в значительной степени объясняет это. У нас есть пакет приложения WinRT (Metro), который мы запутываем с помощью Dotfuscator после каждой сборки. Из-за того, как Dotfuscator выполняет переименование, прямо сейчас нам необходимо вручную переименовать любой элемент управления, который мы вызвали по имени из Codebehind. Если мы этого не сделаем, мы получим исключение NullReferenceException. Это немного раздражает, но мы успешно справились с этим и поймали все случаи этого, но это занимает довольно много времени, и всегда есть шанс, что мы пропустим один.
Что бы я хотел сделать, так это иметь возможность создавать некоторые модульные тесты для проверки функциональности событий в созданных мной представлениях, но это работает, только если я могу сделать это в запутанной версии. Я знаю, что мы можем отлаживать развернутый пакет приложения, даже отлаживать запутанные пакеты приложений (поскольку у нас есть файлы .pdb в проекте).
Если у кого-то есть опыт работы с этим или с Dotfuscator и он знает лучший способ сделать это, я хотел бы получить некоторую информацию. Теоретически я мог бы также создать тест, который читает наш текущий «эталонный» проект Dotfuscator и сравнивает его со всеми именованными элементами управления в отделенном коде, но это похоже на демон теста для написания, и я не ожидаю, что мне придется вообще анализировать код программной части. Это может быть так же просто (для различных определений простого), как выполнение текстового поиска по всему документу XAML для атрибута [x:Name"*"] с последующим поиском значения, отмеченного звездочкой, как в исходном коде, так и в документе проекта Dotfuscator. , который, к счастью, является просто XML.
Любая помощь, которую вы можете предоставить по этому вопросу, будет высоко оценена. Я уже создал тему на форумах поддержки PreEmptive. Я использую Dotfuscator Professional (не версию из App Store) и обновился до самой последней версии 4.10.
*Edit 25/4/13 Итак, в конце концов, несмотря на то, что совет @ianschol был полезен, на данный момент я реализовал решение, описанное выше:
-Перечислить поля элемента управления
-Определить, какие поля являются свойствами, а какие названы элементами управления
-Прочитайте в .xaml.cs
-Найдите все поля, на которые ссылается имя, сохраните их
Примечание. Затем я использовал регулярное выражение для фильтрации полей, объявленных в самом файле .cs, поскольку они были ненужными.
-Чтение в файле проекта Dotfuscator
-Разбор потомков. Если имя элемента управления отображается в списке ссылок, подтвердите, что у него есть дочерний элемент с заданным атрибутом имени.
