Accueil Library Formation Code Téléchargements Support Evénements Communautés Forums
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte.
Traduction
Source
0 sur 1 ont trouvé cela utile - Évaluez ce sujet

Fonctionnement de la compilation dynamique d'ASP.NET

.NET Framework 4

Pour que votre application Web traite les demandes de service, ASP.NET doit d'abord analyser et compiler le code de l'application en un ou plusieurs assemblys. Lorsque le code est compilé, il est traduit en une représentation indépendante du langage et de l'UC, intitulée Microsoft Intermediate Language (MSIL). Au moment de l'exécution, MSIL s'exécute dans le contexte du .NET Framework, qui traduit le MSIL en instructions spécifiques à l'UC pour le processeur de l'ordinateur exécutant l'application.

La compilation dynamique ASP.NET vous permet de modifier votre code source sans devoir compiler explicitement votre code avant de déployer votre application Web. Si vous modifiez un fichier source, ASP.NET recompile automatiquement le fichier et met à jour toutes les ressources liées. Le serveur IIS ne doit pas être redémarré pour que les modifications entrent en vigueur sauf si la section <processModel> a été modifiée.

Vous pouvez étendre le système de génération ASP.NET en créant des fournisseurs de générations personnalisés pour les nouveaux types de fichiers qui sont appelés pendant la compilation.

Par défaut, les pages Web ASP.NET et les fichiers de code sont compilés dynamiquement lorsque les utilisateurs demandent pour la première fois une ressource, telle qu'une page ASP.NET (fichier .aspx), sur un site Web. Après avoir compilé pour la première fois les pages et les fichiers de code, les ressources compilées sont mises en cache, afin que les demandes suivantes de la même page soient extrêmement efficaces.

ASP.NET prend en charge la compilation dynamique de pages ASP.NET (fichiers .aspx), de services Web ASP.NET (fichiers .asmx), de gestionnaires HTTP ASP.NET (fichiers .ashx) et de fichiers d'application ASP.NET (Global.asax), ainsi que d'autres fichiers, tels que les fichiers de code source et de classe. Pour plus d'informations sur les types de fichiers ASP.NET, consultez Types de fichiers de projet Web ASP.NET. Pour plus d'informations sur le processus de compilation ASP.NET, consultez la section « Cycle de vie de compilation » de Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0.

Toute modification apportée à un fichier compilé de façon dynamique invalidera automatiquement l'assembly compilé mis en cache du fichier et déclenchera une recompilation de toutes les ressources affectées. La prochaine fois qu'une demande de code est effectuée, ASP.NET reconnaît que le code a changé et recompile les ressources affectées de l'application Web. Ce système vous permet de développer rapidement des applications avec un minimum de surcharge de traitement de compilation. (Notez que, selon les modifications apportées aux ressources, le résultat peut varier de la recompilation d'une seule page à celle de l'intégralité du site Web.)

Lorsque la première demande est envoyée à une application, ASP.NET compile les fichiers dans un ordre spécifique. Les premiers éléments à être compilés sont appelés éléments de niveau supérieur. Après la première demande, les éléments de niveau supérieur ne sont recompilés que si une dépendance change.

Les éléments de niveau supérieur incluent le dossier App_GlobalResources, le dossier App_WebResources, les propriétés de profil, le dossier App_Code et le fichier Global.asax. Après avoir compilé les éléments de niveau supérieur, ASP.NET compile les éléments supplémentaires. Ces éléments incluent le dossier App_LocalResources, les pages ASP.NET individuelles (fichiers .aspx), les contrôles utilisateur ASP.NET (fichiers .ascx), les gestionnaires HTTP ASP.NET (fichiers .ashx) et les modules HTTP ASP.NET (fichiers .asmx), ainsi que les thèmes, pages maîtres et autres fichiers sources.

Pour plus d'informations, consultez Structure des dossiers de projet Web ASP.NET et la section « Cycle de vie de compilation » de Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0.

Lorsque votre code est compilé, les assemblys résultants sont mis en cache dans un dossier sur le serveur. Ce dossier requiert des autorisations appropriées afin que votre code soit compilé et exécuté correctement. Vous pouvez configurer à la fois l'emplacement du dossier de compilation et les autorisations sous lesquelles votre code est compilé et fonctionne.

Emplacement du dossier de compilation

Par défaut, lorsque vous compilez une application Web, le code compilé est placé dans le dossier Temporary ASP.NET Files. Ce dossier est un sous-répertoire de l'emplacement où vous avez installé le .NET Framework. En général, l'emplacement est le suivant :

Copier 
%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files

Autorisations requises pour le dossier de compilation

La procédure d'installation .NET crée le dossier Temporary ASP.NET Files et assigne des autorisations d'accès au compte d'utilisateur local ASP.NET qui a les autorisations de niveau de confiance élevé nécessaires pour accéder à votre code compilé. Si vous modifiez votre configuration ou les paramètres de compte, vous devez vous assurer que le compte que vous utilisez a des autorisations de niveau de confiance élevé sur le dossier Temporary ASP.NET Files. Pour plus d'informations, consultez Comment : exécuter le processus de travail sous un compte d'utilisateur.

Configurabilité du dossier de compilation

