Как указал SLaks , вы можете проверить HttpContext.Current.Application.GetType().Assembly.
Однако я согласен с Джоном в комментариях о том, что вы, вероятно, приняли неправильное дизайнерское решение , если вам это нужно.
Проблема
Ваш метод лицемер.
Он говорит по-разному с разными вызывающими, но не говорит об этом открыто.
Видите ли, каждый метод определяет определенный контракт с аргументами и типом возвращаемого значения.
Например, int.Parse говорит, что он принимает string и превращает его в int.Если мы хотим изменить поведение по умолчанию, мы также можем указать его NumberStyles и / или IFormatProvider.
Мы, потребители, не знаем, как реализовано int.Parse.Поскольку это static, мы, безусловно, ожидаем, что у него нет побочных эффектов, и всегда будет возвращать одно и то же значение для одного и того же набора параметров .
. Повторите эту мантру после меня:
Явное лучше, чем неявное.
Вы, вероятно, очень рассердитесь, если узнаете, что int.Parse каким-то образом анализирует ваш код и изменяет егоповедение в зависимости от того, откуда он вызывается.
Ответственность за определение контекста несет не вызывающий, а вызывающий.
Попробуйте дать простые и краткие ответы на вопросы ниже:
- Что произойдет, если метод вызывается из сборки C?
- Как бы вы провели его модульное тестирование?Что если какой-то другой разработчик использует этот метод в модульных тестах?
- Что произойдет, если вы переименуете сборку A или B?Слить их?Разделить их дальше?
- Помните ли вы, чтобы поменяли этот метод, если произойдет что-либо выше?
Если ответ на любой из приведенных выше вопросов явно представляет для вас проблему, это признак того, что вы делаете это неправильно ™.
Вместо этого вы должны ...
Введите параметр
Подумайте о контракте метода.Что вы можете сделать, чтобы сделать его полным и описательным?
Определите универсальный (как на английском языке) метод в отдельной сборке, который ничего не знает о вызывающих, и имеет дополнительные параметры , и определите для него ярлыки для заполнения параметровв конкретных сборках.
Лучше, чтобы эти параметры также ничего не знали о сборках.
Например, если вам нужно разрешить URL-адреса внутри вашего метода, вы можете принятьstring baseUrl или Func<string, string> urlResolver, поэтому он потенциально может использоваться из любой сборки, которая задает их.
В худшем случае можно определить перечисление с возможнымконтексты вызывающего и передать его в метод.Это сделает вашу проблему дизайна явной, а не неявной.Очевидная проблема всегда лучше, чем скрытая, хотя хуже, чем вообще никакой проблемы.