Précompilation de votre site web (VB)
par Scott Mitchell
Visual Studio offre aux développeurs ASP.NET deux types de projets : projets d’application web (WAP) et projets de site web (WSPs). 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 d’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 WAPs 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 de copier le contenu du 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. D’autre part, vous déployez les WSP en copiant à la fois les pages de balisage et leurs classes de 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, et la façon dont le modèle de compilation affecte le déploiement.
L’option de compilation automatique est simple à utiliser. Il n’existe aucune é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 un disjoncteur, 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 du code qui se produit 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 fichier et une partie de .aspx code source, généralement dans un fichier de classe code-behind distinct (.aspx.vb). 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 assembly unique 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 sur le 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, en fin de compte, 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 à la fois le contenu déclaratif et le contenu 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 <pages> dans Web.config. Étant donné que l’assembly est enregistré sur le disque, il n’a pas besoin d’être recompilé sur les requêtes suivantes à la même page.
Notes
Comme vous pouvez vous y attendre, il y a un léger délai 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 faible 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. Par conséquent, 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 WSPs, mais en bref, 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 emplacements : dans le .aspx.vb 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, les parties déclaratives et de code source doivent être compilées dans un assembly. Avec les WAP, 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 utilisant 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 un 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 réduit le runtime de la nécessité d’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, case activée Guide pratique pour précompiler les sites web ASP.NET et la 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 types 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 les .ascx fichiers, .master ce qui masque le balisage déclaratif et empêche un 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 Générer 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 de 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 un site web. Cette opération lance la boîte de dialogue Publier le site web (voir figure 1), dans laquelle vous pouvez spécifier l’emplacement cible, si l’interface utilisateur du site précompilé est ou non modifiable et d’autres options d’outil de 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. Comme 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 ne contient qu’un seul fichier, Elmah.dll, que nous avons ajouté dans le tutoriel précédent
Figure 2 : le répertoire du projet contient .aspx les fichiers et .aspx.cs ; le Bin dossier inclut uniquement 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 d’emplacement cible inclut les fichiers pour le déploiement
(Cliquez pour afficher l’image en taille réelle)
Contrairement à la compilation explicite dans les waps, la précompilation pour le processus de 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, contrôles utilisateur et pages master (.aspx, .ascxet .master fichiers, respectivement) sont copiés tels quels dans le répertoire de l’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, reportez-vous à 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 master page en cochant la case « Utilisation de noms fixes et d’assemblys de page unique » dans la boîte de dialogue Publier le site web. Le fait que chaque page ASP.NET soit compilée dans son propre assembly permet un contrôle plus précis du déploiement. Par exemple, si vous avez mis à jour une seule page web ASP.NET et que vous avez besoin de déployer cette modification, vous devez déployer uniquement le fichier de .aspx cette page et l’assembly associé dans 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 l’ASP.NET runtime 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 pouvant être mise à jour à midi.
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 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 modifiable fonctionne de manière similaire à 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 master 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 modifiable
(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 master, 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 d’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. Outre les assemblys, le dossier de la Binfigure 5 inclut un .compiled fichier pour chaque page ASP.NET, contrôle utilisateur et page master.
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 l’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 envoyez 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 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 compilateur à partir de la ligne de commande, commencez par déposer vers 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 compilateur ASP.NET (aspnet_compiler.exe) et, via le -p commutateur, lui indique de précompiler le site web rooté à physical_path_to_app ; cette valeur sera 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 suivant le -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 instance, 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, s’il est présent, 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, s’il est présent, 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 est semblable 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 dans un dossier local, et non dans 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 (d’abord illustrée dans 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 didacticiel Différences de configuration communes 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 que 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 plus d’informations sur 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 du précompilage 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 didacticiel, consultez les ressources suivantes :