В C #, как ограничить, кто может вызывать метод во время компиляции - PullRequest
Новая
       14

В C #, как ограничить, кто может вызывать метод во время компиляции

2 голосов
/ 14 ноября 2011

В C # можно ли ограничить, кто может вызывать метод во время компиляции?

Я изучил директивы, но это не сработало, поскольку я не могу присвоить значения символам. 

#define WHO VisualStudioUser.Current // does not work

Я также посмотрел на Code Access Security (CAS), но это принудительное выполнение во время выполнения, а не время компиляции.

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

вот больше подробностей ... Я строю фреймворк или серию или сборки для команды разработчиков. Из-за наших лицензионных ограничений на программное обеспечение я могу позволить лишь нескольким разработчикам писать код для вызова некоторых ограниченных методов. Разработчики не будут иметь доступа к исходному коду фреймворка, но будут иметь доступ к скомпилированным сборкам фреймворка.

Ответы [ 4 ]

7 голосов
/ 14 ноября 2011

Быстрый ответ будет: Нет, это невозможно, и если вам нужно это сделать, вы делаете это неправильно.

Как бы это сработало? Зависит ли это от того, кто выполняет код или кто его написал?

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

3 голосов
/ 14 ноября 2011

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

Один из способов - пометить метод private или internal, он не может быть вызван кем-либо вне сборки. ОБНОВЛЕНИЕ : также обратите внимание на атрибут InternalsVisibleTo, который используется для определения, какие сборки могут "видеть" внутренние компоненты вашей сборки.

Другой способразделить код, который вы хотите распространять, из кода, который вы не хотите, чтобы люди вызывали, на отдельные сборки.Может быть, вы просто делитесь сборкой в ​​основном интерфейсов со своими пользователями, чтобы они их компилировали;и у вас есть отдельная сборка с реализациями, на которые они не должны ссылаться напрямую.Ваша внутренняя команда будет иметь доступ к сборке реализации.Это обычная форма управления зависимостями, принцип инверсии зависимостей .

1 голос
/ 14 ноября 2011

Черновик:

  1. Скомпилируйте ограниченный код в (обфусцированные) библиотеки DLL: TypeA.dll, TypeB.dll и т. Д.
  2. Определите интерфейс для каждого типа и скомпилируйте их вотдельные библиотеки DLL: ITypeA.dll, ITypeB.dll и т. д.
  3. Создайте «защитную сборку» и вставьте всех запрещенных сборок в нее: Guard.dll.Это ResolveEventHandler и методы для создания экземпляров различных типов, определенных во встроенных ограниченных DLL.Экземпляры возвращаются через их интерфейс.
  4. Разработчики получают библиотеки DLL интерфейса и Guard.dll.Каждый разработчик может получить Guard.dll со специальными токенами аутентификации.Например, Guard.dll может быть связан с ПК, IP-адресом, GUID, выданным разработчику, чем угодно.
  5. Разработчик может создавать экземпляры тех типов, для которых он имеет надлежащий код аутентификации, и используетэкземпляр объекта через интерфейс.

Извините, это немного нечетко, потому что это было больше года назад, когда я использовал эти методы.Я надеюсь, что основная идея ясна.

0 голосов
/ 14 ноября 2011

Можете ли вы попробовать использовать Extensible C #, разработанный ResolveCorp , некоторые ссылки для изучения и реализации:

http://zef.me/782/extensible-c

http://www.codeproject.com/KB/architecture/DbCwithXCSharp.aspx

http://weblogs.asp.net/nunitaddin/archive/2003/02/14/2412.aspx

http://www.devx.com/dotnet/Article/11579/0/page/5

...