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

В веб-службе .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)?

источник

2009-02-25 Mike Chess

Это позволит получить все узлы, загруженные в текущий контекст выполнения:

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

источник

2009-02-25 21:34:54

Это позволит получить полный список сборок, но не затрагивает основной вопрос: как определить, выполняется ли сборка внутри веб-службы. –

Когда вы говорите «из веб-службы», вы имеете в виду, что проверка происходит из кода, выполняемого в вашем веб-сервисе, или вы являетесь внешним по отношению к веб-службе и хотите спросить упомянутую службу, загрузил ли она данную сборку? –

Из кода, выполняемого в веб-службе. Это может быть дополнительная сборка, которую загрузила веб-служба. –

-1

Вы могли бы сделать вызов:

Assembly.GetExecutingAssembly().CodeBase

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

источник

2009-02-25 21:36:57 Millhouse

Да, но это не скажет мне, как определить, выполняется ли сборка внутри веб-службы ... что я действительно хочу знать. –

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

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

источник

2009-02-26 02:24:32

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

В исследовании еще один аспект веб-службы, я наткнулся на это:

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

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

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

источник

2009-02-27 18:05:08

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

ответ

Смежные вопросы