Il existe de nombreuses variétés de modules ASP.NET basés sur diverses plates-formes telles que les formulaires Web, les pages Web, Model-View-Controller (MVC) et le plus récent - Core. Dans cet article, je souhaite examiner un certain nombre de différences entre la compilation d'un site Web ASP.NET et une application Web ASP.NET.
Compilation d'un site Web (Fig. 1) et d'une application Web (Fig. 2).
Fig. 1: Site Web ASP.NET et distinction entre le site Web ASP.NET et l'application Web ASP.NET
Fig. 2: Application Web ASP.NET et distinction entre le site Web ASP.NET et l'application Web ASP.NETCet article ne concerne pas la structure interne des projets ASP.NET, mais l'expérience que j'ai acquise en travaillant sur la plateforme Azure App Service. Le périphérique interne est déjà documenté
ici - «Précompilation de votre site Web (C #)» («Précompilation d'un site Web en C #»). Vous devez comprendre la différence entre la compilation automatique et explicite. En outre, si vous traitez avec un site Web ASP.NET, pensez sérieusement à précompiler avec aspnet_compiler.exe, comme décrit dans Comment: précompiler des sites Web ASP.NET (comment précompiler des sites Web ASP.NET ").
Voici un certain nombre de publications qui vous aideront à élargir vos horizons sur cette question et à explorer d'autres sujets:
Alors, où tout a-t-il commencé? Je voulais vérifier si j'avais bien compris le processus de compilation des modules ASP.NET en assemblys, et j'ai décidé de le faire dans l'environnement Azure App Service. J'avais déjà un concept sur les fichiers ASP.NET temporaires, sur la compilation de fichiers ASPX dans un assembly .dll et sur l'endroit où ils étaient stockés sur un serveur autonome. J'étais sûr que sur la plate-forme App Service, les deux premiers points étaient mis en œuvre de manière similaire, mais je doutais du troisième - à savoir, où les assemblys compilés sont stockés. J'ai donc écrit un code pour le découvrir.
public partial class _default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { LabelFileLocation.Text = $"{System.Web.HttpRuntime.CodegenDir}"; rptResults1.DataSource = System.IO.Directory.GetFiles(System.Web.HttpRuntime.CodegenDir, "*.dll"); rptResults1.DataBind(); } } () <asp:Repeater ID="rptResults1" runat="server"> <HeaderTemplate><table></HeaderTemplate> <ItemTemplate> <tr> <td><%# Container.DataItem %></td> </tr> </ItemTemplate> <FooterTemplate></table></FooterTemplate> </asp:Repeater>
J'ai ensuite publié ce code sur la plateforme App Service.
Lorsque j'ai accédé pour la première fois au site Web, j'ai obtenu le résultat indiqué sur la Fig. 3 (à l'origine à la racine de mon site Web ASP.NET était trois pages)
Fig. 3: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceJ'ai redémarré le site Web et les binaires compilés dans un nouvel assemblage (figure 4). C'était tout à fait inattendu, car j'ai seulement redémarré et n'ai effectué aucun déploiement ou changement.
Fig. 4: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceJ'ai cherché dans KUDU le répertoire d'assemblage et je ne l'ai pas trouvé; c'était très étrange.
Après avoir cliqué sur les liens "Une autre page" et "Et une autre page", toutes mes pages ont été compilées en un seul assembly, et j'ai été très surpris de le trouver car debug = true a été défini dans mon fichier web.config.
J'avais besoin de trouver les réponses aux questions suivantes:
- Pourquoi mon application s'est-elle recompilée après le redémarrage, alors que je n'ai effectué aucun changement de déploiement ou de configuration?
- Pourquoi n'ai-je pas trouvé l'assembly dans KUDU alors que mon code source était correct?
- Pourquoi mon application a-t-elle été compilée en un seul assembly, bien que debug = true ait été défini dans le fichier web.config?
La réponse à la première question était que je regardais en fait l'assemblage KUDU, pas celui qui a été compilé pour l'App Service. Jetez un œil à la figure 2 de l'
article «Créer un vidage de mémoire pour votre application Web à faible performance». Cela montre que KUDU s'exécute dans un processus différent de celui d'App Service. Par conséquent, KUDU s'est recompilé lors de la création de l'instance, et ce n'était pas mon instance de l'App Service.
J'ai également trié la deuxième question en fonction des informations reçues sur la première question. Je vais omettre les détails sur la configuration des fichiers sur la plate-forme App Service et dire que j'ai pu afficher mes assemblages de site Web ASP.NET sur cette plate-forme: pour cela, j'ai défini WEBSITE_DISABLE_SCM_SEPARATION sur true (voir figure 5). Faites cela uniquement pour les tests et (ou) le débogage et rien de plus. Je ne recommande pas de mapper plusieurs pages d'un site Web à un seul processus dans App Service. Une fois le débogage terminé, réinitialisez cette valeur et séparez à nouveau les processus.
Fig. 5: compilation du site Web ASP.NET dans Azure App Service; Je ne trouve pas de fichiers ASP.NET temporaires sur KUDULa réponse à la troisième question était que si le fichier Web.Debug.config est présent, l'attribut debug = true est supprimé pendant le processus de déploiement.
<compilation xdt:Transform="RemoveAttributes(debug)" />
J'ai écrit sur les fichiers XDT
ici ,
ici et
ici , mais dans ce cas, j'ai dû réfléchir un peu pour comprendre (me souvenir, réaliser) leur signification.
Après avoir défini WEBSITE_DISABLE_SCM_SEPARATION sur true, j'ai fait un arrêt et un démarrage, en d'autres termes, un démarrage à froid ... et j'ai vu que SCM / KUDU et mon site Web ont réellement démarré dans le même processus (Fig. 6.)
Fig. 6: compilation du site Web ASP.NET dans Azure App Service; Je ne trouve pas de fichiers ASP.NET temporaires sur KUDULa publication et la compilation de default.aspx est lancée, le nom de l'assembly reste inchangé après toutes les requêtes (Fig. 7).
Fig. 7: compilation d'un site Web ASP.NET sur la plateforme Azure App ServicePour vérifier cela, j'ai pris un vidage de la mémoire de processus, pris un vidage du module et l'ai analysé. Honnêtement, j'étais toujours perplexe par le résultat affiché par l'assembly, car je n'ai compris le paramètre debug = true qu'une fois tous les tests terminés. Parfois, j'écris des articles dans le mauvais ordre dans lequel les événements suivent. Confus, j'ai décidé de tester la compilation par lots; lisez-le
ici : "Élément de compilation (schéma des paramètres ASP.NET)" ("Élément de compilation - Schéma des paramètres Web ASP.NET"). Je m'attendais à ce qu'un seul assemblage par page soit compilé, donc le résultat (voir figure 8) a été une surprise totale.
Fig. 8: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceJe m'attendais à voir un assembly par page, car je pensais que je travaillais avec le paramètre debug = true. En lisant la compilation par lots, j'ai réalisé qu'elle compile toutes les pages dans l'assemblage contenu dans un répertoire spécifique. J'ai donc créé deux répertoires et mis les fichiers .aspx dans chacun d'eux. Le PID n'a pas changé, il n'y a donc pas eu de «démarrage à froid» (Fig. 9).
Fig. 9: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceCependant, le site a vraiment été recompilé dans un autre fichier binaire, mais est resté dans le même répertoire (chemin) (Fig. 10).
Fig. 10: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceJ'ai vidé la mémoire pour vérifier entièrement l'exactitude de mes conclusions. Et, dès que je me suis tourné vers la racine du site et que j'ai vu que toutes les pages du répertoire étaient compilées, j'ai réalisé que mon hypothèse sur la compilation par lots était confirmée (Fig. 11).
Fig. 11: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceJ'ai suivi le lien «Répertoire 1» et j'ai vu un autre assemblage (Fig. 12).
Fig. 12: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceJ'ai à nouveau vidé la mémoire, retiré le vidage du module et vu qu'elle correspond vraiment à la page «Répertoire 1» (Fig. 13).
Fig. 13: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceJ'ai fait de même pour la page Annuaire 2 (Fig. 14 et 15).
Fig. 14: compilation d'un site Web ASP.NET sur la plateforme Azure App Service
Fig. 15: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceJ'ai également eu l'occasion d'aller aux assemblées elles-mêmes dans SCM / KUDU (Fig. 16).
Fig. 16: compilation d'un site Web ASP.NET sur la plateforme Azure App ServiceDès que j'ai découvert le problème avec le paramètre debug = true, tout s'est mis en place et ce fut une bonne expérience d'apprentissage. J'espère que vous trouverez mon article utile.
Ressources utiles
Guide d'architecture d'application cloud
Adoptez une approche structurée pour développer des applications cloud. Cet e-book de 300 pages sur l'architecture de cloud computing décrit l'architecture, le développement et les directives de mise en œuvre qui s'appliquent quelle que soit la plateforme cloud que vous choisissez. Ce guide comprend des étapes pour:
- Choisir le bon style d'architecture d'application cloud pour votre application ou solution;
- sélection de technologies informatiques et de stockage de données appropriées;
- mettre en œuvre 10 principes de développement pour créer une application évolutive, résiliente et gérable;
- suivre les cinq principes de création d'un logiciel de qualité garantissant le succès de votre application cloud;
- Utiliser des modèles de conception conçus pour le problème que vous essayez de résoudre.
→
TéléchargerGuide du développeur Azure
Dans cette mise à jour du Guide du développeur Azure, vous verrez comment l'ensemble complet de services pour la plate-forme logicielle Azure répond à vos besoins. Vous trouverez ici des informations sur les approches architecturales et les situations les plus courantes qui se produisent lors de la création d'applications cloud.
→
TéléchargerBases de Microsoft Azure
Ce livre fournit des informations importantes sur les services Azure clés pour les développeurs et les professionnels de l'informatique qui découvrent le cloud computing. Des démos étape par étape sont incluses pour aider le lecteur à comprendre comment démarrer avec chacun des services clés. Chaque chapitre est indépendant, il n'est pas nécessaire d'effectuer des démonstrations pratiques des chapitres précédents pour comprendre un chapitre en particulier.
Les sujets suivants sont traités dans ce livre:
- Premiers pas avec Azure;
- Azure Application Service et applications Web;
- Machines virtuelles;
- Service de stockage;
- Bases de données
- Services Azure supplémentaires.
→
TéléchargerLiens utiles