Déploiement d'une application Runtime à l'aide d'Internet Explorer

Article
08/21/2008

Mise à jour : novembre 2007

Les applications Web peuvent utiliser Microsoft Internet Explorer 5.5 (ou version ultérieure) pour télécharger et exécuter des assemblys. Une application Web peut télécharger les deux types standard de fichiers exécutables portables (PE, Portable Executable) : .exe ou .dll. Un document HTML peut fournir des informations sur les assemblys à télécharger, les emplacements des assemblys et l'emplacement d'un fichier de configuration qui peut contenir des informations supplémentaires.

L'un des avantages du déploiement d'une application à l'aide d'Internet Explorer est que les assemblys ne sont téléchargés que lorsqu'ils sont utilisés. Si l'application consiste en plusieurs assemblys, ceux-ci ne sont téléchargés que lorsqu'ils sont référencés. Ce processus automatique permet un téléchargement initial d'une application plus rapide, parce qu'il n'est pas nécessaire de télécharger la totalité de l'application et que le client reçoit seulement le code qu'il utilise.

Remarque :
Le code déployé à partir d'Internet dispose en général des autorisations Internet par défaut définies par la stratégie de sécurité. Ces autorisations permettent au code de n'exécuter qu'un ensemble restreint de fonctions. Pour plus d'informations sur la stratégie de sécurité Internet par défaut, consultez Stratégie de sécurité.

Paramètres des applications Web

Par défaut, le Common Language Runtime crée un domaine d'application pour chaque site accédé en utilisant Internet Explorer. Les domaines d'application isolent des applications séparées qui s'exécutent dans un processus. La façon dont les domaines d'application sont créés affecte les autorisations des assemblys lors de leur exécution dans le domaine. Chaque domaine d'application est associé à une preuve d'URL ainsi qu'à une base d'application et peut également posséder un fichier de configuration.

Preuve d'URL

Une preuve d'URL est assignée aux applications déployées à l'aide de Microsoft Internet Explorer 5.5 ou version ultérieure. L'hôte du runtime utilise cette preuve d'URL pour arrêter des décisions fondées sur la stratégie de sécurité. Bien que la preuve d'URL soit associée à la fois aux assemblys qui constituent l'application et au domaine d'application créé par l'application, son format est différent dans chaque cas. Pour un assembly, la preuve d'URL est le chemin d'accès complet du fichier d'assembly principal. Par exemple, un assembly faisant partie d'une application peut avoir la preuve d'URL http://www.code.microsoft.com/myApp/myAssembly.dll. La preuve d'URL du domaine de l'application est équivalente à la preuve du site. Dans l'exemple précédent, la preuve d'URL du domaine d'application serait donc http://www.code.microsoft.com/.

Remarque :
L'emplacement du fichier de configuration de l'application n'a pas d'incidence sur la preuve d'URL du domaine de l'application.

Fichiers de configuration

Les applications Web déployées à l'aide d'Internet Explorer peuvent utiliser des informations stockées dans un fichier de configuration de l'application. Le fichier de configuration de l'application doit résider sur le serveur Web, dans le même répertoire que l'exécutable de l'application. Il doit suivre les règles d'attribution de nom des fichiers de configuration de l'application. Il doit porter le même nom que l'exécutable, suivi de l'extension .config. Par exemple, une application appelée myApplication.exe aurait un fichier de configuration de l'application appelé myApplication.exe.config.

Les applications ASP.NET spécifient les informations de configuration en utilisant un fichier Web.config. Les applications Web peuvent fournir des informations de configuration tout comme ASP.NET et un hôte exécutable. Si une application hébergée dans Internet Explorer possède un fichier de configuration, l'emplacement du fichier de configuration est spécifié dans une balise <link> avec la syntaxe suivante :

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

Dans cet exemple, [nom du fichier de configuration] est le nom du fichier de configuration, par exemple :

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

Pour les scénarios d'applications Web de base, où la page Web ne fournit pas de balise <link> vers un fichier de configuration, le runtime crée un domaine d'application en fonction de chaque site. Autrement dit, si le document HTML réside à l'adresse http://www.code.microsoft.com/myApp/mypage.htm, le domaine d'application est créé sur l'ensemble du site http://www.code.microsoft.com. Notez que ce scénario est pratique pour l'auteur de l'application Web, mais que toutes les pages Web qui utilisent des assemblys de code managé sur ce site partagent le même domaine d'application, parce qu'aucun fichier de configuration n'a été spécifié.

