Лучше запутывать в Visual Studio решения для многих проектов?

Question

У меня есть решение со многими проектами, которое приводит ко многим файлам DLL.

У меня вопрос, является ли это препятствием при запутывании, и я должен каким-то образом оптимизировать это?

Или это просто вопрос открытых / закрытых полей / методов?

Answer 1

Способ, которым вы выполняете это с помощью Dotfuscator, заключается в добавлении всех ваших сборок в качестве входных данных в проект Dotfuscator. После этого вам нужно будет отключить режим библиотеки либо для проекта в целом (на вкладке Входные файлы, значок, который выглядит как набор книг), либо для каждой сборки отдельно. Режим библиотеки является режимом по умолчанию для файлов DLL и не переименовывает какие-либо общедоступные элементы.

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

Редактировать: Еще одна вещь, на которую вы можете обратить внимание, которая может облегчить ваше распространение, - это функция связывания Dotfuscator. Это позволяет связывать сборки вместе (аналогично тому, что делает ILMerge), чтобы вы могли отправить один EXE-файл со всеми связанными с ним DLL-библиотеками или любой другой комбинацией, чтобы у вас было меньше физических файлов для предоставления конечным пользователям. *

Answer 2

Нет, вы определенно не должны ставить под угрозу структуру вашего проекта только для обфускатора.

В общем, у обфускаторов есть режим, в котором вы можете сказать: «Здесь вся моя система, предположим, что никто больше ничего не делает», что фактически говорит об этом, как об одном блоке кода.

Можно использовать такие приемы, как использование internal вместе с InternalsVisibleToAttribute (по умолчанию многие обфускаторы будут более агрессивными с internal, чем public.

Все, что нужно оставить как есть, например, для доступа System.Reflection или dynamic, может быть помечено ObfuscationAttribute, чтобы сказать обфускатору "Не трогай это".

Существуют и другие компромиссы, которые следует учитывать при добавлении слоев фасада, которые действуют как мосты между компонентами, а затем создают внутренние классы за этим - в зависимости от контекста, который может облегчить обратный инжиниринг (вы передаете otu краткое резюме) или сложнее (у вас был базовый класс, и вы раздавали множество подсказок, имея при себе некоторые ключевые методы, например, не переименованные).