Configuration et instrumentation
par Microsoft
Notes
Depuis la rédaction de cet article, les fournisseurs d’appartenance ASP.NET ont été remplacés par ASP.NET Identity. Nous vous recommandons vivement de mettre à jour les applications pour utiliser la plateforme d’identité ASP.NET plutôt que les fournisseurs d’appartenances proposés au moment de la rédaction de cet article. ASP.NET Identity présente un certain nombre d’avantages par rapport au système d’appartenance ASP.NET, notamment :
- Meilleures performances
- Extensibilité et testabilité améliorées
- Prise en charge d’OAuth, OpenID Connect et de l’authentification à deux facteurs
- Prise en charge des identités basées sur les revendications
- Meilleure interopérabilité avec ASP.Net Core
Des changements majeurs ont été apportés à la configuration et à l’instrumentation dans ASP.NET 2.0. La nouvelle API de configuration ASP.NET permet d’effectuer des modifications de configuration par programmation. En outre, de nombreux nouveaux paramètres de configuration permettent de nouvelles configurations et de nouvelles instrumentations.
Des changements majeurs ont été apportés à la configuration et à l’instrumentation dans ASP.NET 2.0. La nouvelle API de configuration ASP.NET permet d’effectuer des modifications de configuration par programmation. En outre, de nombreux nouveaux paramètres de configuration permettent de nouvelles configurations et de nouvelles instrumentations.
Dans ce module, nous allons aborder ASP.NET l’API de configuration en ce qui concerne la lecture et l’écriture dans ASP.NET fichiers de configuration, et nous aborderons également ASP.NET instrumentation. Nous aborderons également les nouvelles fonctionnalités disponibles dans ASP.NET traçage.
ASP.NET Configuration API
L’API de configuration ASP.NET vous permet de développer, déployer et gérer des données de configuration d’application à l’aide d’une seule interface de programmation. Vous pouvez utiliser l’API de configuration pour développer et modifier des configurations ASP.NET complètes par programmation sans modifier directement le code XML dans les fichiers de configuration. En outre, vous pouvez utiliser l’API de configuration dans les applications console et les scripts que vous développez, dans les outils de gestion web et dans les composants logiciels enfichables MMC (Microsoft Management Console).
Les deux outils de gestion de configuration suivants utilisent l’API de configuration et sont inclus avec .NET Framework version 2.0 :
- Le ASP.NET composant logiciel enfichable MMC, qui utilise l’API de configuration pour simplifier les tâches d’administration, en fournissant une vue intégrée des données de configuration locales de tous les niveaux de la hiérarchie de configuration.
- L’outil d’administration de site web, qui vous permet de gérer les paramètres de configuration pour les applications locales et distantes, y compris les sites hébergés.
L’API de configuration ASP.NET comprend un ensemble d’objets de gestion ASP.NET que vous pouvez utiliser pour configurer des sites web et des applications par programmation. Les objets de gestion sont implémentés en tant que bibliothèque de classes .NET Framework. Le modèle de programmation d’API de configuration permet de garantir la cohérence et la fiabilité du code en appliquant des types de données au moment de la compilation. Pour faciliter la gestion des configurations d’application, l’API de configuration vous permet d’afficher les données fusionnées à partir de tous les points de la hiérarchie de configuration sous la forme d’une collection unique, au lieu d’afficher les données sous la forme de regroupements distincts à partir de différents fichiers de configuration. En outre, l’API de configuration vous permet de manipuler des configurations d’application entières sans modifier directement le code XML dans les fichiers de configuration. Enfin, l’API simplifie les tâches de configuration en prenant en charge les outils d’administration, tels que l’outil d’administration de site web. L’API de configuration simplifie le déploiement en prenant en charge la création de fichiers de configuration sur un ordinateur et l’exécution de scripts de configuration sur plusieurs ordinateurs.
Notes
L’API de configuration ne prend pas en charge la création d’applications IIS.
Utilisation des paramètres de configuration locale et distante
Un objet Configuration représente la vue fusionnée des paramètres de configuration qui s’appliquent à une entité physique spécifique, telle qu’un ordinateur, ou à une entité logique, telle qu’une application ou un site Web. L’entité logique spécifiée peut exister sur l’ordinateur local ou sur un serveur distant. Lorsqu’aucun fichier de configuration n’existe pour une entité spécifiée, l’objet Configuration représente les paramètres de configuration par défaut définis par le fichier Machine.config.
Vous pouvez obtenir un objet Configuration à l’aide de l’une des méthodes de configuration ouvertes des classes suivantes :
- Classe ConfigurationManager, si votre entité est une application cliente.
- Classe WebConfigurationManager, si votre entité est une application web.
Ces méthodes retournent un objet Configuration, qui fournit à son tour les méthodes et propriétés requises pour gérer les fichiers de configuration sous-jacents. Vous pouvez accéder à ces fichiers pour la lecture ou l’écriture.
Lecture
Vous utilisez la méthode GetSection ou GetSectionGroup pour lire les informations de configuration. L’utilisateur ou le processus qui lit doit avoir des autorisations de lecture sur tous les fichiers de configuration de la hiérarchie.
Notes
Si vous utilisez une méthode GetSection statique qui accepte un paramètre path, le paramètre path doit faire référence à l’application dans laquelle le code est en cours d’exécution. Sinon, le paramètre est ignoré et les informations de configuration de l’application en cours d’exécution sont retournées.
Écriture
Vous utilisez l’une des méthodes Save pour écrire des informations de configuration. L’utilisateur ou le processus qui écrit doit avoir des autorisations d’écriture sur le fichier de configuration et le répertoire au niveau de la hiérarchie de configuration actuelle, ainsi que des autorisations de lecture sur tous les fichiers de configuration de la hiérarchie.
Pour générer un fichier de configuration qui représente les paramètres de configuration hérités d’une entité spécifiée, utilisez l’une des méthodes de configuration d’enregistrement suivantes :
- Méthode Save pour créer un fichier de configuration.
- Méthode SaveAs pour générer un nouveau fichier de configuration à un autre emplacement.
Classes de configuration et espaces de noms
De nombreuses classes et méthodes de configuration sont similaires. Le tableau suivant décrit les classes de configuration et les espaces de noms les plus couramment utilisés.
Classe de configuration ou espace de noms | Description |
---|---|
Espace de noms System.Configuration | Contient les classes de configuration main pour toutes les applications .NET Framework. Les classes de gestionnaire de section sont utilisées pour obtenir les données de configuration d’une section à partir de méthodes telles que GetSection et GetSectionGroup. Ces deux méthodes ne sont pas statiques. |
Classe System.Configuration.Configuration | Représente un ensemble de données de configuration pour un ordinateur, une application, un répertoire Web ou une autre ressource. Cette classe contient des méthodes utiles, telles que GetSection et GetSectionGroup, pour mettre à jour les paramètres de configuration et obtenir des références aux sections et aux groupes de sections. Cette classe est utilisée comme type de retour pour les méthodes qui obtiennent des données de configuration au moment du design, telles que les méthodes des classes WebConfigurationManager et ConfigurationManager. |
Espace de noms System.Web.Configuration | Contient les classes de gestionnaire de section pour les sections de configuration ASP.NET définies dans ASP.NET Paramètres de configuration. Les classes de gestionnaire de section sont utilisées pour obtenir les données de configuration d’une section à partir de méthodes telles que GetSection et GetSectionGroup. |
Classe System.Web.Configuration.WebConfigurationManager | Fournit des méthodes utiles pour obtenir des références aux paramètres de configuration au moment de l’exécution et au moment du design. Ces méthodes utilisent la classe System.Configuration.Configuration comme type de retour. Vous pouvez utiliser indifféremment la méthode GetSection statique de cette classe ou la méthode GetSection non statique de la classe System.Configuration.ConfigurationManager. Pour les configurations d’application web, la classe System.Web.Configuration.WebConfigurationManager est recommandée à la place de la classe System.Configuration.ConfigurationManager. |
Espace de noms System.Configuration.Provider | Fournit un moyen de personnaliser et d’étendre le fournisseur de configuration. Il s’agit de la classe de base pour toutes les classes de fournisseur dans le système de configuration. |
Espace de noms System.Web.Management | Contient des classes et des interfaces pour la gestion et la supervision de l’intégrité des applications web. À proprement parler, cet espace de noms n’est pas considéré comme faisant partie de l’API de configuration. Par exemple, le suivi et le déclenchement d’événements sont effectués par les classes de cet espace de noms. |
Espace de noms System.Management.Instrumentation | Fournit les classes nécessaires à l’instrumentation des applications afin d’exposer leurs informations et événements de gestion via Windows Management Instrumentation (WMI) aux consommateurs potentiels. ASP.NET surveillance de l’intégrité utilise WMI pour fournir des événements. À proprement parler, cet espace de noms n’est pas considéré comme faisant partie de l’API de configuration. |
Lecture à partir de fichiers de configuration ASP.NET
La classe WebConfigurationManager est la classe principale pour la lecture à partir de ASP.NET fichiers de configuration. Il existe essentiellement trois étapes pour lire ASP.NET fichiers de configuration :
- Obtenez un objet Configuration à l’aide de la méthode OpenWebConfiguration.
- Obtenez une référence à la section souhaitée dans le fichier de configuration.
- Lisez les informations souhaitées à partir du fichier de configuration.
L’objet Configuration représente ne représente pas un fichier de configuration particulier. Au lieu de cela, il représente une vue fusionnée de la configuration d’un ordinateur, d’une application ou d’un site Web. L’exemple de code suivant instancie un objet Configuration représentant la configuration d’une application web appelée ProductInfo.
Configuration config = WebConfigurationManager.OpenWebConfiguration("/ProductInfo);
Notes
Notez que si le chemin /ProductInfo n’existe pas, le code ci-dessus retourne la configuration par défaut spécifiée dans le fichier machine.config.
Une fois que vous avez l’objet Configuration, vous pouvez utiliser la méthode GetSection ou GetSectionGroup pour explorer les paramètres de configuration. L’exemple suivant obtient une référence aux paramètres d’emprunt d’identité pour l’application ProductInfo ci-dessus :
Configuration config =
WebConfigurationManager.OpenWebConfiguration("/ProductInfo);
IdentitySection section =
(IdentitySection)config.GetSection("system.web/identity");
Écriture dans ASP.NET fichiers de configuration
Comme dans la lecture à partir de fichiers de configuration, la classe WebConfigurationManager est le cœur de l’écriture dans Asp.NET fichiers de configuration. Il existe également trois étapes pour écrire dans ASP.NET fichiers de configuration.
- Obtenez un objet Configuration à l’aide de la méthode OpenWebConfiguration.
- Obtenez une référence à la section souhaitée dans le fichier de configuration.
- Écrivez les informations souhaitées à partir du fichier de configuration à l’aide de la méthode Save ou SaveAs.
Le code suivant modifie l’attribut de débogage de l’élément <de compilation> sur false :
System.Configuration.Configuration updateWebConfig =
System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("/webApp");
System.Web.Configuration.CompilationSection compilation =
updateWebConfig.GetSection("system.web/compilation")
as System.Web.Configuration.CompilationSection;
compilation.Debug = false;
if (!compilation.SectionInformation.IsLocked) {
updateWebConfig.Save();
Response.Write("Save Success!");
} else {
Response.Write("Save Failed!");
}
Lorsque ce code est exécuté, l’attribut de débogage de l’élément <de compilation> est défini sur false pour le fichier web.config de l’application webApp .
Espace de noms System.Web.Management
L’espace de noms System.Web.Management fournit les classes et les interfaces pour la gestion et la surveillance de l’intégrité des applications ASP.NET.
La journalisation s’effectue en définissant une règle qui associe des événements à un fournisseur. La règle définit le type d’événements qui sont envoyés au fournisseur. Les événements de base suivants sont disponibles pour journaliser :
WebBaseEvent | Classe d’événements de base pour tous les événements. Contient les propriétés requises pour tous les événements, telles que le code d’événement, le code de détail de l’événement, la date et l’heure de levée de l’événement, le numéro de séquence, le message d’événement et les détails de l’événement. |
---|---|
WebManagementEvent | Classe d’événements de base pour les événements de gestion, tels que les événements de durée de vie de l’application, de requête, d’erreur et d’audit. |
WebHeartbeatEvent | Événement généré par l’application à intervalles réguliers pour capturer des informations d’état d’exécution utiles. |
WebAuditEvent | Classe de base pour les événements d’audit de sécurité, qui sont utilisés pour marquer des conditions telles que l’échec d’autorisation, l’échec de déchiffrement, etc. |
WebRequestEvent | Classe de base pour tous les événements de demande d’informations. |
WebBaseErrorEvent | Classe de base pour tous les événements indiquant des conditions d’erreur. |
Les types de fournisseurs disponibles vous permettent d’envoyer une sortie d’événement à observateur d'événements, SQL Server, Windows Management Instrumentation (WMI) et à la messagerie électronique. Les fournisseurs préconfigurés et les mappages d’événements réduisent la quantité de travail nécessaire pour obtenir la sortie d’événement journalisée.
ASP.NET 2.0 utilise le fournisseur du journal des événements prête à l’emploi pour journaliser les événements en fonction du démarrage et de l’arrêt des domaines d’application, ainsi que de la journalisation des exceptions non gérées. Cela permet de couvrir certains des scénarios de base. Par exemple, supposons que votre application lève une exception, mais que l’utilisateur n’enregistre pas l’erreur et que vous ne pouvez pas la reproduire. Avec la règle de journal des événements par défaut, vous pouvez collecter les informations d’exception et de pile pour avoir une meilleure idée du type d’erreur qui s’est produit. Un autre exemple s’applique si votre application perd l’état de session. Dans ce cas, vous pouvez rechercher dans le journal des événements si le domaine d’application est en cours de recyclage et pourquoi le domaine d’application s’est arrêté en premier lieu.
En outre, le système de surveillance de l’intégrité est extensible. Par exemple, vous pouvez définir des événements web personnalisés, les déclencher dans votre application, puis définir une règle pour envoyer les informations d’événement à un fournisseur tel que votre courrier électronique. Cela vous permet de lier facilement votre instrumentation aux fournisseurs de surveillance de l’intégrité. Par exemple, vous pouvez déclencher un événement chaque fois qu’une commande est traitée et configurer une règle qui envoie chaque événement à la base de données SQL Server. Vous pouvez également déclencher un événement lorsqu’un utilisateur ne parvient pas à se connecter plusieurs fois de suite et configurer l’événement pour utiliser les fournisseurs basés sur la messagerie.
La configuration des fournisseurs et des événements par défaut est stockée dans le fichier Web.config global. Le fichier Web.config global stocke tous les paramètres web qui ont été stockés dans le fichier Machine.config dans ASP.NET 1x. Le fichier Web.config global se trouve dans le répertoire suivant :
%windir%\Microsoft.Net\Framework\v2.0.*\config\Web.config
La <section healthMonitoring> du fichier Web.config global fournit les paramètres de configuration par défaut. Vous pouvez remplacer ces paramètres ou configurer vos propres paramètres en implémentant la <section healthMonitoring> dans le fichier Web.config de votre application.
La <section healthMonitoring> du fichier Web.config global contient les éléments suivants :
fournisseurs | Contient les fournisseurs configurés pour les observateur d'événements, WMI et SQL Server. |
---|---|
eventMappings | Contient des mappages pour les différentes classes WebBase. Vous pouvez étendre cette liste si vous générez votre propre classe d’événements. La génération de votre propre classe d’événements vous donne une granularité plus fine par rapport aux fournisseurs à qui vous envoyez des informations. Par exemple, vous pouvez configurer des exceptions non gérées pour qu’elles soient envoyées à SQL Server, tout en envoyant vos propres événements personnalisés à un e-mail. |
rules | Lie les eventMappings au fournisseur. |
Tampon | Utilisé avec les fournisseurs de SQL Server et de messagerie pour déterminer la fréquence à laquelle vider les événements sur le fournisseur. |
Vous trouverez ci-dessous un exemple de code du fichier Web.config global.
<healthMonitoring>
<!-- Event Log Provider being added. -->
<providers>
<add name="EventLogProvider"
type="System.Web.Management.EventLogWebEventProvider,
System.Web,Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
<!-- Event mapping provides a friendly name to the
events based on the WebBaseErrorEvent class. -->
<eventMappings>
<add name="All Errors"
type="System.Web.Management.WebBaseErrorEvent,
System.Web,Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
startEventCode="0" endEventCode="2147483647" />
</eventMappings>
<!-- Rule tying the "All Errors" event mapping to the EventLog Provider. -->
<rules>
<add name="All Errors Default" eventName="All Errors"
provider="EventLogProvider"
profile="Default" minInstances="1"
maxLimit="Infinite" minInterval="00:01:00" custom="" />
</rules>
</healthMonitoring>
Comment stocker des événements dans observateur d'événements
Comme mentionné précédemment, le fournisseur de journalisation des événements dans le observateur d'événements est configuré pour vous dans le fichier Web.config global. Par défaut, tous les événements basés sur WebBaseErrorEvent et WebFailureAuditEvent sont consignés. Vous pouvez ajouter des règles supplémentaires pour enregistrer des informations supplémentaires dans le journal des événements. Par exemple, si vous souhaitez journaliser tous les événements (par exemple, chaque événement basé sur WebBaseEvent), vous pouvez ajouter la règle suivante à votre fichier Web.config :
<healthMonitoring>
<rules>
<add name="All Events" eventName="All Events"
provider="EventLogProvider" profile="Critical" />
</rules>
</healthMonitoring>
Cette règle lierait le mappage d’événements Tous les événements au fournisseur du journal des événements. EventMapping et le fournisseur sont inclus dans le fichier Web.config global.
Comment stocker des événements dans SQL Server
Cette méthode utilise la base de données ASPNETDB , qui est générée par l’outil Aspnet_regsql.exe. Le fournisseur par défaut utilise la chaîne de connexion LocalSqlServer, qui utilise une base de données basée sur des fichiers dans le dossier App_data ou le instance SQLExpress local de SQL Server. La chaîne de connexion LocalSqlServer et SqlProvider sont configurées dans le fichier Web.config global.
La chaîne de connexion LocalSqlServer dans le fichier Web.config global ressemble à ceci :
<connectionStrings>
<add name="LocalSqlServer"
connectionString="data source=.\SQLEXPRESS;
Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;
User Instance=true"
providerName="System.Data.SqlClient" />
</connectionStrings>
Si vous souhaitez utiliser un autre SQL Server instance, vous devez utiliser l’outil Aspnet_regsql.exe, qui se trouve dans le dossier %windir%\Microsoft.Net\Framework\v2.0.*. Utilisez l’outil Aspnet_regsql.exe pour générer une base de données ASPNETDB personnalisée sur le SQL Server instance, puis ajoutez la chaîne de connexion au fichier de configuration de vos applications, puis ajoutez un fournisseur à l’aide de la nouvelle chaîne de connexion. Une fois la base de données ASPNETDB créée, vous devez définir une règle pour lier un eventMapping au sqlProvider.
Que vous utilisiez sqlProvider par défaut ou que vous configuriez votre propre fournisseur, vous devez ajouter une règle liant le fournisseur à un mappage d’événements. La règle suivante lie le nouveau fournisseur que vous avez créé ci-dessus à la carte d’événements Tous les événements . Cette règle consigne tous les événements basés sur WebBaseEvent et les envoie au MySqlWebEventProvider qui utilisera la chaîne de connexion MYASPNETDB. Le code suivant ajoute une règle pour lier le fournisseur à une carte d’événements :
<healthMonitoring>
<rules>
<add name="All Events" eventName="All Events"
provider="MySqlWebEventProvider" profile="Critical"/>
</rules>
</healthMonitoring>
Si vous souhaitez uniquement envoyer des erreurs à SQL Server, vous pouvez ajouter la règle suivante :
<add name="All Errors"
eventName="All Errors"
provider="MySqlWebEventProvider"
profile="Critical"/>
Comment transférer des événements vers WMI
Vous pouvez également transférer les événements à WMI. Le fournisseur WMI est configuré pour vous dans le fichier Web.config global par défaut.
L’exemple de code suivant ajoute une règle pour transférer les événements à WMI :
<providers>
<add name="WmiWebEventProvider"
type="System.Web.Management.WmiWebEventProvider,System.Web,
Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
Vous devez ajouter une règle pour associer un eventMapping au fournisseur, ainsi qu’une application d’écouteur WMI pour écouter les événements. L’exemple de code suivant ajoute une règle pour lier le fournisseur WMI à la carte d’événements Tous les événements :
<rules>
<add name="All Events"
eventName="All Events" provider="WmiWebEventProvider"
profile="Critical" />
</rules>
Comment transférer des événements vers un e-mail
Vous pouvez également transférer des événements à un e-mail. Soyez prudent quant aux règles d’événements que vous mappez à votre fournisseur de messagerie, car vous pouvez involontairement vous envoyer un grand nombre d’informations qui peuvent être mieux adaptées à SQL Server ou au journal des événements. Il existe deux fournisseurs de messagerie ; SimpleMailWebEventProvider et TemplatedMailWebEventProvider. Chacun a les mêmes attributs de configuration, à l’exception des attributs « template » et « detailedTemplateErrors », tous deux disponibles uniquement sur templatedMailWebEventProvider.
Notes
Aucun de ces fournisseurs de messagerie n’est configuré pour vous. Vous devez les ajouter à votre fichier Web.config.
La main différence entre ces deux fournisseurs de messagerie est que SimpleMailWebEventProvider envoie des e-mails dans un modèle générique qui ne peut pas être modifié. L’exemple de fichier Web.config ajoute ce fournisseur de messagerie à la liste des fournisseurs configurés à l’aide de la règle suivante :
<add name="mySimple-mailWebEventProvider"
type="System.Web.Management.Simple-mailWebEventProvider"
to="e-mail@foo.com" from="e-mail@foo.com"
maxMessagesPerNotification="1" maxEventsPerMessage="10"
buffer="true" bufferMode="Critical Notification"
subjectPrefix="Web Events"/>
La règle suivante est également ajoutée pour lier le fournisseur de messagerie à la carte d’événements Tous les événements :
<add name="All Events" eventName="All Events"
provider="mySimple-mailWebEventProvider" profile="Critical"/>
Suivi ASP.NET 2.0
Trois améliorations majeures sont apportées au traçage dans ASP.NET 2.0.
- Fonctionnalité de suivi intégrée
- Accès par programme aux messages de suivi
- Suivi au niveau de l’application amélioré
Fonctionnalité de suivi intégré
Vous pouvez désormais acheminer les messages émis par la classe System.Diagnostics.Trace vers ASP.NET sortie de suivi et acheminer les messages émis par ASP.NET suivi vers System.Diagnostics.Trace. Vous pouvez également transférer ASP.NET événements d’instrumentation vers System.Diagnostics.Trace. Cette fonctionnalité est fournie par le nouvel attribut writeToDiagnosticsTrace de l’élément <trace> . Lorsque cette valeur booléenne a la valeur true, ASP.NET messages de trace sont transférés à l’infrastructure de suivi System.Diagnostics pour être utilisés par tous les écouteurs inscrits pour afficher les messages de trace.
Accès par programme aux messages de suivi
ASP.NET 2.0 autorise l’accès par programmation à tous les messages de trace via la classe TraceContextRecord et la collection TraceRecords . Le moyen le plus efficace d’accéder aux messages de trace consiste à inscrire un délégué TraceContextEventHandler (également nouveau dans ASP.NET 2.0) pour gérer le nouvel événement TraceFinished . Vous pouvez ensuite parcourir en boucle les messages de suivi comme vous le souhaitez.
L’exemple de code suivant illustre ceci :
void Page_Load(object sender, EventArgs e) {
// Register a handler for the TraceFinished event.
Trace.TraceFinished += new
TraceContextEventHandler(this.OnTraceFinished);
// Write a trace message.
Trace.Write("Web Forms Infrastructure Methods",
"USERMESSAGE: Page_Load complete.");
}
// A TraceContextEventHandler for the TraceFinished event.
void OnTraceFinished(object sender, TraceContextEventArgs e) {
TraceContextRecord r = null;
// Iterate through the collection of trace records and write
// them to the response stream.
foreach (object o in e.TraceRecords) {
r = (TraceContextRecord)o;
Response.Write(String.Format("trace message: {0} <BR>",
r.Message));
}
}
Dans l’exemple ci-dessus, j’effectue une boucle dans la collection TraceRecords, puis j’écris chaque message dans le flux de réponse.
Suivi Application-Level amélioré
Le suivi au niveau de l’application est amélioré par l’introduction du nouvel attribut mostRecent de l’élément <trace> . Cet attribut spécifie si la sortie de suivi au niveau de l’application la plus récente est affichée et si les données de trace plus anciennes au-delà des limites indiquées par requestLimit sont ignorées. Si la valeur est false, les données de trace sont affichées pour les requêtes jusqu’à ce que l’attribut requestLimit soit atteint.
Outils en ligne de commande ASP.NET
Il existe plusieurs outils en ligne de commande pour faciliter la configuration de ASP.NET. ASP.NET développeurs doivent être familiarisés avec l’outil aspnet_regiis.exe. ASP.NET 2.0 fournit trois autres outils en ligne de commande pour faciliter la configuration.
Les outils en ligne de commande suivants sont disponibles :
Outil | Utilisation |
---|---|
aspnet_regiis.exe | Permet l’inscription de ASP.NET auprès d’IIS. Il existe deux versions de ces outils qui sont livrées avec ASP.NET 2.0: une pour les systèmes 32 bits (dans le dossier Framework) et une pour les systèmes 64 bits (dans le dossier Framework64).) La version 64 bits ne sera pas installée sur un système d’exploitation 32 bits. |
aspnet_regsql.exe | L’outil Inscription de ASP.NET SQL Server est utilisé pour créer une base de données Microsoft SQL Server à utiliser par les fournisseurs de SQL Server dans ASP.NET, ou pour ajouter ou supprimer des options d’une base de données existante. Le fichier Aspnet_regsql.exe se trouve dans le dossier [lecteur:]\WINDOWS\Microsoft.NET\Framework\versionNumber sur votre serveur web. |
aspnet_regbrowsers.exe | L’outil Inscription du navigateur ASP.NET analyse et compile toutes les définitions de navigateur à l’échelle du système dans un assembly et installe l’assembly dans le global assembly cache. L’outil utilise les fichiers de définition de navigateur (. Fichiers BROWSER) du sous-répertoire Navigateurs .NET Framework. L’outil se trouve dans le répertoire %SystemRoot%\Microsoft.NET\Framework\version\. |
aspnet_compiler.exe | L’outil de compilation ASP.NET vous permet de compiler une application web ASP.NET, soit en place, soit pour un déploiement vers un emplacement cible tel qu’un serveur de production. La compilation sur place facilite les performances de l’application, car les utilisateurs finaux ne rencontrent pas de retard lors de la première demande adressée à l’application pendant la compilation de l’application. |
Étant donné que l’outil aspnet_regiis.exe n’est pas nouveau pour ASP.NET 2.0, nous n’en discuterons pas ici.
Outil d’inscription ASP.NET SQL Server - aspnet_regsql.exe
Vous pouvez définir plusieurs types d’options à l’aide de l’outil Inscription ASP.NET SQL Server. Vous pouvez spécifier une connexion SQL, spécifier les ASP.NET services d’application qui utilisent SQL Server pour gérer les informations, indiquer la base de données ou la table utilisée pour la dépendance du cache SQL et ajouter ou supprimer la prise en charge de l’utilisation de SQL Server pour stocker les procédures et l’état de session.
Plusieurs ASP.NET services d’application s’appuient sur un fournisseur pour gérer le stockage et la récupération des données à partir d’une source de données. Chaque fournisseur est spécifique à la source de données. ASP.NET inclut un fournisseur de SQL Server pour les fonctionnalités ASP.NET suivantes :
- Appartenance (classe SqlMembershipProvider ).
- Gestion des rôles (classe SqlRoleProvider ).
- Profil (classe SqlProfileProvider ).
- Personnalisation des composants WebPart (classe SqlPersonalizationProvider ).
- Événements web (la classe SqlWebEventProvider ).
Lorsque vous installez ASP.NET, le fichier Machine.config de votre serveur inclut des éléments de configuration qui spécifient SQL Server fournisseurs pour chacune des fonctionnalités ASP.NET qui reposent sur un fournisseur. Ces fournisseurs sont configurés, par défaut, pour se connecter à un utilisateur local instance de SQL Server Express 2005. Si vous modifiez la chaîne de connexion par défaut utilisée par les fournisseurs, avant de pouvoir utiliser l’une des fonctionnalités ASP.NET configurées dans la configuration de l’ordinateur, vous devez installer la base de données SQL Server et les éléments de base de données pour la fonctionnalité choisie à l’aide de Aspnet_regsql.exe. Si la base de données que vous spécifiez avec l’outil d’inscription SQL n’existe pas encore (aspnetdb sera la base de données par défaut si elle n’est pas spécifiée sur la ligne de commande), l’utilisateur actuel doit disposer des droits nécessaires pour créer des bases de données dans SQL Server ainsi que pour créer des éléments de schéma dans une base de données.
Dépendance de cache SQL
Une fonctionnalité avancée de la mise en cache de ASP.NET sortie est la dépendance du cache SQL. La dépendance du cache SQL prend en charge deux modes de fonctionnement différents : l’un qui utilise une implémentation ASP.NET d’interrogation de table et l’autre qui utilise les fonctionnalités de notification de requête de SQL Server 2005. L’outil d’inscription SQL peut être utilisé pour configurer le mode d’opération d’interrogation de table.
État de la session
Par défaut, les valeurs et les informations d’état de session sont stockées en mémoire dans le processus ASP.NET. Vous pouvez également stocker des données de session dans une base de données SQL Server, où elles peuvent être partagées par plusieurs serveurs Web. Si la base de données que vous spécifiez pour l’état de session avec l’outil d’inscription SQL n’existe pas déjà, l’utilisateur actuel doit disposer des droits nécessaires pour créer des bases de données dans SQL Server ainsi que pour créer des éléments de schéma dans une base de données. Si la base de données existe, l’utilisateur actuel doit disposer des droits nécessaires pour créer des éléments de schéma dans la base de données existante.
Pour installer la base de données d’état de session sur SQL Server, exécutez l’outil Aspnet_regsql.exe et fournissez les informations suivantes avec la commande :
- Nom du SQL Server instance, à l’aide de l’option -S.
- Informations d’identification d’ouverture de session pour un compte qui est autorisé à créer une base de données sur un ordinateur exécutant SQL Server. Utilisez l’option -E pour utiliser l’utilisateur actuellement connecté, ou utilisez l’option -U pour spécifier un ID utilisateur avec l’option -P pour spécifier un mot de passe.
- Option de ligne de commande -ssadd permettant d’ajouter la base de données d’état de session.
Par défaut, vous ne pouvez pas utiliser l’outil Aspnet_regsql.exe pour installer la base de données d’état de session sur un ordinateur exécutant SQL Server 2005 Express Edition.
Outil d’inscription du navigateur ASP.NET - aspnet_regbrowsers.exe
Dans ASP.NET version 1.1, le fichier Machine.config contenait une section appelée <browserCaps>. Cette section contenait une série d’entrées XML qui définissaient les configurations de différents navigateurs en fonction d’une expression régulière. Pour ASP.NET version 2.0, un nouveau . Le fichier BROWSER définit les paramètres d’un navigateur particulier à l’aide d’entrées XML. Vous ajoutez des informations sur un nouveau navigateur en ajoutant un nouveau . Fichier BROWSER dans le dossier situé dans %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers sur votre système.
Étant donné qu’une application ne lit pas un fichier .config chaque fois qu’elle a besoin d’informations de navigateur, vous pouvez créer un nouveau fichier . Fichier BROWSER et exécutez Aspnet_regbrowsers.exe pour ajouter les modifications requises à l’assembly. Cela permet au serveur d’accéder immédiatement aux nouvelles informations du navigateur afin que vous n’ayez pas à arrêter vos applications pour récupérer les informations. Une application peut accéder aux fonctionnalités du navigateur via la propriété Browser de la requête HttpRequest actuelle.
Les options suivantes sont disponibles lors de l’exécution de aspnet_regbrowser.exe :
Option | Description |
---|---|
-? | Affiche le texte d’aide Aspnet_regbbrowsers.exe dans la fenêtre de commande. |
-i | Crée l’assembly des fonctionnalités du navigateur d’exécution et l’installe dans le global assembly cache. |
-u | Désinstalle l’assembly des fonctionnalités du navigateur d’exécution du global assembly cache. |
Outil de compilation ASP.NET - aspnet_compiler.exe
L’outil compilation ASP.NET peut être utilisé de deux manières générales : pour la compilation sur place et la compilation pour le déploiement, où un répertoire de sortie cible est spécifié.
Compilation d’une application sur place
L’outil de compilation ASP.NET peut compiler une application sur place, c’est-à-dire qu’il imite le comportement de l’envoi de plusieurs requêtes à l’application, ce qui entraîne une compilation régulière. Les utilisateurs d’un site précompilé ne subiront pas de retard dû à la compilation de la page à la première demande.
Lorsque vous précompilez un site en place, les éléments suivants s’appliquent :
- Le site conserve ses fichiers et sa structure de répertoires.
- Vous devez disposer de compilateurs pour tous les langages de programmation utilisés par le site sur le serveur.
- Si un fichier échoue à la compilation, la compilation de l’ensemble du site échoue.
Vous pouvez également recompiler une application sur place après y avoir ajouté de nouveaux fichiers sources. L’outil compile uniquement les fichiers nouveaux ou modifiés, sauf si vous incluez l’option -c .
Notes
La compilation d’une application qui contient une application imbriquée ne compile pas l’application imbriquée. L’application imbriquée doit être compilée séparément.
Compilation d’une application pour le déploiement
Vous compilez une application pour le déploiement (compilation vers un emplacement cible) en spécifiant le paramètre targetDir. TargetDir peut être l’emplacement final de l’application web, ou l’application compilée peut être déployée davantage. L’utilisation de l’option -u compile l’application de telle sorte que vous pouvez apporter des modifications à certains fichiers de l’application compilée sans la recompiler. Aspnet_compiler.exe fait une distinction entre les types de fichiers statiques et dynamiques et les gère différemment lors de la création de l’application résultante.
- Les types de fichiers statiques sont ceux qui n’ont pas de compilateur ou de fournisseur de build associés, tels que les fichiers dont le nom a des extensions telles que .css, .gif, .htm, .html, .jpg, .js, etc. Ces fichiers sont simplement copiés vers l’emplacement cible, avec leur emplacement relatif dans la structure de répertoires conservé.
- Les types de fichiers dynamiques sont ceux qui ont un compilateur ou un fournisseur de build associé, y compris les fichiers avec des extensions de nom de fichier spécifiques à ASP.NET telles que .asax, .ascx, .ashx, .aspx, .browser, . master, et ainsi de suite. L’outil compilation ASP.NET génère des assemblys à partir de ces fichiers. Si l’option -u est omise, l’outil crée également des fichiers avec l’extension de nom de fichier . COMPILED qui mappent les fichiers sources d’origine à leur assembly. Pour garantir la conservation de la structure de répertoires de la source de l’application, l’outil génère des fichiers d’espace réservé aux emplacements correspondants dans l’application cible.
Vous devez utiliser l’option -u pour indiquer que le contenu de l’application compilée peut être modifié. Sinon, les modifications suivantes sont ignorées ou provoquent des erreurs d’exécution.
Le tableau suivant décrit comment l’outil de compilation ASP.NET gère différents types de fichiers lorsque l’option -u est incluse.
Type de fichier | Action du compilateur |
---|---|
.ascx, .aspx, . master | Ces fichiers sont divisés en balisage et code source, qui inclut à la fois des fichiers code-behind et tout code inclus dans <des éléments runat="server »> de script. Le code source est compilé en assemblys, avec des noms dérivés d’un algorithme de hachage, et les assemblys sont placés dans le répertoire Bin. Tout code inline, c’est-à-dire le code placé entre les < crochets % et %> , est inclus avec le balisage et non compilé. De nouveaux fichiers portant le même nom que les fichiers sources sont créés pour contenir le balisage et placés dans les répertoires de sortie correspondants. |
.ashx, .asmx | Ces fichiers ne sont pas compilés et sont déplacés vers les répertoires de sortie tels qu’ils sont et non compilés. Si vous souhaitez que le code du gestionnaire soit compilé, placez le code dans les fichiers de code source du répertoire App_Code. |
.cs, .vb, .jsl, .cpp (sans les fichiers code-behind pour les types de fichiers répertoriés précédemment) | Ces fichiers sont compilés et inclus en tant que ressource dans des assemblys qui les référencent. Les fichiers sources ne sont pas copiés dans le répertoire de sortie. Si un fichier de code n’est pas référencé, il n’est pas compilé. |
Types de fichiers personnalisés | Ces fichiers ne sont pas compilés. Ces fichiers sont copiés dans les répertoires de sortie correspondants. |
Fichiers de code source dans le sous-répertoire App_Code | Ces fichiers sont compilés en assemblys et placés dans le répertoire Bin. |
Fichiers .resx et .resource dans le sous-répertoire App_GlobalResources | Ces fichiers sont compilés en assemblys et placés dans le répertoire Bin. Aucun App_GlobalResources sous-répertoire n’est créé dans le répertoire de sortie main, et aucun fichier .resx ou .resources situé dans le répertoire source n’est copié dans les répertoires de sortie. |
Fichiers .resx et .resource dans le sous-répertoire App_LocalResources | Ces fichiers ne sont pas compilés et sont copiés dans les répertoires de sortie correspondants. |
Fichiers .skin dans le sous-répertoire App_Themes | Les fichiers .skin et les fichiers de thème statiques ne sont pas compilés et sont copiés dans les répertoires de sortie correspondants. |
.browser Web.config types de fichiers statiques Assemblys déjà présents dans le répertoire Bin | Ces fichiers sont copiés tels qu’ils sont dans les répertoires de sortie. |
Le tableau suivant décrit comment l’outil compilation ASP.NET gère différents types de fichiers lorsque l’option -u est omise.
Type de fichier | Action du compilateur |
---|---|
.aspx, .asmx, .ashx, . master | Ces fichiers sont divisés en balisage et code source, qui inclut à la fois des fichiers code-behind et tout code inclus dans <des éléments runat="server »> de script. Le code source est compilé en assemblys, avec des noms dérivés d’un algorithme de hachage. Les assemblys résultants sont placés dans le répertoire Bin. Tout code inline, c’est-à-dire le code placé entre les < crochets % et %> , est inclus avec le balisage et non compilé. Le compilateur crée des fichiers pour contenir le balisage portant le même nom que les fichiers sources. Ces fichiers résultants sont placés dans le répertoire Bin. Le compilateur crée également des fichiers portant le même nom que les fichiers sources, mais avec l’extension . COMPILED qui contiennent des informations de mappage. Lla. Les fichiers COMPILÉS sont placés dans les répertoires de sortie correspondant à l’emplacement d’origine des fichiers sources. |
.ascx | Ces fichiers sont divisés en balisage et code source. Le code source est compilé en assemblys et placé dans le répertoire Bin, avec des noms dérivés d’un algorithme de hachage. Aucun fichier de balisage n’est généré. |
.cs, .vb, .jsl, .cpp (sans les fichiers code-behind pour les types de fichiers répertoriés précédemment) | Le code source référencé par les assemblys générés à partir de fichiers .ascx, .ashx ou .aspx est compilé dans des assemblys et placé dans le répertoire Bin. Aucun fichier source n’est copié. |
Types de fichiers personnalisés | Ces fichiers sont compilés comme des fichiers dynamiques. Selon le type de fichier sur lequel ils sont basés, le compilateur peut placer des fichiers de mappage dans les répertoires de sortie. |
Fichiers dans le sous-répertoire App_Code | Les fichiers de code source de ce sous-répertoire sont compilés en assemblys et placés dans le répertoire Bin. |
Fichiers dans le sous-répertoire App_GlobalResources | Ces fichiers sont compilés en assemblys et placés dans le répertoire Bin. Aucun App_GlobalResources sous-répertoire n’est créé sous le répertoire de sortie main. Si le fichier de configuration spécifie appliesTo="All », les fichiers .resx et .resources sont copiés dans les répertoires de sortie. Ils ne sont pas copiés s’ils sont référencés par un BuildProvider. |
Fichiers .resx et .resource dans le sous-répertoire App_LocalResources | Ces fichiers sont compilés en assemblys avec des noms uniques et placés dans le répertoire Bin. Aucun fichier .resx ou .resource n’est copié dans les répertoires de sortie. |
Fichiers .skin dans le sous-répertoire App_Themes | Les thèmes sont compilés en assemblys et placés dans le répertoire Bin. Les fichiers stub sont créés pour les fichiers .skin et placés dans le répertoire de sortie correspondant. Les fichiers statiques (tels que .css) sont copiés dans les répertoires de sortie. |
.browser Web.config types de fichiers statiques Assemblys déjà présents dans le répertoire Bin | Ces fichiers sont copiés tels qu’ils sont dans le répertoire de sortie. |
Noms d’assembly fixes
Certains scénarios, tels que le déploiement d’une application web à l’aide de MSI Windows Installer, nécessitent l’utilisation de noms de fichiers et de contenus cohérents, ainsi que de structures de répertoire cohérentes pour identifier les assemblys ou les paramètres de configuration pour les mises à jour. Dans ce cas, vous pouvez utiliser l’option -fixednames pour spécifier que l’outil de compilation ASP.NET doit compiler un assembly pour chaque fichier source au lieu d’utiliser où plusieurs pages sont compilées en assemblys. Cela peut entraîner un grand nombre d’assemblys. Par conséquent, si vous êtes préoccupé par la scalabilité, vous devez utiliser cette option avec précaution.
Compilation de noms forts
Les options -aptca, -delaysign, -keycontainer et -keyfile sont fournies afin que vous puissiez utiliser Aspnet_compiler.exe pour créer des assemblys fortement nommés sans utiliser l’outil Strong Name Tool (Sn.exe) séparément. Ces options correspondent, respectivement, à AllowPartiallyTrustedCallersAttribute, AssemblyDelaySignAttribute, AssemblyKeyNameAttribute et AssemblyKeyFileAttribute.
La discussion de ces attributs n’entre pas dans le cadre de ce cours.
Laboratoires
Chacun des labos suivants s’appuie sur les labos précédents. Vous devrez les faire dans l’ordre.
Labo 1 : Utilisation de l’API de configuration
- Créez un site Web appelé mod9lab.
- Ajoutez un nouveau fichier de configuration web au site.
- Ajoutez le code suivant au fichier web.config :
<authorization>
<deny users="?"/>
</authorization>
<identity impersonate="true"/>
Cela garantit que vous êtes autorisé à enregistrer les modifications apportées au fichier web.config.
- Ajoutez un nouveau contrôle Label à Default.aspx et remplacez l’ID par lblDebugStatus.
- Ajoutez un nouveau contrôle Button à Default.aspx.
- Remplacez l’ID du contrôle Button par btnToggleDebug et le texte par Désactiver l’état du débogage.
- Ouvrez la vue code pour le fichier code-behind de Default.aspx et ajoutez une instruction using pour System.Web.Configuration comme suit :
using System.Web.Configuration;
- Ajoutez deux variables privées à la classe et une méthode Page_Init comme indiqué ci-dessous :
public partial class _Default : System.Web.UI.Page {
private bool _debugStatus;
private CompilationSection compilation;
private Configuration config;
protected void Page_Init(object sender, EventArgs e) {
config = WebConfigurationManager.OpenWebConfiguration("/mod9lab");
compilation =
(CompilationSection)config.GetSection("system.web/compilation");
_debugStatus = compilation.Debug;
}
}
- Ajoutez le code suivant à Page_Load :
lblDebugStatus.Text = "Debug set to: " + _debugStatus.ToString();
- Enregistrez et parcourez default.aspx. Notez que le contrôle Label affiche le status de débogage actuel.
- Double-cliquez sur le contrôle Button dans le concepteur et ajoutez le code suivant à l’événement Click pour le contrôle Button :
compilation.Debug = !_debugStatus;
config.Save();
lblDebugStatus.Text = "Debug set to: " + compilation.Debug.ToString();
- Enregistrez et parcourez default.aspx, puis cliquez sur le bouton .
- Ouvrez le fichier web.config après chaque clic de bouton et observez l’attribut de débogage dans la <section compilation> .
Labo 2 : Redémarrages de l’application de journalisation
Dans ce labo, vous allez créer du code qui vous permettra de basculer la journalisation des arrêts, des start-ups et des recompilations d’applications dans le observateur d'événements.
- Ajoutez un DropDownList à default.aspx et remplacez l’ID par ddlLogAppEvents.
- Définissez la propriété AutoPostBack pour dropDownList sur true.
- Ajoutez trois éléments à la collection Items pour dropDownList. Définissez le texte pour le premier élément Sélectionner la valeur et la valeur -1. Définissez le texte et la valeur du deuxième élément true et le texte et la valeur du troisième élément False.
- Ajoutez une nouvelle étiquette à default.aspx. Remplacez l’ID par lblLogAppEvents.
- Ouvrez la vue code-behind pour default.aspx et ajoutez une nouvelle déclaration pour une variable de type HealthMonitoringSection, comme indiqué ci-dessous :
public partial class _Default : System.Web.UI.Page {
private bool _debugStatus;
private CompilationSection compilation;
private Configuration config;
// new variable below
private HealthMonitoringSection health;
}
- Ajoutez le code suivant au code existant dans Page_Init :
health = (HealthMonitoringSection)config.GetSection("system.web/healthMonitoring");
- Double-cliquez sur dropDownList et ajoutez le code suivant à l’événement SelectedIndexChanged :
if (ddlLogAppEvents.SelectedValue != "-1") {
if (Convert.ToBoolean(ddlLogAppEvents.SelectedValue)) {
RuleSettings appRules = new
RuleSettings("AppRestartEvents",
"Application Lifetime Events",
"EventLogProvider");
health.Rules.Add(appRules);
config.Save();
} else {
health.Rules.Remove("AppRestartEvents");
config.Save();
}
}
Parcourez default.aspx.
Définissez la liste déroulante sur False.
Effacez le journal d’application dans le observateur d'événements.
Cliquez sur le bouton pour modifier l’attribut Debug pour l’application.
Actualisez le journal d’application dans le observateur d'événements.
- Des événements ont-ils été enregistrés ?
- Pourquoi ou pourquoi pas ?
Définissez la liste déroulante sur True.
Cliquez sur le bouton pour désactiver l’attribut Debug pour l’application.
Actualisez la connexion de l’application observateur d'événements.
- Des événements ont-ils été enregistrés ?
- Quelle a été la raison de l’arrêt de l’application ?
Essayez d’activer et de désactiver la journalisation et examinez les modifications apportées au fichier web.config.
Informations complémentaires :
Le modèle fournisseur de ASP.NET 2.0 vous permet de créer vos propres fournisseurs non seulement pour l’instrumentation d’application, mais aussi pour de nombreuses autres utilisations, telles que l’appartenance, les profils, etc. Pour plus d’informations sur l’écriture d’un fournisseur personnalisé pour journaliser les événements d’application dans un fichier texte, consultez ce lien.