Развертывание приложений среды выполнения с помощью Internet Explorer

Статья
11/05/2008

Обновлен: Ноябрь 2007

Веб-приложения могут использовать Microsoft Internet Explorer 5.5 или более поздние версии для загрузки и запуска сборок. Веб-приложения могут загружать оба вида переносимых исполняемых файлов — .exe и .dll. В документе HTML могут содержаться сведения о том, какие сборки загружаются, о местоположениях сборок и о местоположении файла конфигурации, в котором могут содержаться дополнительные сведения.

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

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

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

Параметры веб-приложений

По умолчанию общеязыковой средой выполнения создается домен приложения для каждого узла, доступ к которому получают с помощью Internet Explorer. Домены приложений изолируют отдельные приложения, выполняющиеся в рамках одного процесса. Способ создания доменов приложений влияет на те разрешения, которыми обладают сборки во время выполнения в соответствующем домене. Каждый домен приложения связан с URL-признаком и базовой папкой приложения, а также может иметь файл конфигурации.

URL-признак

Приложениям, развертываемым с помощью Microsoft Internet Explorer 5.5 или более поздних версий, ставится в соответствие URL-признак. Узлы среды выполнения используют этот URL-признак для принятия решений, основанных на политике безопасности. Хотя URL-признак связан как со сборками, составляющими приложение, так и с доменом приложения, созданным приложением, формат признака является разным в каждом случае. URL-признак для сборки представляет собой полный URL-путь к главному файлу сборки. Например, сборка, являющаяся частью приложения, могла бы иметь URL-признак http://www.code.microsoft.com/myApp/myAssembly.dll. URL-признак для домена приложения эквивалентен признаку узла. В соответствии с предыдущим примером URL-признак для домена приложения был бы http://www.code.microsoft.com/.

Примечание.
Местоположение файла конфигурации приложения не влияет на URL-признак домена приложения.

Файлы конфигурации

Веб-приложения, развертываемые с помощью Internet Explorer, могут использовать данные, хранящиеся в файле конфигурации приложения. Файл конфигурации приложения должен находиться на веб-сервере в том же каталоге, в котором хранится исполняемое приложение. Файл конфигурации приложения должен удовлетворять правилам именования файлов конфигурации приложений. Файл должен иметь такое же имя, как исполняемое приложение, с добавлением расширения ".config". Например, приложение с именем myApplication.exe будет иметь файл конфигурации приложения myApplication.exe.config.

Приложения ASP.NET задают сведения о конфигурации с помощью файла "web.config". Веб-приложения могут предоставлять сведения о конфигурации точно так же, как это делают ASP.NET и исполняемый узел. Если приложение, размещаемое в Internet Explorer, имеет файл конфигурации, местоположение файла конфигурации задается тегом <link> со следующим синтаксисом:

<LINK REL="CONFIGURATION" HREF="[configuration file name]"></LINK>

В этом примере [имя файла конфигурации] — это имя файла конфигурации, например:

<LINK REL="CONFIGURATION" HREF="two.dll.config"></LINK>

Для базовых сценариев веб-приложения, где веб-страница не предоставляет тег <link> в файл конфигурации, среда выполнения создает домен приложения для каждого узла. То есть, если HTML-документ находится по адресу http://www.code.microsoft.com/myApp/mypage.htm, домен приложения создается для всего узла http://www.code.microsoft.com. Обратите внимание, что хотя этот сценарий удобен для веб-разработок, все веб-страницы, использующие сборки управляемого кода в этом узле, имеют общий доступ к домену приложения, поскольку файл конфигурации не был задан.

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

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

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

Примечание.
Средой выполнения не поддерживается символ "#" в URL-адресах, указывающих на файл конфигурации, когда тег <link> содержит относительный путь.

Базовая папка приложения

Свойство ApplicationBase — это свойство домена приложения, которое задает каталог, служащий в качестве корневого каталога при поиске сборок средой выполнения. По умолчанию предполагается, что свойство ApplicationBase является корневой папкой узла (например, wwwroot). Если имеется файл конфигурации приложения, свойство ApplicationBase становится местом нахождения этого файла конфигурации. Файл конфигурации может содержать сведения о конфигурации, характерные для кода, выполняющегося в данном домене приложения. Если на компьютере определено более одного узла, свойство ApplicationBase устанавливается по умолчанию равным узлу "по умолчанию", определенному для порта 80.

Загрузка управляемых исполняемых файлов

Хотя большинство приложений, загружаемых с помощью тега <object>, являются элементами управления пользовательского интерфейса, которые отображаются на веб-странице, среда выполнения поддерживает также два сценария загрузки управляемых исполняемых файлов:

Ввод пользователем URL-адреса управляемого EXE-файла в обозревателе; например:
```
http://www.server.microsoft.com/MyWebSite/MyApp.exe.
```
HTML-страница содержащая ссылку на управляемый исполняемый файл; например:
```
HREF="MyApp.exe".
```

В обоих сценариях среда выполнения создает новый домен приложения для запуска исполняемого файла. Для последующих запросов сборок база приложения устанавливается равной местоположению исполняемого файла.

Например, следующий код ссылается на класс myClass:

<object id="myCtl" 
  classid="http://www.mycode.Microsoft.com/mycode.dll#myClass"> 
</object>