Si l'application lit les informations dans un fichier de configuration de l'application, vous devez effectuer les opérations suivantes :

Placez le fichier de configuration au même emplacement que l'exécutable.
Autorisez l'accès anonyme au site Web et le répertoire contenant le fichier de configuration doit permettre l'exécution de script.

Dans un scénario plus complexe, deux applications disparates ou plus peuvent être nécessaires pour s'exécuter sur le même site tout en restant isolées. Pour réussir cette isolation, l'auteur de la page Web doit spécifier un fichier de configuration dans le document HTML. Toutes les pages qui pointent vers le même fichier de configuration sont créées dans le même domaine d'application. De cette manière, il est possible de créer un domaine d'application pour chaque fichier de configuration.

Remarque :
Le runtime ne prend pas en charge le caractère "#" dans des URL qui pointent vers un fichier de configuration lorsque la balise <link> contient un chemin relatif.

Base de l'application

ApplicationBase est une propriété du domaine d'application qui spécifie le répertoire racine lorsque le runtime recherche des assemblys. Par défaut, la propriété ApplicationBase est considérée comme la racine du site (par exemple, wwwroot). Si un fichier de configuration de l'application existe, ApplicationBase devient son emplacement. Le fichier de configuration peut contenir des informations de configuration spécifiques au code exécuté dans le domaine d'application. Si plusieurs sites sont définis sur un ordinateur, ApplicationBase a comme valeur par défaut le site « par défaut » défini sur le port 80.

Téléchargement des exécutables managés

Alors que la plupart des applications téléchargées en utilisant la balise <object> sont des contrôles d'interface utilisateur qui apparaissent sur la page Web, le runtime prend également en charge deux scénarios permettant de télécharger les fichiers exécutables managés :

Un utilisateur tape l'URL d'un fichier .exe managé dans le navigateur ; par exemple :
```
http://www.server.microsoft.com/MyWebSite/MyApp.exe.
```
Une page HTML contient un lien vers un fichier exécutable managé ; par exemple :
```
HREF="MyApp.exe".
```

Dans les deux cas, le runtime crée un nouveau domaine d'application dans lequel les fichiers exécutables sont exécutés. Pour les demandes d'assemblys suivantes, la base d'application est définie comme étant l'emplacement du fichier exécutable.

Par exemple, le code suivant référence myClass :

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

Les assemblys dépendants qui sont liés statiquement doivent être situés dans le même répertoire que l'assembly appelant lorsque ce dernier est spécifié en utilisant la balise <object>. Par exemple, si l'assembly monAssembly.dll est spécifié en utilisant une balise <object> et qu'il possède une référence statique à l'assembly monAutreAssembly.dll, ce dernier doit alors être situé dans le même répertoire que monAssembly.dll.

Remarque :
Les exécutables de code managé déployés par Internet Explorer à l'aide d'un lien HREF ne doivent pas être démarrés avec des arguments de ligne de commande. Les arguments ne sont pas passés avec succès à l'exécutable.

Rapport d'erreurs

Le processus de téléchargement du code utilise les deux paramètres du Registre suivants pour contrôler le rapport d'erreurs des exécutables de code managé déployés à l'aide d'Internet Explorer.

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

Ces deux paramètres utilisent les valeurs suivantes pour spécifier le rapport d'erreurs.

Valeur	Description
1	Les informations relatives aux erreurs sont envoyées au flux de sortie standard.
2	Les informations relatives aux erreurs sont affichées à l'utilisateur.
3	Les informations relatives aux erreurs sont envoyées au flux de sortie standard et sont affichées à l'utilisateur.

Lorsque vous déboguez le code managé déployé à l'aide d'Internet Explorer, vous pouvez utiliser les valeurs de ces paramètres pour rechercher des informations détaillées sur les échecs de téléchargement du code. Par exemple, cela permet de consulter les informations de traçage de la pile lorsque des exceptions sont levées, au lieu de se limiter au rapport d'erreurs fourni par Internet Explorer qui a été conçu pour les utilisateurs finals et non pour les développeurs.

Contrôles hébergés dans Internet Explorer

