Можно ли определить, была ли сборка загружена внутри веб-службы?

Question

В веб-сервисе .Net можно определить, была ли сборка загружена в веб-сервис? Если это так, как будет проводиться такая проверка? А по такой проверке можно определить исходное место сборки?

Это длинная история о том, что сборки разделяются между несколькими точками входа нашего приложения на сервере, некоторые из которых доступны через веб-службы, а другие - через более традиционные сокеты TCP, размещенные внутри обычных служб Windows. Также могут быть запущены другие службы Windows, использующие те же общие сборки. Конфигурационные потребности каждого из них немного различаются, и такие вызовы, как System.Windows.Forms.Application.ExecutablePath, дают разные результаты в зависимости от того, что является «размещением» сборки. Мне нужно иметь возможность надежно рассчитать местоположение сборки, чтобы вычислить местоположение файла конфигурации.

Web.config / app.config не являются параметрами в этом сценарии.

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

EDIT:

Предположим, что foo.dll можно вызывать как из MyApp.asmx (веб-служба), так и из MyService.exe (служба Windows). В любом случае можно определить, было ли MyApp.asmx приложением, загружающим файл foo.dll из выделенного кода (MyApp.dll)?

Answer 1

При этом все сборки загружаются в текущий контекст выполнения:

Assembly[] loadedAssemblies = AppDomain.CurrentDomain.GetAssemblies();

Answer 2

Исследуя другой аспект веб-сервиса, я наткнулся на это:

string path = Context.Request.ServerVariables["APPL_PHYSICAL_PATH"];

Будет возвращено что-то вроде «C: \ inetpub \ wwwroot \ MyWebApp \», указывающее, установлено ли приложение. Конкретный путь зависит от того, где установлено приложение.

Как уже упоминалось в вопросе, это не поможет foo.dll выяснить, был ли он вызван из веб-службы, поскольку foo.dll обычно не имеет доступа к Context.Request. С небольшими изменениями в foo.dll веб-служба сообщит foo.dll, что это за корень приложения.

Answer 3

Если вы владеете кодом, было бы лучше добавить метод или свойство инициализации, которые можно было бы использовать, вызвав код, для сообщить сборке, где он выполняется. Фактически, вы можете добавить статическое свойство, которое является местоположением файла конфигурации.

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

Answer 4

Вы можете позвонить на:

Assembly.GetExecutingAssembly().CodeBase

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