Статически связанные зависимые сборки должны находиться в том же каталоге, что и вызывающая сборка, задаваемая с помощью тега <object>. Например, если сборка myAssembly.dll задана с помощью тега <object> и имеет статическую ссылку на сборку myOtherAssembly.dll, тогда сборка myOtherAssembly.dll должна находиться в том же каталоге, что и сборка myAssembly.dll.

Примечание.
Исполняемые файлы управляемого кода, развернутые Internet Explorer с помощью связи HREF, не должны запускаться с аргументами командной строки. Аргументы не могут быть нормально переданы в исполняемый файл.

Отчетность по ошибкам

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

HKLM\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM
HKCU\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM

Для задания порядка отчетности об ошибках обеими параметрами используются следующие значения.

Значение	Описание
1	Сведения об ошибках отправляются в стандартный выходной поток.
2	Сведения об ошибках показываются пользователю.
3	Сведения об ошибках отправляются в стандартный выходной поток и показываются пользователю.

При отладке управляемого кода, разворачиваемого с помощью Internet Explorer, можно использовать значения этих параметров для поиска подробных сведений об ошибках загрузки кода. Например, это позволяет просмотреть сведения о трассировке стека при выдаче исключений вместо того, чтобы полагаться на отчетность по ошибкам, предоставляемую обозревателем Internet Explorer, который предназначен для конечного пользователя и не рассчитан на потребности разработчиков.

Элементы управления, размещаемые в Internet Explorer

Для размещения элементов управления, созданных с помощью .NET Framework, можно использовать Internet Explorer. Элементы управления должны содержаться в библиотеке с расширением ".dll". Для использования элементов управления форм Windows как автономно, так и с размещением в Internet Explorer, библиотека должна в обоих случаях иметь расширение ".dll".

Важное примечание.
Все управляемые элементы управления, размещаемые в Internet Explorer, используют последнюю версию общеязыковой среды выполнения, установленную на компьютере. Это означает, что в некоторых случаях элемент управления может не выполняться в той версии среды выполнения, для которой он был создан, и, возможно, элемент управления не будет выполняться под управлением политики безопасности, для которой он первоначально предназначался. До запуска управляемого элемента управления в новой версии общеязыковой среды выполнения следует обновить политику безопасности для новой версии среды выполнения. Это правило применяется к любой зоне безопасности, но не применяется к загружаемым управляемым исполняемым файлам.

Все управляемые элементы управления, размещаемые в Internet Explorer, используют последнюю версию общеязыковой среды выполнения, установленную на компьютере. Это означает, что в некоторых случаях элемент управления может не выполняться в той версии среды выполнения, для которой он был создан, и, возможно, элемент управления не будет выполняться под управлением политики безопасности, для которой он первоначально предназначался. До запуска управляемого элемента управления в новой версии общеязыковой среды выполнения следует обновить политику безопасности для новой версии среды выполнения. Это правило применяется к любой зоне безопасности, но не применяется к загружаемым управляемым исполняемым файлам.

Примечание.
При загрузке управляемого элемента управления максимальная длина значения для атрибута classid элемента <object> равна 256 знакам (MAX_PATH). Если длина превышает максимальное значение, элемент управления не загружается, но никакой ошибки не возникает. Например, следующее значение атрибута classid является допустимой длиной: <object id="myCtl" classid="http://www.example.com/mycode.dll#myClass">

При загрузке управляемого элемента управления максимальная длина значения для атрибута classid элемента <object> равна 256 знакам (MAX_PATH). Если длина превышает максимальное значение, элемент управления не загружается, но никакой ошибки не возникает. Например, следующее значение атрибута classid является допустимой длиной:

Примечание.
По соображениям безопасности управляемые элементы управления, использующие тег <object> и протокол доступа к файлам на HTML-странице, не поддерживаются. Например, следующий тег <object> не поддерживается: <OBJECT classid="file:///c:/control.dll#control">

По соображениям безопасности управляемые элементы управления, использующие тег <object> и протокол доступа к файлам на HTML-странице, не поддерживаются. Например, следующий тег <object> не поддерживается:

Обнаружение зависимых сборок

Процесс, используемый средой выполнения для обнаружения зависимых сборок для веб-приложений, подобен процессу, используемому для обычных приложений. Среда выполнения осуществляет поиск частных зависимых сборок, используя путь, указываемый относительно ApplicationBase. Для обнаружения частных сборок средой выполнения используется комбинация ApplicationBase, тега <private_binpath> в файле конфигурации и правил поиска. Для проверки зависимых сборок среда выполнения также проверяет URL-адрес, по которому расположена вызывающая сборка.

Подписание управляемого кода подписью Microsoft Authenticode

Для подписания файла цифровой подписью Authenticode можно воспользоваться сведениями статьи Средство (Signcode.exe) подписания файлов. Следует заметить, что в случае необходимости подписи как строгим именем, так и цифровой подписью Authenticode, сначала должно выполняться подписание строгим именем. Если сначала присвоить подпись Authenticode, то строгое имя будет нарушено. Дополнительные сведения о подписании файлов см. в разделе Вопросы безопасности сборок. Сведения о подписании файлов с помощью Visual Studio 2005 см. в разделе "Развертывание и подписание по технологии Authenticode" в документации Visual Studio 2005. Дополнительные сведения о технологии подписания Authenticode см. в разделе "Общие сведения о подписании кода" в документации Platform SDK.