Vous pouvez utiliser Internet Explorer pour héberger des contrôles créés à l'aide du .NET Framework. Les contrôles doivent être contenus dans une bibliothèque dotée d'une extension .dll. Pour utiliser le même contrôle Windows Form en tant que contrôle autonome et hébergé dans Internet Explorer, la bibliothèque doit porter l'extension .dll pour fonctionner dans l'un et l'autre cas.

Remarque importante :
Tous les contrôles managés hébergés par Internet Explorer utilisent la dernière version du Common Language Runtime installée sur l'ordinateur. Cela signifie que dans certaines instances, le contrôle ne peut pas s'exécuter contre la version pour laquelle il a été construit et le contrôle ne peut pas s'exécuter sous la même stratégie de sécurité que prévu à l'origine. Avant d'exécuter un contrôle managé sous une nouvelle version du common language runtime, la stratégie de sécurité doit être mise à jour pour la nouvelle version du runtime. Cela s'applique à toutes les zones de sécurité, mais pas aux exécutables managés téléchargés.

Tous les contrôles managés hébergés par Internet Explorer utilisent la dernière version du Common Language Runtime installée sur l'ordinateur. Cela signifie que dans certaines instances, le contrôle ne peut pas s'exécuter contre la version pour laquelle il a été construit et le contrôle ne peut pas s'exécuter sous la même stratégie de sécurité que prévu à l'origine. Avant d'exécuter un contrôle managé sous une nouvelle version du common language runtime, la stratégie de sécurité doit être mise à jour pour la nouvelle version du runtime. Cela s'applique à toutes les zones de sécurité, mais pas aux exécutables managés téléchargés.

Remarque :
Lors du chargement d'un contrôle managé, la longueur maximale de la valeur pour l'attribut classid de l'élément <object> est 256 caractères (MAX_PATH). Si la longueur est supérieure au maximum, le contrôle ne procède pas au chargement, mais aucune erreur n'est générée. Par exemple, la valeur suivante de l'attribut classid a une longueur acceptable : <object id="myCtl" classid="http://www.example.com/mycode.dll#myClass">

Lors du chargement d'un contrôle managé, la longueur maximale de la valeur pour l'attribut classid de l'élément <object> est 256 caractères (MAX_PATH). Si la longueur est supérieure au maximum, le contrôle ne procède pas au chargement, mais aucune erreur n'est générée. Par exemple, la valeur suivante de l'attribut classid a une longueur acceptable :

Remarque :
Pour des raisons de sécurité, les contrôles managés utilisant la balise <object> et le protocole d'accès aux fichiers dans une page HTML ne sont pas pris en charge. Par exemple, la balise <object> suivante n'est pas prise en charge : <OBJECT classid="file:///c:/control.dll#control">

Pour des raisons de sécurité, les contrôles managés utilisant la balise <object> et le protocole d'accès aux fichiers dans une page HTML ne sont pas pris en charge. Par exemple, la balise <object> suivante n'est pas prise en charge :

Localisation d'assemblys dépendants

Le processus utilisé par le runtime pour localiser des assemblys dépendants pour les applications Web est analogue à celui qui est utilisé pour les applications non Web. Le runtime recherche les assemblys dépendants privés en utilisant un chemin d'accès relatif à la propriété ApplicationBase. Le runtime combine la propriété ApplicationBase, la balise <private_binpath> dans un fichier de configuration et les règles de recherche pour localiser des assemblys privés. Le runtime vérifie également l'URL où l'assembly appelant est situé pour vérifier la présence éventuelle d'assemblys dépendants.

Signature du code managé avec une signature Microsoft Authenticode

Vous pouvez utiliser l'outil File Signing Tool (Signcode.exe) pour signer un fichier avec une signature numérique Authenticode. Notez que si vous souhaitez signer un fichier avec un nom fort et une signature numérique Authenticode, vous devez d'abord assigner le nom fort. Car en assignant d'abord la signature Authenticode, vous corromprez le nom fort. Pour plus d'informations, consultez Aspects de la sécurité des assemblys. Pour plus d'informations sur la signature de fichier à l'aide de Visual Studio 2005, consultez « Déploiement et signature Authenticode » dans la documentation Visual Studio 2005. Pour plus d'informations sur la technologie de signature Authenticode, consultez « Introduction to Code Signing » dans la documentation du Kit de développement Platform SDK.