Précompilation de votre site web (C#)
par Scott Mitchell
Visual Studio offre aux développeurs ASP.NET deux types de projets : les projets d’application web (WAP) et les projets de site web (WSP). L’une des principales différences entre les deux types de projet est que les waP doivent avoir le code explicitement compilé avant le déploiement, tandis que le code dans un WSP peut être compilé automatiquement sur le serveur web. Toutefois, il est possible de précompiler un WSP avant le déploiement. Ce tutoriel explore les avantages de la précompilation et montre comment précompiler un site web à partir de Visual Studio et de la ligne de commande.
Introduction
Visual Studio offre aux développeurs ASP.NET deux types de projets différents : Projets d’application web (WAP) et Projets de site web (WSP). L’une des principales différences entre ces types de projets est que les WAP nécessitent une compilation explicite , tandis que les WSP utilisent la compilation automatique, par défaut. Avec les waps, vous compilez le code de l’application web dans un assembly unique, qui est créé dans le dossier du Bin site web. Le déploiement implique la copie du contenu de balisage (les .aspx.ascxfichiers et .master ) dans le projet, ainsi que l’assembly dans le Bin dossier ; les fichiers de classe code-behind eux-mêmes n’ont pas besoin d’être déployés. En revanche, vous déployez les WSP en copiant les pages de balisage et leurs classes code-behind correspondantes dans l’environnement de production. Les classes code-behind sont compilées à la demande sur le serveur web.
Notes
Pour plus d’informations sur les différences entre les modèles de projet, la compilation explicite et la compilation automatique, reportez-vous à la section « Compilation explicite et compilation automatique » du didacticiel Détermination des fichiers à déployer.
L’option de compilation automatique est simple à utiliser. Il n’y a pas d’étape de compilation explicite et seuls les fichiers qui ont été modifiés doivent être déployés, tandis que la compilation explicite nécessite le déploiement des pages de balisage modifiées et de l’assembly qui vient d’être compilé. Toutefois, le déploiement automatique présente deux inconvénients potentiels :
- Étant donné que les pages doivent être compilées automatiquement lors de leur première visite, il peut y avoir un délai court mais notable lorsqu’une page ASP.NET est demandée pour la première fois après avoir été déployée.
- La compilation automatique nécessite que le balisage déclaratif et le code source soient présents sur le serveur web. Il peut s’agir d’une option peu attrayante si vous envisagez de vendre l’application web aux clients qui l’installeront sur leurs serveurs web.
Si l’une des deux lacunes ci-dessus est des disjoncteurs, vous pouvez basculer vers le modèle WAP ou précompiler le WSP avant le déploiement. Ce tutoriel examine les options de précompilation les mieux adaptées à un site web hébergé et décrit le processus de précompilation et le déploiement d’un site web précompilé.
Vue d’ensemble de la génération et de la compilation de code ASP.NET
Avant d’examiner les options de précompilation disponibles, parlons d’abord de la génération et de la compilation de code qui se produisent lorsqu’une page ASP.NET est demandée pour la première fois depuis sa création ou sa dernière mise à jour. Comme vous le savez, ASP.NET pages sont composées de deux parties : le balisage déclaratif dans le .aspx fichier et une partie de code source, généralement dans un fichier de classe code-behind distinct (.aspx.cs). Les étapes effectuées par le runtime lorsqu’une page ASP.NET est demandée dépendent du modèle de compilation de l’application.
Avec les waps, le code source des pages doit être compilé explicitement dans un seul assembly avant d’être déployé. Pendant le déploiement, cet assembly et les différentes pages de balisage sont copiés dans l’environnement de production. Lorsqu’une requête arrive au serveur web pour une page ASP.NET, le runtime crée une instance de la classe code-behind de la page et appelle sa ProcessRequest méthode, qui démarre le cycle de vie de la page et, finalement, génère le contenu de la page, qui est retourné au demandeur. Le runtime peut fonctionner avec la classe code-behind de la page ASP.NET, car la classe code-behind a déjà été compilée dans un assembly avant le déploiement.
Avec les WSP et la compilation automatique, il n’existe aucune étape de compilation explicite avant le déploiement. Au lieu de cela, le déploiement implique de copier le contenu du code déclaratif et du code source dans l’environnement de production. Lorsqu’une requête arrive au serveur web pour une page ASP.NET pour la première fois depuis la création ou la dernière mise à jour de la page, le runtime doit d’abord compiler la classe code-behind dans un assembly. Cet assembly compilé est enregistré dans le dossier %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files, bien que l’emplacement de ce dossier puisse être personnalisé via l’élément <compilation tempDirectory="" /> de <system.web>, généralement dans Web.config. Étant donné que l’assembly est enregistré sur le disque, il n’a pas besoin d’être recompilé sur les demandes suivantes sur la même page.
Notes
Comme vous vous y attendez, il y a un léger retard lors de la demande d’une page pour la première fois (ou pour la première fois depuis qu’elle a été modifiée) dans un site qui utilise la compilation automatique, car il faut un moment au serveur pour compiler le code de la page et enregistrer l’assembly résultant sur le disque.
En bref, avec la compilation explicite, vous devez compiler le code source du site web avant le déploiement, ce qui évite au runtime d’effectuer cette étape. Avec la compilation automatique, le runtime gère la compilation du code source des pages, mais avec un léger coût d’initialisation pour la première visite de la page depuis sa création ou sa dernière mise à jour.
Mais qu’en est-il de la partie déclarative de ASP.NET pages (le .aspx fichier) ? Il est évident qu’il existe une relation entre les .aspx fichiers et le code dans leurs classes code-behind, car les contrôles Web définis dans le balisage déclaratif sont accessibles dans le code. Il est également évident que le contenu des .aspx fichiers influence considérablement le balisage rendu généré par la page. Comment le runtime fonctionne-t-il avec la syntaxe de contrôle texte, HTML et Web définie dans le .aspx fichier pour générer le contenu rendu de la page demandée ?
Je ne veux pas être trop à l’écart sur les détails d’implémentation de bas niveau, qui varient entre les waps et les WSP, mais en un mot, le runtime génère automatiquement un fichier de classe qui contient les différents contrôles Web en tant que membres et méthodes protégés. Ce fichier généré est implémenté en tant que classe partielle dans la classe code-behind correspondante. (Les classes partielles permettent de répartir le contenu d’une seule classe sur plusieurs fichiers.) Par conséquent, la classe code-behind est définie à deux endroits : dans le .aspx.cs fichier que vous créez et dans cette classe générée automatiquement créée par le runtime. Cette classe générée automatiquement est stockée dans le %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files dossier .
L’important à retenir ici est que pour qu’une page ASP.NET soit rendue par le runtime, ses parties de code déclaratif et source doivent être compilées dans un assembly. Avec les waps, le code source est compilé explicitement dans un assembly avant le déploiement, mais le balisage déclaratif doit toujours être converti en code et compilé par le runtime sur le serveur web. Avec les WSP qui utilisent la compilation automatique, le code source et le balisage déclaratif doivent être compilés par le serveur web.
Il est possible d’utiliser la compilation explicite avec le modèle WSP. Vous pouvez compiler explicitement la partie du code source, comme avec le modèle WAP. De plus, vous pouvez également compiler le balisage déclaratif.
Options de précompilation
Le .NET Framework est fourni avec un outil de compilation ASP.NET (aspnet_compiler.exe) qui vous permet de compiler le code source (et même le contenu) d’une application ASP.NET créée à l’aide du modèle WSP. Cet outil a été publié avec .NET Framework version 2.0 et se trouve dans le %WINDIR%\Microsoft.NET\Framework\v2.0.50727 dossier ; il peut être utilisé à partir de la ligne de commande ou lancé à partir de Visual Studio via l’option Publier le site web du menu Générer.
L’outil de compilation fournit deux formes générales de compilation : la précompilation sur place et la précompilation pour le déploiement. Avec la précompilation sur place, vous exécutez l’outil aspnet_compiler.exe à partir de la ligne de commande et spécifiez le chemin d’accès au répertoire virtuel ou au chemin physique d’un site web qui réside sur votre ordinateur. L’outil de compilation compile ensuite chaque page ASP.NET dans le projet, en stockant la version compilée dans le %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files dossier comme si les pages avaient chacune été visitées pour la première fois à partir d’un navigateur. La précompilation sur place peut accélérer la première requête adressée aux pages ASP.NET récemment déployées sur votre site, car elle permet au runtime d’éviter d’avoir à effectuer cette étape. Toutefois, la précompilation sur place n’est pas utile pour la majorité des sites web hébergés, car elle nécessite que vous puissiez exécuter des programmes à partir de la ligne de commande du serveur web. Dans les environnements d’hébergement partagé, ce niveau d’accès n’est pas autorisé.
Notes
Pour plus d’informations sur la précompilation sur place, consultez Guide pratique pour précompiler ASP.NET sites web et précompilation dans ASP.NET 2.0.
Au lieu de compiler les pages du site web dans le dossier, la précompilation pour le Temporary ASP.NET Files déploiement compile les pages dans un répertoire de votre choix et dans un format qui peut être déployé dans l’environnement de production.
Il existe deux versions de précompilation pour le déploiement que nous explorons dans ce tutoriel : la précompilation avec une interface utilisateur pouvant être mise à jour et la précompilation avec une interface utilisateur non modifiable. La précompilation avec une interface utilisateur pouvant être mise à jour laisse le balisage déclaratif dans les .aspxfichiers , .ascxet .master , ce qui permet à un développeur d’afficher et, si vous le souhaitez, de modifier le balisage déclaratif sur le serveur de production. La précompilation avec une interface utilisateur non modifiable génère des pages vides .aspx de contenu et supprime des fichiers, masquant .master.ascx ainsi le balisage déclaratif et interdisant au développeur de le modifier de l’environnement de production.
Précompilation pour le déploiement avec une interface utilisateur pouvant être mise à jour
La meilleure façon de comprendre la précompilation pour le déploiement consiste à voir un exemple en action. Nous allons précompiler le WSP Book Reviews pour le déploiement à l’aide d’une interface utilisateur pouvant être mise à jour. L’outil de compilation ASP.NET peut être appelé à partir du menu Build de Visual Studio ou de la ligne de commande. Cette section examine l’utilisation de l’outil à partir de Visual Studio ; La section « Précompilation à partir de la ligne de commande » examine l’exécution de l’outil compilateur à partir de la ligne de commande.
Ouvrez le WSP Book Review dans Visual Studio, accédez au menu Générer, puis sélectionnez l’option de menu Publier le site web. Cette opération lance la boîte de dialogue Publier le site web (voir la figure 1), dans laquelle vous pouvez spécifier l’emplacement cible, que l’interface utilisateur du site précompilé soit mise à jour ou non, ainsi que d’autres options de l’outil du compilateur. L’emplacement cible peut être un serveur web distant ou un serveur FTP, mais pour l’instant, choisissez un dossier sur le disque dur de votre ordinateur. Étant donné que nous voulons précompiler le site avec une interface utilisateur pouvant être mise à jour, laissez la case à cocher « Autoriser ce site précompilé à être mis à jour », puis cliquez sur OK.
Figure 1 : L’outil de compilation ASP.NET précompile votre site web à l’emplacement cible spécifié
(Cliquez pour afficher l’image en taille réelle)
Notes
L’option Publier un site web dans le menu Générer n’est pas disponible dans Visual Web Developer. Si vous utilisez Visual Web Developer, vous devez utiliser la version en ligne de commande de l’outil de compilation ASP.NET, qui est abordée dans la section « Précompilation à partir de la ligne de commande ».
Après avoir précompilé le site web, accédez à l’emplacement cible que vous avez entré dans la boîte de dialogue Publier le site web. Prenez un moment pour comparer le contenu de ce dossier avec le contenu de votre site web. La figure 2 montre le dossier du site web Book Reviews. Notez qu’il contient à la fois les .aspx fichiers et .aspx.cs . Notez également que le Bin répertoire comprend un seul fichier, Elmah.dll, que nous avons ajouté dans le didacticiel précédent
Figure 2 : Le répertoire du projet contient .aspx des fichiers et .aspx.cs ; le Bin dossier inclut juste Elmah.dll
(Cliquez pour afficher l’image en taille réelle)
La figure 3 montre le dossier d’emplacement cible dont le contenu a été créé par l’outil de compilation ASP.NET. Ce dossier ne contient aucun fichier code-behind. En outre, le répertoire de Bin ce dossier comprend plusieurs assemblys et deux .compiled fichiers en plus de l’assembly Elmah.dll .
Figure 3 : Le dossier emplacement cible inclut les fichiers pour le déploiement
(Cliquez pour afficher l’image en taille réelle)
Contrairement à la compilation explicite dans les wanps, le processus de précompilation pour le déploiement ne crée pas un assembly pour l’ensemble du site. Au lieu de cela, il regroupe plusieurs pages dans chaque assembly. Il compile également le fichier (le Global.asax cas échéant) dans son propre assembly, ainsi que toutes les classes du App_Code dossier. Les fichiers qui contiennent le balisage déclaratif pour ASP.NET pages web, les contrôles utilisateur et les pages maîtres (.aspx, .ascxet .master les fichiers, respectivement) sont copiés en l’état dans le répertoire d’emplacement cible. De même, le Web.config fichier est copié directement, ainsi que tous les fichiers statiques, tels que les images, les classes CSS et les fichiers PDF. Pour obtenir une description plus formelle de la façon dont l’outil de compilation gère différents types de fichiers, consultez Gestion des fichiers pendant ASP.NET précompilation.
Notes
Vous pouvez demander à l’outil de compilation de créer un assembly par ASP.NET page, contrôle utilisateur ou page maître en cochant la case « Nommage fixe et assemblys de page unique utilisés » dans la boîte de dialogue Publier un site web. Le fait que chaque page ASP.NET soit compilée dans son propre assembly permet un contrôle plus précis sur le déploiement. Par exemple, si vous avez mis à jour une seule page web ASP.NET et que vous deviez déployer cette modification, vous devez uniquement déployer le fichier de .aspx cette page et l’assembly associé à l’environnement de production. Pour plus d’informations , consultez Guide pratique pour générer des noms fixes avec l’outil de compilation ASP.NET .
Le répertoire d’emplacement cible contient également un fichier qui ne faisait pas partie du projet web précompilé, à savoir PrecompiledApp.config. Ce fichier informe le runtime ASP.NET que l’application a été précompilée et si elle a été précompilée avec une interface utilisateur pouvant être mise à jour ou non modifiable.
Enfin, prenez un moment pour ouvrir l’un des fichiers à l’emplacement .aspx cible à l’aide de Visual Studio ou de l’éditeur de texte de votre choix. Lors de la précompilation pour le déploiement avec une interface utilisateur pouvant être mise à jour, les pages ASP.NET dans le répertoire d’emplacement cible contiennent exactement le même balisage que les fichiers correspondants dans le site web.
Précompilation pour le déploiement avec une interface utilisateur non modifiable
L’outil de compilateur ASP.NET peut également être utilisé pour précompiler un site pour le déploiement avec une interface utilisateur non modifiable. La précompilation du site avec une interface utilisateur non updatable fonctionne un peu comme la précompilation avec une interface utilisateur pouvant être mise à jour, la principale différence étant que les pages ASP.NET, les contrôles utilisateur et les pages maîtres dans le répertoire cible sont supprimés de leur balisage. Pour précompiler un site web pour le déploiement avec une interface utilisateur non modifiable, choisissez l’option Publier le site web dans le menu Générer, mais décochez l’option « Autoriser ce site précompilé à être mis à jour » (voir figure 4).
Figure 4 : Décochez l’option « Autoriser ce site précompilé à être mis à jour » pour précompiler avec une interface utilisateur non updatable
(Cliquez pour afficher l’image en taille réelle)
La figure 5 montre le dossier d’emplacement cible après la précompilation avec une interface utilisateur non modifiable.
Figure 5 : Dossier d’emplacement cible pour le déploiement avec une interface utilisateur non modifiable
(Cliquez pour afficher l’image en taille réelle)
Comparez la figure 3 à la figure 5. Bien que les deux dossiers puissent sembler identiques, notez que le dossier d’interface utilisateur non modifiable ne dispose pas de la page maître, Site.master. Et bien que la figure 5 inclut les différentes pages ASP.NET, si vous affichez le contenu de ces fichiers, vous verrez qu’ils ont été supprimés de leur balisage déclaratif et remplacés par le texte de l’espace réservé : « Il s’agit d’un fichier de marqueur généré par l’outil de précompilation et ne doit pas être supprimé ! »
Figure 5 : Le balisage déclaratif a été supprimé des pages ASP.NET
Les Bin dossiers des figures 3 et 5 diffèrent plus considérablement. En plus des assemblys, le dossier de la Binfigure 5 inclut un .compiled fichier pour chaque page ASP.NET, contrôle utilisateur et page maître.
La précompilation d’un site avec une interface utilisateur non modifiable est utile dans les situations où vous ne souhaitez pas que le contenu des pages ASP.NET soit modifié par la personne ou l’entreprise qui installe ou gère le site web dans l’environnement de production. Si vous créez une application web ASP.NET que vous vendez aux clients pour les installer sur leurs propres serveurs web, vous pouvez vous assurer qu’ils ne modifient pas l’apparence de votre site en modifiant directement les .aspx pages que vous leur envoyez. En précompilant votre site web avec une interface utilisateur non modifiable, vous expédiez les pages d’espace réservé .aspx dans le cadre de l’installation, empêchant ainsi vos clients d’examiner ou de modifier leur contenu.
Précompilation à partir de la ligne de commande
En arrière-plan, la boîte de dialogue Publier le site web de Visual Studio appelle l’outil de compilation ASP.NET (aspnet_compiler.exe) pour précompiler le site web. Vous pouvez également appeler cet outil à partir de la ligne de commande. En fait, si vous utilisez Visual Web Developer, vous devez exécuter l’outil de compilateur à partir de la ligne de commande, car le menu Générer de Visual Web Developer n’inclut pas l’option Publier le site web.
Pour utiliser l’outil de compilateur à partir de la ligne de commande, commencez par accéder à la ligne de commande et accédez au répertoire du framework, %WINDIR%\Microsoft.NET\Framework\v2.0.50727. Ensuite, entrez l’instruction suivante dans la ligne de commande :
aspnet_compiler -p "physical_path_to_app" -v / -f -u "target_location_folder"
La commande ci-dessus lance l’outil de compilateur ASP.NET (aspnet_compiler.exe) et, via le -p commutateur, lui demande de précompiler le site web enraciné à physical_path_to_app ; cette valeur est semblable C:\MySites\BookReviewsà , et doit être délimitée par des guillemets.
Le -v commutateur spécifie le répertoire virtuel du site. Si votre site est inscrit en tant que site web par défaut dans la métabase IIS, vous pouvez omettre le -p commutateur et spécifier simplement le répertoire virtuel de l’application. Si vous utilisez le -p commutateur, la valeur qui passe au -v commutateur indique la racine du site web et est utilisée pour résoudre les références à la racine de l’application. Par exemple, si vous spécifiez une valeur de -v /MySite , les références dans l’application à ~/path/file seront résolues en tant que ~/MySite/path/file. Étant donné que le site Book Reviews se trouve dans le répertoire racine de ma société d’hébergement web, j’ai utilisé le commutateur -v /.
Le -f commutateur, le cas échéant, indique à l’outil de compilation de remplacer le répertoire target_location_folder s’il existe déjà. Si vous omettez le -f commutateur et que le dossier d’emplacement cible existe déjà, l’outil de compilation se ferme avec l’erreur : « erreur ASPRUNTIME : Le répertoire cible n’est pas vide. Supprimez-le manuellement ou choisissez une autre cible. »
Le -u commutateur, le cas échéant, indique à l’outil de créer une interface utilisateur pouvant être mise à jour. Omettez ce commutateur pour précompiler le site avec une interface utilisateur non modifiable.
Enfin, le target_location_folder est le chemin physique du répertoire d’emplacement cible ; cette valeur sera quelque chose comme C:\MySites\Output\BookReviews, et doit être délimitée par des guillemets.
Déploiement du site web précompilé
À ce stade, nous avons vu comment utiliser l’outil de compilation ASP.NET pour précompiler un site web à l’aide des options d’interface utilisateur pouvant être mises à jour et non modifiables. Toutefois, nos exemples jusqu’à présent ont précompilé le site web à un dossier local, et non à l’environnement de production. La bonne nouvelle est que le déploiement du site web précompilé est un jeu d’enfant et peut être effectué via Visual Studio ou via un autre mécanisme de copie de fichiers, par exemple à partir d’un client FTP autonome.
La boîte de dialogue Publier un site web (illustrée pour la première fois à la figure 1) comporte une option d’emplacement cible, qui indique l’emplacement vers lequel les fichiers de site web précompilés sont copiés. Cet emplacement peut être un serveur web distant ou un serveur FTP. L’entrée d’un serveur distant dans cette zone de texte précompile et déploie le site web sur le serveur spécifié en une seule étape. Vous pouvez également précompiler le site web dans un dossier local, puis copier manuellement le contenu de ce dossier dans l’environnement de production via FTP ou une autre approche.
Le déploiement automatique du site web précompilé via la boîte de dialogue Publier le site web de Visual Studio est utile pour les sites simples où il n’existe aucune différence de configuration entre les environnements de développement et de production. Toutefois, comme indiqué dans le tutoriel Différences de configuration courantes entre le développement et la production, il n’est pas rare que de telles différences existent. Par exemple, l’application web Book Reviews utilise une base de données différente dans l’environnement de production et dans l’environnement de développement. Lorsque Visual Studio publie le site web sur un serveur distant, il copie aveuglément les informations du fichier de configuration dans l’environnement de développement.
Pour les sites présentant des différences de configuration entre les environnements de développement et de production, il peut être préférable de précompiler le site dans un répertoire local, de copier les fichiers de configuration spécifiques à la production, puis de copier le contenu de la sortie précompilée en production.
Pour une actualisation de la copie de fichiers de l’environnement de développement vers l’environnement de production, consultez les didacticiels Déploiement de votre site web à l’aide d’un client FTP et Déploiement de votre site web à l’aide de Visual Studio .
Résumé
ASP.NET prend en charge deux modes de compilation : automatique et explicite. Comme indiqué dans les tutoriels précédents, les projets d’application web (WAP) utilisent la compilation explicite, tandis que les projets de site web (WSP) utilisent la compilation automatique, par défaut. Toutefois, il est possible de compiler explicitement un WSP avant le déploiement à l’aide de l’outil de compilation ASP.NET.
Ce tutoriel s’est concentré sur la précompilation de l’outil de compilation pour la prise en charge du déploiement. Lors de la précompilation pour le déploiement, l’outil de compilation crée un dossier d’emplacement cible, compile le code source de l’application web spécifiée et copie ces assemblys compilés et les fichiers de contenu dans le dossier d’emplacement cible. L’outil de compilation peut être configuré pour créer une interface utilisateur pouvant être mise à jour ou non mise à jour. Lors de la précompilation avec une option d’interface utilisateur non modifiable, le balisage déclaratif dans les fichiers de contenu est supprimé. En résumé, la précompilation vous permet de déployer votre application basée sur un projet de site web sans inclure de fichiers de code source et avec le balisage déclaratif supprimé, si vous le souhaitez.
Bonne programmation!
En savoir plus
Pour plus d’informations sur les sujets abordés dans ce tutoriel, reportez-vous aux ressources suivantes :