Implementar una aplicación en tiempo de ejecución mediante Internet Explorer
Las aplicaciones Web pueden utilizar Microsoft Internet Explorer 5.5 o una versión posterior para descargar y ejecutar ensamblados. Una aplicación Web puede descargar los dos tipos de archivos estándar ejecutables portables (PE) que existen, archivos .exe y archivos .dll. Un documento HTML puede proporcionar información sobre los ensamblados que se han de descargar, sus ubicaciones y la ubicación de un archivo de configuración que puede proporcionar información adicional.
Una ventaja cuando se utiliza Internet Explorer para implementar una aplicación es que los ensamblados se descargan sólo cuando se utilizan. Si la aplicación consta de varios ensamblados, éstos se descargan solamente cuando se hace referencia a ellos. Este proceso automático proporciona una descarga inicial más rápida de una aplicación ya que no se tiene que descargar toda la aplicación, y el cliente sólo recibe el código que utiliza.
Nota
El código implementado desde Internet suele tener los permisos de Internet predeterminados, establecidos por la directiva de seguridad. Estos permisos dejan que el código realice sólo un conjunto limitado de funciones. Para obtener más información sobre la directiva de seguridad predeterminada de Internet, vea Directiva de seguridad.
Configuración de aplicaciones Web
De forma predeterminada, Common Language Runtime crea un dominio de aplicación para cada sitio al que se obtiene acceso utilizando Internet Explorer. Los dominios de aplicación aíslan las aplicaciones independientes que se ejecutan dentro de un proceso. El modo en que se crean los dominios de aplicación afecta a los permisos que tienen los ensamblados cuando se ejecutan en el dominio. Cada dominio de aplicación se asocia a una evidencia de dirección URL y a una base de la aplicación y también podría tener un archivo de configuración.
Evidencia de dirección URL
La evidencia de dirección URL se asigna a aplicaciones implementadas con Microsoft Internet Explorer 5.5 o posterior. El host de motor en tiempo de ejecución utiliza esta evidencia de dirección URL para tomar decisiones basándose en la directiva de seguridad. Aunque la evidencia de dirección URL se asocia tanto con los ensamblados que componen la aplicación como con el dominio que crea la aplicación, el formato de la evidencia es distinto en cada caso. Para el ensamblado, la evidencia de dirección URL es la ruta completa de acceso URL al archivo de ensamblado principal. Por ejemplo, un ensamblado que sea parte de una aplicación podría tener la evidencia de dirección URL de http://www.code.microsoft.com/myApp/myAssembly.dll. La evidencia de dirección URL para el dominio de la aplicación es equivalente a la evidencia del sitio. Al utilizar el ejemplo anterior, la evidencia de dirección URL para el dominio de la aplicación sería http://www.code.microsoft.com/.
Nota
La ubicación del archivo de configuración de la aplicación no influye en la evidencia de dirección URL para el dominio de la aplicación.
Archivos de configuración
Las aplicaciones Web implementadas usando Internet Explorer pueden utilizar información almacenada en un archivo de configuración de la aplicación. El archivo de configuración de una aplicación debe estar en el servidor Web en el mismo directorio que la aplicación ejecutable. El archivo de configuración de la aplicación debe seguir las reglas de nomenclatura de los archivos de configuración de la aplicación. El archivo debe tener el mismo nombre que el ejecutable, con la extensión .config anexada al mismo. Por ejemplo una aplicación denominada myApplication.exe tendría un archivo de configuración de la aplicación denominado myApplication.exe.config.
Las aplicaciones ASP.NET especifican la información de configuración mediante un archivo web.config. Las aplicaciones Web pueden suministrar información sobre la configuración, del mismo modo que lo hacen ASP.NET y un host ejecutable. Si una aplicación alojada en Internet Explorer tiene un archivo de configuración, la ubicación de este archivo se especifica en una etiqueta <link> con la sintaxis siguiente:
<LINK REL="CONFIGURATION" NavigateURL="[configuration file name]"></LINK>
En este ejemplo, [configuration file name] es el nombre del archivo de configuración, por ejemplo:
<LINK REL="CONFIGURATION" NavigateURL="two.dll.config"></LINK>
Para los escenarios básicos de aplicaciones Web, donde la página Web no proporciona una etiqueta <link> a un archivo de configuración, el motor en tiempo de ejecución crea un dominio de aplicación por cada sitio. O sea, si el documento HTML reside en http://www.code.microsoft.com/myApp/mypage.htm, el dominio de la aplicación se crea sobre todo el sitio http://www.code.microsoft.com. Hay que tener en cuenta que aunque este escenario resulte adecuado para el creador de la página Web, todas las páginas Web que utilizan ensamblados de código administrado en este sitio comparten el mismo dominio de aplicación porque no se ha especificado ningún archivo de configuración.
Si la aplicación lee información de un archivo de configuración de la aplicación, debe seguir este procedimiento:
Coloque el archivo de configuración en la misma ubicación que el archivo ejecutable.
Permita el acceso anónimo al sitio Web, y el directorio que contiene el archivo de configuración debe permitir la ejecución de las secuencias de comandos.
En un escenario más complejo, es posible que dos o más aplicaciones distintas tengan que ejecutarse en el mismo sitio, aunque estén aisladas entre sí. Para conseguir este aislamiento, el creador de la página Web debe especificar un archivo de configuración en el documento HTML. Todas las páginas que apuntan al mismo archivo de configuración se crean en el mismo dominio de aplicación. De este modo, se puede crear un dominio de aplicación para cada archivo de configuración.
Nota
El motor en tiempo de ejecución no admite el carácter '#' en las direcciones URL que señalan un archivo de configuración cuando la etiqueta <link> contiene una ruta de acceso relativa.
Base de aplicación
ApplicationBase es una propiedad del dominio de aplicación que especifica el directorio que actúa como directorio raíz cuando el motor en tiempo de ejecución busca ensamblados. De forma predeterminada, se considera que la propiedad ApplicationBase es la raíz del sitio (por ejemplo, wwwroot). Si está presente un archivo de configuración de la aplicación, ApplicationBase se convierte en la ubicación del archivo de configuración. El archivo de configuración puede contener información de configuración específica para el código que se ejecuta en el dominio de aplicación. Si hay más de un sitio definido en un equipo, ApplicationBase toma como valor predeterminado el sitio “predeterminado” definido en el puerto 80.
Descarga de archivos ejecutables administrados
Aunque la mayoría de las aplicaciones que se descargan mediante la etiqueta <object> son controles de interfaz de usuario que aparecen en la página Web, el motor en tiempo de ejecución también proporciona dos escenarios para la descarga de archivos ejecutables administrados:
Un usuario escribe la dirección URL de un archivo .exe administrado en el explorador; por ejemplo:
http://www.server.microsoft.com/MyWebSite/MyApp.exe.Una página HTML contiene un vínculo a un archivo ejecutable administrado, por ejemplo:
NavigateURL="MyApp.exe".
En ambos escenarios, el motor en tiempo de ejecución crea un nuevo dominio de aplicación en el que se puede ejecutar el archivo ejecutable. Para las peticiones de ensamblados posteriores, la base de aplicación se establece en la ubicación del archivo ejecutable.
Por ejemplo, el siguiente código hace referencia a myClass:
<object id="myCtl"
classid="http://www.mycode.Microsoft.com/mycode.dll#myClass">
</object>
Los ensamblados dependientes que están vinculados estáticamente pueden ubicarse en el mismo directorio que el ensamblado que realiza la llamada cuando éste se especifica mediante la etiqueta <object>. Por ejemplo, si el ensamblado myAssembly.dll se especifica mediante una etiqueta <object> y tiene una referencia estática a myOtherAssembly.dll, entonces myOtherAssembly.dll debe estar ubicado en el mismo directorio que myAssembly.dll.
Nota
Los archivos ejecutables de código administrado implementados con Internet Explorer mediante un vínculo NavigateURL no se deben iniciar con argumentos de línea de comandos. Los argumentos no pasan correctamente al archivo ejecutable.
Informes de errores
El proceso de descarga de código utiliza la dos siguientes opciones de configuración del Registro para controlar los informes de errores de aplicaciones ejecutables de código administrado que se implementan con Internet Explorer.
HKLM\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM
HKCU\Software\Microsoft\.NETFramework\ExposeExceptionsInCOM
En ambas opciones de configuración se utilizan los siguientes valores para especificar cómo informar de los errores.
| Valor | Descripción |
|---|---|
1 |
La información de error se envía a la secuencia de salida estándar. |
2 |
La información de error se muestra al usuario. |
3 |
La información de error se envía a la secuencia de salida estándar y se muestra al usuario. |
Cuando depure código administrado implementado con Internet Explorer, puede utilizar los valores de estas opciones de configuración para buscar información detallada sobre errores de descarga de código. Esto le permite, por ejemplo, ver información de seguimiento de pila cuando se producen excepciones, en vez de depender de los informes de errores que proporciona Internet Explorer, diseñados para los usuarios, no para los desarrolladores.
Controles alojados en Internet Explorer
Se puede utilizar Internet Explorer para alojar controles creados con .NET Framework. Una biblioteca con extensión .dll debe contener los controles. Para utilizar el mismo control de formularios Windows Forms como independiente y a la vez alojado en Internet Explorer, la biblioteca debe tener una extensión .dll con la que trabajar en ambos casos.
.gif) Importante |
|---|
Todos los controles administrados alojados en Internet Explorer utilizan la última versión de Common Language Runtime instalada en el equipo. Es decir, en algunas instancias puede que no se ejecute el control en la versión en la que se generó y quizá tampoco se ejecute en la misma directiva de seguridad como se pretendía originalmente. Antes de ejecutar un control administrado bajo una nueva versión de Common Language Runtime, se debe actualizar la directiva de seguridad para la nueva versión del motor en tiempo de ejecución. Esto se aplica a cualquier zona de seguridad, pero no a archivos ejecutables administrados descargados. |
Nota
Al cargar un control administrado, la longitud máxima del valor para el atributo classid del elemento <object> es de 256 caracteres (MAX_PATH). Si la longitud sobrepasa el límite máximo, el control no se carga pero no se genera ningún error. Por ejemplo, el valor de atributo classid siguiente es una longitud aceptable:
<object id="myCtl" classid="http://www.example.com/mycode.dll#myClass">
Nota
Por razones de seguridad, no se admiten los controles administrados que utilizan la etiqueta <object y un protocolo de acceso a archivos en una página HTML. Por ejemplo, no se admite la siguiente etiqueta <object>:
<OBJECT classid="file:///c:/control.dll#control">
Ubicar ensamblados dependientes
El proceso que el motor en tiempo de ejecución utiliza con objeto de localizar ensamblados dependientes para las aplicaciones basadas en Web es similar al proceso que emplea para las aplicaciones que no están basadas en Web. El motor en tiempo de ejecución busca ensamblados dependientes privados utilizando una ruta de acceso relativa a ApplicationBase. El motor en tiempo de ejecución emplea una combinación de AplicationBase, la etiqueta <private_binpath> de un archivo de configuración y las reglas de búsqueda para localizar ensamblados privados. Además, comprueba la dirección URL donde se ubica el ensamblado que realiza la llamada para comprobar los ensamblados dependientes.
Firma de código administrado con una firma Authenticode Microsoft
Puede utilizar la Herramienta firma de archivos (Signcode.exe) para firmar un archivo con una firma digital Authenticode. Tenga en cuenta que si desea firmar un archivo con un nombre seguro y una firma digital Authenticode, primero debe asignar el nombre seguro. Si asigna la firma Authenticode primero, el nombre seguro se bloquea. Para obtener más información sobre la firma de archivos, vea Consideraciones de seguridad de ensamblados. Para obtener información sobre la firma de archivos con Visual Studio 2005, vea el apartado sobre implementación y firma con Authenticode, en la documentación de Visual Studio 2005. Para obtener más información sobre la tecnología de firma con Authenticode, vea “Introducción a la firma de código” en la documentación de Platform SDK.
Vea también
Referencia
Herramienta Firma de archivos (Signcode.exe)
Conceptos
Escenarios de implementación de aplicaciones de .NET Framework
Consideraciones de seguridad sobre ensamblados
Cómo el motor en tiempo de ejecución ubica ensamblados