Блог

Изменяет ли объединение сборок область действия внутреннего ключевого слова?

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

Возможно, это гипотетический вопрос, не имеющий реального значения, но, тем не менее, мне было любопытно.

Редактировать: я имею в виду с ILMerge, а не объединение исходного кода в единую сборку, которую можно собрать.

Да, как только сборки объединены, они получают доступ к внутренним классам друг друга. Некоторые обфускаторы специально используют это для преобразования общедоступных вызовов между сборками во внутренние вызовы, а затем запутывают их, делая это более безопасным. Ссылка: SmartAssembly

Кстати, используя ILMerge, вы можете использовать параметр командной строки /internalize, который сделает все общедоступные классы в сборках, отличных от основной сборки, внутренними, что уберет общедоступные интерфейсы из поля зрения конечного пользователя, но сборки все равно будут функционировать нормально.

Предполагая, что вы не работаете с полным доверием, любые типы, которые были объединены в окончательную сборку с внутренними типами, теперь смогут получить доступ к общедоступным элементам внутренних типов.

Итак, данная сборка A:

 public class MyClassA { ... }
  

и сборка B:

 internal class MyClassB { ... }
  

У MyClassA может не быть разрешения отражать общедоступные элементы MyClassB. Если они были объединены в одну сборку, то MyClassA может получить такое разрешение.

Другой возможный ресурс для получения дополнительной информации — это страница ILMerge в Microsoft Research, где они предлагают альтернативу ILMerge