Внутренний модификатор C#, обфускация и модульные тесты ⇐ C#

[Anonymous]

TLDR;

• Один проект, 95 % специально помечен как внутренний, протестирован отдельным тестовым проектом с использованием InternalsVisibleTo
• Выполнение тестов в запутанной сборке выпуска вызывает множество исключений System.MissingMethodException
• Инструмент обфускации рекомендует не использовать InternalsVisibleTo, хотя нам удалось настроить его так, чтобы он не переименовывал внутренние символы.

Разрыв между

• Сделать все внутренние компоненты общедоступными для инструмента обфускации satisfsy.
• Запустить тесты на незашифрованной сборке и повторно запустить выбранный набор тестов на запутанных сборках, чтобы убедиться, что обфускация ничего не сломала.

Любые другие идеи и предложения приветствуются

У меня есть проект C#, который является частью решения, включающего более 30 других проектов.
Это алгоритм, вы вносите в него некоторые входные данные, а он возвращает результат.
Все это подключено через контейнер DI, и потребители обычно запрашивают открытый интерфейс из контейнера и называют его так.
Внутренне, все службы также используют внедрение зависимостей для получения и вызова своих зависимостей, и именно так все связано вместе с начальной точки общедоступного API.
Чтобы предотвратить (ab)(повторное) использование кем-либо чего-либо из того, что я создал внутри указанного проекта, почти все помечается как внутреннее, за исключением некоторых структур данных и единственного интерфейса, который предоставляет общедоступный API моего алгоритма.
Я в основном придерживался позиции "Все является внутренним, пока мне не требуется доступ в него из другого проекта, который не является моим тестовым проектом. Если да, оцените в каждом конкретном случае, следует ли его сделать общедоступным или следует вывести из проекта алгоритма»..
Для настройки моего DI-контейнера сам проект предоставляет общедоступный тип, который передается в контейнер, и убедитесь, что все внутри проекта подключено правильно.
Итак, у него есть собственный тестовый проект, и, поскольку большая часть функций помечена как внутренняя, я сделал это. прибегнуть к использованию InternalsVisibleTo, чем я занимаюсь с тех пор, как пишу тесты.
Все идет нормально, тесты выполняются без проблем как в отладочной, так и в выпускной сборках.
У меня есть тесты, которые тестируют отдельные сервисы, а что нет, и интеграционные тесты, которые проверяют, что определенные части моего алгоритма работают так, как задумано.
Другие потребители моего алгоритма в решении знают только об этом одном общедоступном интерфейсе и типах данных, которые я явно раскрываю, ничего else.
Введите обфускацию
Текущий процесс выпуска выглядит следующим образом:

• Создайте решение и запутайте сборки
• Запустите тесты против запутанных сборок
• Публикуйте запутанные сборки
• Создайте установщики и включите запутанные сборки сборки, подпишите их

В настоящее время у меня возникают проблемы с «Выполнять тесты для запутанных сборок».
Инструмент обфускации, который мы сейчас используем, четко указано в документации:

.NET определяет класс System.Runtime.CompilerServices.InternalsVisibleToAttribute, который позволяет указывать типы, которые обычно видимы. другой сборке видны только внутри входной сборки.

Хотя в некоторых сценариях это может быть полезно, настоятельно не рекомендуется использовать эту функцию .NET в сборках Release, поскольку она делает обфускацию теоретически и практически бесполезной.

и вместо этого рекомендует такие вещи, как:

• не использовать InternalsVisibleToAttribute вообще в Выпускайте сборки. Оберните его с помощью #if DEBUG
• use System.ComponentModel.EditorBrowsableAttribute, чтобы отметить классы и члены, которые вы хотите скрыть от конечных пользователей.

Я не могу найти в Интернете источники, подтверждающие утверждение об отказе от использования InternalsVisibleToAttribute или что-либо, что помечало бы это как плохую практику.
Большинство вещей, которые я нахожу, связаны с людьми, желающими написать тесты для частной функциональности класса, и я согласен, что злоупотреблять InternalsVisibleTo для этого и менять частное на внутреннее только ради этого плохо.
Поэтому я сейчас немного не знаю, как действовать.
Лично я не хочу идти по пути превращения всего внутреннего в общедоступное, просто для ради того, чтобы сделать наш инструмент обфускации счастливым.

Единственная причина, по которой я могу придумать, почему мы тестируем наши запутанные сборки, - это убедиться, что сама обфускация ничего не сломала.
Поэтому мне интересно, можно ли считать следующий подход действительным:

• Построить решение (конфигурация выпуска)
• Запустить все тесты в решении (без обфускации, перехватывайте все, что приводит к сбою тестов)
• Запутывайте сборки
• Повторно запускайте любые (скорее всего, интеграционные/E2E) тесты, которые используют наш контейнер для разрешения SUT и его зависимостей, поскольку обфускация, похоже, не влияет на них. Это необходимо для проверки того, что обфускация ничего не сломала.
• Публиковать запутанные сборки.
• Создать установщики, включить запутанные сборки, подписать их.