Всем привет !!! Столкнулся со ледующей проблемой..... При открытии определенной страницы (*.aspx в Internet Explorer) перед загрузкой компонента подгружаются необходимые сборки. Но IE начинает поиск сборок в сдедующей последовательности: 

1. В корневой папке приложения, допустим http://site.com/
2. Затем в папке /bin, полный путь http://site.com/bin/
3. Затем в папке по имени сборки, допустим имя сборки assembl.dll, тогда http://site.com/assembl/
4. Затем ввиду отсутсвия сборки в этих местах вызывается метод привязанный к AssemblyResolve и загружает сборки отуда где они лежат, допустим http://site.com/main/com/.

Ввиду такой последовательности загрузки сборок, страница первый раз загружается очень долго..... Можно ли как-нибудь "сказать" IE , где ему сборки брать....Причем путь http://site.com/main/ может быть другим (http://site.com/main1/ или .../asdf/), т.е. нужно через относительный путь. Как вариант можно принудительно загружать нужные сборки, но тогда при добавлении новой сборки прийдется снова править код... Может есть какие-нибудь другие варианты ???

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

И еще интересует как вы определили эту хронику запросов ???

А если идет речь о контролах на стороне сервера, то IE не имеет никакого отношения к серверу. Тогда надо работать непосредственно с IIS и aspnet_isapi.dll но там кажись нельзя изменять путь где сервер будет искать страницы... Просто при изменении web.config или dll то у тебя по новой собирается Application...  но это происходит только лишь при первом заходе первого пользователя. В дальнейшем этого не происходит.

Чистый Windows.Forms контрол, написсаный на C#.

При помощи программы httpwatch, пятой версии, если надо выложу скрин.
 
Может можно как нибудь задать путь для контрола, где искать необходимые ему сборки ??? Или что-то похожее ??? Я пытаюсь копать в сторону AppDomain.CurrentDomain.SetupInformation.PrivateBinPath, но для текущего домена, это строка только для чтения..... Кстати сам контрол лежит по тому же пути что сборки и загружается без проблем (т.е. оттуда где находиться без перебора папок), а остальные сборки вышеописанным способом.......

Так если Windows.Forms то получается ты делаешь web-запрос к localhost или куда-то на другой сервер. Да ??? Или ты всеже используешь ActiveX объекты ???



Я все еще не понимаю для чего тебе нужно это задавать (для клиенской программы на Winforms или для aspnet_isapi.dll). Просто вначале ты говоришь про IE. потом ты говоришь про Windows.Forms... 

Как и при запуске WinForms программы, .NET должен выгрузить все это дело в машинные коды и держать в памяти. Тоже самое и с asp.net'ом. При запуске приложения он выгружает все это дело в память. 
Или я не в те дебри лезу... 
Опять таки, при подгрузки контролов, ты четко указываешь где лежат контроды. При использовании сборок, они лежат в bin каталоге... я чего-то не понимаю   

Попробую обьяснить....... Сам в этих вопросах я практически не разбираюсь (очень поверхностно). Просто нужно избавиться от долгой загрузки страницы и я пытаюсь выяснить причину )....Вот как я это понимаю....

Launcher, как вчера  я выяснил чистый windows.Forms control (создавался как Windows Control Library)....Дальше... Его загрузка происходит при рендериге aspx страницы джаваскриптом:

<script language="javascript" type="text/javascript">
scriptCode = '<object id="LauncherObject" classid="<%= Me.Request.Url.Scheme %>:../com/Launcher.dll#Launcher.Launcher" ';
scriptCode += 'style="text-decoration: none; position: relative; top: 40px;">';
scriptCode += '<param name="Id" value="<%= Me.Id %>" />';
scriptCode += '<param name="WebExt" value="<%= Me.WebExt %>" />';
scriptCode += '<param name="Pwd" value="<%= Me.EncryptedPwd %>" />';
scriptCode += '<param name="LoggerActivationUrl" value="<%= Me.GetLoggerActivationUrl() %>" />';
scriptCode += '<param name="RStatusWebServiceUrl" value="<%= Me.GetRStatusWebServiceUrl() %>" />';
scriptCode += '</object>';
activateActiveX(scriptCode);
</script>