ASP.NET crée un sous-dossier discret sous le dossier Temporary ASP.NET Files pour chaque application. Vous pouvez configurer l'emplacement racine à l'aide de l'attribut tempDirectory de la section de compilation du fichier de configuration. Cet attribut facultatif vous permet de spécifier le répertoire à utiliser pour le stockage de fichier temporaire pendant la compilation. La valeur par défaut est une chaîne vide (""). Dans le cas d'une chaîne vide et si le processus actuel a les autorisations d'accès requises, les fichiers sont stockés dans le répertoire suivant :

Copier 
%FrameworkInstallLocation%\Temporary ASP.NET Files

Pour plus d'informations, consultez compilation, élément (Schéma des paramètres ASP.NET) et la propriété TempDirectory de la CompilationSection.

ASP.NET 2.0 prend en charge plusieurs langages de programmation dans la même application Web. Dans le répertoire App_Code, vous pouvez spécifier un sous-dossier pour chaque langage, tel que C# et Visual Basic. ASP.NET créera un assembly séparé pour chaque sous-dossier. Pour plus d'informations, consultez Dossiers de code partagé dans des projets Web ASP.NET et Procédure pas à pas : utilisation de plusieurs langages de programmation dans un projet de site Web.

Par défaut, lorsque des modifications sont apportées à un fichier de niveau supérieur sur un site Web, le site entier est recompilé. Les fichiers de niveau supérieur incluent le fichier global.asax et tous les fichiers contenus dans les dossiers bin et App_Code. Il est plus prudent de recompiler le site entier lorsque l'un de ces fichiers change, car les autres fichiers du site, tels que les fichiers .aspx et .ascx, peuvent référencer les objets créés par du code dans les fichiers de niveau supérieur.

Alors que la recompilation complète fonctionne bien pour la plupart des applications, elle peut provoquer l'indisponibilité d'applications de très grande taille pendant de longues périodes, même si les modifications effectuées ne sont que mineures. Si l'application est de grande taille, elle peut être indisponible pendant cinq à dix minutes ou plus après l'exécution d'une modification.

Si vous souhaitez être en mesure de modifier des fichiers de niveau supérieur sans provoquer la recompilation du site entier, vous pouvez affecter la valeur true à l'attribut optimizeCompilations de l'élément de compilation. Si optimizeCompilations a la valeur true, lorsque vous modifiez un fichier de niveau supérieur, seuls les fichiers concernés sont recompilés. Cela gagne du temps mais peut provoquer des erreurs d'exécution selon le type des modifications que vous apportez à un fichier de niveau supérieur.

Les types suivants de modifications sont généralement sûrs :

  • Modification d'une implémentation de méthode. Étant donné que la signature n'est pas modifiée, les pages compilées avec l'ancienne version peuvent appeler la méthode sans lever une exception.

  • Ajout de nouvelles méthodes ou propriétés. Étant donné que celles-ci n'existaient pas avant, aucune page déjà compilée ne les référence et aucune exception n'est levée.

  • Ajout d'un attribut CLR à un membre existant. Il s'agit d'un scénario Dynamic Data typique dans lequel vous ajoutez des attributs comme DisplayName aux propriétés. Étant donné que les attributs CLR sont découverts pendant l'exécution via la réflexion, il n'est pas nécessaire de recompiler les pages existantes.

Les types suivants de modifications peuvent provoquer des exceptions runtime :

  • Attribution d'un nouveau nom à des méthodes ou des propriétés ou suppression de celles-ci. Si le membre affecté est référencé par une page déjà compilée, une exception sera levée.

  • Modification de la signature d'une méthode ou du type d'une propriété. Si le membre affecté est référencé par une page déjà compilée, une exception sera levée. Certaines modifications de signature ne provoquent pas d'erreurs de compilation ou d'exécution si le site entier est recompilé. Par exemple, la compilation et l'exécution du code Response.Write(ClassA.MethodA() sur une page .aspx s'effectueront correctement si MethodA retourne int ou short. En revanche, si la page .aspx est déjà compilée et si vous remplacez le type de retour de MethodA int par short sans effectuer de recompilation, une exception runtime sera levée car le code compilé attend la signature int.

Si vous souhaitez utiliser l'attribut optimizeCompilations pour réduire le temps de compilation dynamique, vous devez soigneusement revoir chaque modification apportée aux fichiers de niveau supérieur sur votre site ; si une modification particulière n'est pas sécurisée, vous devez supprimer temporairement l'attribut optimizeCompilations ou lui affecter la valeur false.

Il existe certaines fonctions que la compilation dynamique n'offre pas. La compilation dynamique peut signifier un temps de réponse initial plus lent pour les utilisateurs, car les pages et fichiers de code doivent être compilés la première fois qu'ils sont demandés. Cela peut représenter un problème, particulièrement pour les grands sites qui sont fréquemment mis à jour. La compilation dynamique n'offre pas de moyen pour identifier les bogues de compilation avant que les utilisateurs n'accèdent à un site. Par ailleurs, elle n'offre pas la possibilité de créer une version compilée du site qui peut être déployée sur un serveur de production sans code source. Si l'un de ces points est un problème pour vos applications Web, vous pouvez précompiler votre site Web. Pour plus d'informations, consultez Vue d'ensemble de la précompilation ASP.NET.

Cela vous a-t-il été utile ?
(1500 caractères restants)

Ajouts de la communauté

AJOUTER
© 2013 Microsoft. Tous droits réservés.
|
Commentaires sur le site
© 2013 Microsoft. Tous droits réservés.