2012-05-02 1 views
1

Я хотел бы заблокировать классы внутри моей сборки, чтобы они не вызывались из других классов внутри одной и той же сборки. То есть, другими словами, никаких боковых вызовов внутри сборки.Определите, вызван ли код из той же сборки

Я собирался написать некоторую проверку в вызовах класса, чтобы убедиться, что они не вызываются из одной сборки. Как я могу определить это с помощью рефлексии?

Таким образом, ее следующий сценарий:

Assembly1 
---------- 
Class 1A 

Assembly2 
---------- 
Class 2A 
Class 2B 

Так класс 2 не может вызвать класс 2B. Но Class 1A может вызывать Class 2A или Class 2B.

+0

Для этого не используется ключевое слово 'internal'? –

+0

Это звучит точно в обратном порядке для большинства требований. Разрешено ли 'Class2A' называть' Class1A', что в свою очередь вызывает 'Class2B'? –

+0

@juergend - Нет. Он позволяет вам получить доступ к классам внутри одной сборки, а не к сборкам. Он также не поддерживает доступ к узлу в сборке. – Oded

ответ

2

То, о чем вы просите, невозможно с существующим access modifiers.

Вы не можете сделать класс общедоступным для других сборок, но внутренне закрытым.

Если разделить ваш Class2B к другой сборке и сделать его internal, вы можете также set the InternalsVisibleToAttribute к Assembly1.

Этого достигнет то, что Class2A не имеет доступа к нему, но Class1A может.


Вы можете сделать некоторые проверки во время выполнения с помощью отражения, а также - в качестве the answer деталей Christian.K.

0

Как насчет:

if (Assembly.GetCallingAssembly() == Assembly.GetExecutingAssembly()) 
{ 
    // Throw some exception 
} 

Кажется довольно странным, что нужно сделать, хотя ...

1

Почему вы поместите их в той же сборке, в первую очередь?

Скорее всего, 2B и 2A имеют собственные сборки, обозначающие классы как internal. Предоставьте атрибут уровня сборки InternalsVisibleTo, чтобы позволить «Assembly1» получить доступ к внутренним элементам «Assembly2B» и «Assembly2A» соответственно.

Используя отражение, вы все равно сможете обойти это.

Использование такого механизма (или любого другого, ручной проверки «звонящего») в любом случае не рекомендуется в целях безопасности. Если вы хотите сделать это для «архитектурных» целей, вы можете пойти с тем, что было предложено выше, и использовать инструменты, такие как NDepend или пользовательское правило FxCop/CodeAnalysis. Вы можете подтвердить, что ваши правила не нарушаются во время сборки.