Т.е. происходит примерно следующие: Скачивается сборка Launcher.dll, анализируется и затем скачиваются необходимые Launcher.dll сборки. И еще вопрос. Вот этой строчкой activateActiveX(scriptCode), Launcher создается как ActiveX компонент или все же остается как windows.Forms control (вроде бы где-то читал что их можно применять, но только в ИЕ) ?????

Выяснил еще что пару недель назад этого не было: activateActiveX(scriptCode)
а вместо нее было просто написано что-то похожее на: <object clsid="....Launcher.dll...."></object>

Ну и проаналировав лог http запросов и ответов, обнаружил что скорей всего это проблема (как писал выше) поиска сборок. Еще раз последовательность поиска:

1) site.com/sborka.dll
2) site.com/sborka/sborka.dll
3) site.com/bin/sborka.dll
4) site.com/bin/sborka/sborka.dll
и повторяется такой же поиск только sborka.exe. А потом находит там где она лежит site.com/temp/com/sborka.dll.

Вот собственно и нужно избавиться от такой последовательности поиска, т.е. как нибудь в рантайме (почему в рантайме , потому что  в пути site.com/temp/com/ вместо temp будет что угодно) указать где искать сборки (может в ИЕ, в самой сборке Launcher.dll и т.д.).... Помогите плиз....уже  3 дня бьюсь над проблемой..... Укажите хоть куда копать.......

Mymikу 
Это называется: встроенные елементы управления на клиентской стороне (embedded client-side control). Используется СОМ-интерфейс.
Это не АктивХ, а .НЕТ сборки. 
Очень интересная концепция, почти все как АктивХ но с улучшеной безопасностью. Правда только ИЕксплоеры это поддерживают.

andrew_shу
Тоже эта же проблема. Пока ложу библиотеку в каталог с определенными страничками. И получается что таких мест несколько (на разных уровнях - в разных папках) и одну и туже библиотеку приходится ложить в разные места. Как бы ее положить один раз?

Порывшись по форум, факам и т.д. пришел к выводу(может и неправильному!!!) , что все-таки Каким либо образом необходимо IE указывать, откуда скачивать сборки(скачиваются на локальный комп). И всякие варианты с использованием 
AppDomen.AppendPrivatePath (и т.п, в том числе <codebase> и <probing>,AssemblyResolve) проблему долгого поиска (перебора все выше описанных папок) не решают. Они в основном решают проблему, если сборка не найдена. Вот пример похожей темыhttp://www.gotdotnet.ru/Forums/Web/427884.aspx... Решение тоже не найдено. НО ОНО ДОЛЖНО ЖЕ БЫТЬ.

2Servena:

Посмотри в сторону AssemblyResolve. Проблема поиска решается (в смысле ложишь в определенную папку все сборки), но вышеописаная мной проблема скорости нет(т.е. обойдя все папки и не найдя вней нужной сборки, вызывается метод связанный с AssemblyResolve, где ты вручную загружаешь сборку).

Помоему тема достаточно актуальная.... Если кто что нибудь найдет, не проходите мимо, отпишите хоть в какую сторону копать

Вот примерная структура всего приложения:


www.site.com\
    Component1\      ---  winform компонент (который Launcher.dll, но сборка лежит в "~/site/com")
    Component2\
    ..........
    WebServices\     ---  вебсервисы
    ..........
    SITE\            --- веб приложение (сам сайт, название папки может быть какое угодно)
        .....
        .....
        .....
        COM\     --- папка со сборками


Может попробовать что-нибудь типа "..Создать новый AppDomain и указать ему соотв. ApplicationBase..", ведь ApplicationBase (получается первое место откуда ИЕ пытается скачать сборку) для текущего домена поменять нельзя.....Только как это сделать и где, и заставить все это работать, понятия не имею

....ФУФ.... Проблема решена (правда не мной  )...... А решается следующим образом. Для aspx страницы, на которой размещен .NET компонент, необходимо добавить ссылку на конфигурационный файл (файл может быть пустым, только с тегами <configuration></configuration>). Файл должен находиться в папке с нужными сборками..... Подробней Настройка приложений Internet Explorer.... Там есть такая фраза "Корень приложения задан каталогом, содержащим файл конфигурации", а это и есть то место откуда IE первым делом ищет сборки..

Всем спасибо за участие.