Débogage ASP.NET (niveau 300)

Débogage ASP.NET (niveau 300) Présentation de l’outillage standard d’ASP.NET 2.0 et de Visual Studio Team System Health Monitoring Profiling Tests de charge Gestion des anomalies dans TFS Pause Débogage d’applications ASP.NET en production Préambule Outils pour la capture et l’analyse Présentation de WinDbg et SOS IIS et CLR Commande SOS Exemple de problématiques

Débogage ASP.NET (niveau 300) Présentation de l’outillage standard d’ASP.NET 2.0 et de Visual Studio Team System Daniel TIZON Resp. du pôle Génie Logiciel /Team System - Winwise daniel.tizon@winwise.fr - http://blogs.developpeur.org/daniel

Introduction Avec les outils inclus dans ASP.NET et Team System… Vous disposez d’outils utiles pour éviter de traiter les problèmes en production Ils sont à votre disposition mais souvent méconnus des développeurs

Agenda Health Monitoring Profiling Tests de charge Gestion des anomalies dans TFS

Health Monitoring D’ASP.NET 2.0 « Comment surveiller les signes vitaux des applications en production »

Health Monitoring Un mécanisme standard d’ASP.NET2.0 Gère les événements importants dans la vie de l’application L’application démarre ou s’arrête Compilations Etat du processus Evénements d’erreur Erreurs de requêtes : exception non gérées, etc… Erreurs de configuration : compilation, parser,… Extensible

Health Monitoring : Hiérarchie des types d’événements

Health Monitoring : WebBaseEvent Contient des informations communes Des types plus spécialisés Pile des appels, adresse du client, informations de thread/process, information de requête public class WebBaseEvent { // properties public DateTime EventTime; public string Message; public object EventSource; public long EventSequence; public int EventCode; public int EventDetailCode; // methods static public void Raise(WebBaseEvent eventRaised); }

Health Monitoring : Configuration Dans le Web.config du serveur Dans le Web.config de l’application Section <healthMonitoring> <eventMappings>  événements gérés <providers>  destinataires enregistrés <rules>  mappage événements/destinataires <profiles>  paramètres des événements <bufferModes>  paramètres des destinataires

Health Monitoring : Destinataires d’événements S’appuie sur le modèles de providers Providers disponibles EventLogWebEventProvider BufferedWebEventProvider MailWebEventProvider SimpleMailWebEventProvider SqlWebEventProvider TemplatedMailWebEventProvder TraceWebEventProvider WMIWebEventProvider Extensible

Health Monitoring : Filtrage des événements Filtrage par hiérarchie de type Exemple : capturer toutes les erreurs ou uniquement les erreurs de configuration Les types peuvent être mappés à plusieurs fournisseurs Exemple : Toutes les erreurs  Event Log Erreurs de configuration  Email

Health Monitoring : Contraintes sur les événements Par palier Ex: 1 par minute Par seuils Minima/Maxima Ex : seulement 10 premières occurrences Ex : seulement à partir de la 10ième occurrence

Demo Health Monitoring

Le Profiling Dans Visual Studio 2005 for Team Developers « Identification des portions de codes à optimiser (mémore/perf) »

Le Profiling Intégré à Visual Studio 2005 for Team Developers Rassemble les informations sur les temps d’exécution et performances Méthodes qui prennent le plus de temps Consomment le plus de mémoire Les plus appelées Deux méthodes de mesure Sampling : ponctionne des informations à intervalles réguliers sur ce qui est exécuté Instrumentation : enregistre tous les appels

Le Profiling Code managé v2.0 Tout type de cible Exécutables Bibliothèques de classes Applications Web ASP.NET Services Windows VS n’a pas besoin d’être lancé Permet de rapidement maximiser les gains de performance Profiling sur les tests Unitaires également

Profiling : Sampling ou Instrumentation Le Sampling a moins d’impact sur l’exécution Analyse de la pile Non intrusive Des méthodes peuvent être manquées L’instrumentation insère du code entre les méthodes Résultats précis Coûteux sur l’exécution

AMethod main BMethod main 3 AMethod 6 BMethod 9 2 Profiling : Sampling Analyse sans modification de l’application main AMethod BMethod This slide shows how sampling works: no code is added to the application. Instead, the stack is polled at intervals in order to see which methods are executing at that time. main 3 AMethod 6 BMethod 9 2 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. 19

AMethod main BMethod main 001 AMethod 0023 BMethod 0098 Profiling : Intrumentation Injection de code main AMethod BMethod main 001 AMethod 0023 BMethod 0098 This build shows how instrumentation works: the light-green bars show how code is added at the entry and exit points of each method, so that precise statistics are gathered about calls to each method. Point out fast-cap, this slide only shows call-cap. Translation, we also instrument around any calls to external references, so we collect data on the instrumented code + one level deeper. Even if this doesn’t make it into the picture, it should be in the notes. This is important because it allows you to see what system calls are expensive in the context of your application. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary. 20

Profiling : depuis Visual Studio 2005 Via le menu Tools/Performances Tools Performance Wizard Choix de l’application à profiler: Projet de la soluton courante Exécutable (.exe), Librairie (.dll), Application ASP.NET. Choix de la méthode: Sampling, Instrumentation Performance Explorer Configuration, exécution Analyse et stockage des résultats Résumé Fonctions et Appelant/Appelés Pile des appels Exportation XML

Profiling : à la ligne de commande En mode instrumentation VSPerfCLREnv /traceon VSInstr <binaire> VSPerfCmd /start:trace /output:<fichier de sortie>.VSP Exécuter l’application VSPerfCmd /shutdown En mode Sampling VSPerfCLREnv /sampleon VSPerfCmd /start:sample / output:<fichier de sortie>.VSP VSPerfCmd /launch:<binaire> /args:<arguments> Intéragir avec l’application et sortir En s’attachant à un processus en mode Sampling Démarrer l’application VSPerfCmd /attach:<PID> VSPerfCmd /detach:<PID>

Demo Profiling

Les Tests de charge Dans Visual Studio 2005 for Team Testers « un moyen de détecter des problèmes habituellement remontés qu’en production »

Tests de Charge Intégré à Visual Studio 2005 for Team Testers Charge constante ou progressive Applications Web ou tests unitaires Récolte des données sur les performances De l’application Des serveurs concernés Génère des rapports Possibilité d’ajouter un contrôleur et agents externes

Tests de Charge : Types de charge supportés Charge fixe Nombre fixe d’utilisateurs, Permet de vérifier que l’application tient Charge progressive Le nombre d’utilisateurs varie, À partir d’une valeur minimale, Par paliers, Jusqu’à une valeur limite Permet de déterminer les limites de l’application

Tests de Charge : Sur des Tests Web Créer des test web Enregistrer le scénario de navigation dans IE Scripter/modifier l’enregistrement Possibilités de databinding Définir la répartition selon les types de navigateurs Le(s) type(s) de connexion utilisé(s) Les tests sélectionnés (scénarios différents) Exemple: 10% de Firefox, 5% de smartphone, 85% IE6.0 90% ADSL, 10% de modem 56k… 90% d’affichage de la page d’accueil, 10% création commande

Tests de Charge : Procédure pas à pas Créer un projet de type Tests Créer des tests Web et/ou Unitaires Créer un test « Load Test » Sélectionner les tests Web/Unitaires Distribution des % d’exécution de chacun Choisir le type de charge Sélectionner les compteurs de performance

Tests de Charge : Agents de test VS2005 Team Edition for Software Testers Load Agent Produit séparé de Team Suite Permet de simuler plus de charge Env 1000 par processeur Composé de : Team Test Load Agent : simule les tests Team Test Load Controller : pilote les agents

Demo Tests de Charge

Gestion des anomalies avec Team Foundation Server (TFS) « Remontée des anomalies depuis des applications Web en production aux équipes de développement dans TFS »

Team Foundation Server: Une extension de VS Développeur Testeur Chef de Projet Architecte Application Team Edition for Testers Team Edition for Developers Architecte Infrastructure Team Explorer Microsoft Project Microsoft Excel Team Edition for Architects Team Foundation Server Utilisateurs & Management Contrôleur de Versions Serveur Build Portail Projet Work Items Navigateur Web Etats & Analyses

Team Foundation Server: Architecture Architecture multi-couche Couche données SQL Server 2005 Couche applicative WebServices Windows Sharepoint Services Reporting Services Couche cliente Visual Studio 2005 MS Office : Excel / Project Internet Explorer (via WSS) Team Explorer …

Team Foundation Server: Architecture logique Visual Studio Office Lignes de commande Plug-in Excel Plug-in MS Project Packages IE Modèle objet de Team Foundation (API managée) SOAP/HTTP(S) WSS (portail projet) Team Foundation services d’intégration Evénements et notifications Service d’enregistrement Service de liaison Web Parts Team Foundation services de données SQL Reporting services Gestion des Work Items Services de compilation Gestion de sources Rapports MSSQL/TCP Team Foundation couche données WI (Product Studio) SCC Données de compilation Warehouse Méthodologies

Les Work Items: De quoi s’agit-il ? Un concept générique pour Créer de l’information La faire évoluer La partager La suivre Basés sur des modèles Données, comportement Définis au niveau Team Project Extensibles

Les Work Items: Concrètement Un Work Item possède : Un type: Bogue, Tâche, Demande d’évolution,… Des états: Actif, Résolu, Fermé,… Motif de passage d’un Etat à l’autre Nouveau, Fixé, Obsolète, Non reproduit Des champs: Titre, Description, Date, Assigné à , Area, Itération,… Un historique Des pièces jointes Peuvent être liés à Du code, un test, résultat d’une compilation, un autre Work Item, Un fichier, un lien hypertexte

Modèle Objet: Team Foundation Server Team Server Object Model The Team Foundation Server object model is the public interface to the Team Foundation Server. It communicates with Web services on the application tier which in turn communicates with the SQL database on the data tier. Consumers such as the Team Foundation Client or integrators can sit on top of the Team Foundation Server object model to interact with the Server. The root node of the object model is encapsulated by the TeamFoundationServer managed class. This class contains basic properties of the server and APIs for working with various components of the server such as source code control and work item tracking. Connecting to a TFS To connect to a TFS, users must construct a TeamFoundationServer object. The TeamFoundationServerFactory should be used to get create an instance of a TeamFoundationServer object. When a TeamFoundationServer object is created by the factory, an instance of it will be cached so subsequent calls to the factory will return the same instance. It is important that all Team Foundation services share the same Team Foundation Sever instance to avoid multiple prompts for credentials. The TeamFoundationServerFactory method signatures match those of the TeamFoundationServer constructors. One constructor takes only a server name and defaults to the caller’s Windows credentials. Additional constructors are available for specifying non-default credentials. Non-default credentials are discussed further in the next section. public static class TeamFoundationServerFactory { public static TeamFoundationServer GetServer(string name) public static TeamFoundationServer GetServer(string name, ICredentials credentials) public static TeamFoundationServer GetServer(string name, ICredentialsProvider credentialsProvider) } Note that the name of the Team Foundation Server can be specified as either a URL or friendly name. Authentication The ICredentialsProvider interface is used for authenticating users other than the currently running user. The UICredentialsProvider class implements this interface. The examples below illustrate use of non-default credentials. Handling credentials from a console application // Parses the /login option or sets default credentials, among other things. Command command = CreateCommand(args); ICredentialsProvider provider = new UICredentialsProvider(); TeamFoundationServer m_tfs = TeamFoundationServerFactory.GetServer(m_server, provider); while (true)    { try        { // A Command requests by URL a TFS object from CommandLine object once it // determines the URL. // CommandLine object has a method to get cached credentials from the // credentials provider based on user name and URL.         command.Run();         break;     }  catch (UnauthorizedException)     { // Now prompt user, etc.  If it succeeds, we try the command again. // Otherwise, Authenticate() // will throw an Unauthorized exception and break out of this loop.         m_tfs.Authenticate();     } Handling credentials on a server application // Use default credentials (e.g., ASNET user), retrieve from registry, // retrieve from DPAPI cache, etc. TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(m_server);         try         { // Find out up front whether we can even start.           tfs.Authenticate(); // Make tfs calls // If any subsequent call fails with the unauthorized exception, the whole // thing ends.  For example, the current user's account password expires.         }         catch (UnauthorizedException) // Somehow record the problem.  For example, write event to event log, send // email, update status Web page, etc. Handling credentials for a Windows application // Start UI, bring up application. // At some point in the app, make the first contact with the server // by authenticating logged on user or whatever is specified in VS // options dialog. TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(m_server, provider); // Make sure we can go. // Now try to authenticate.  If unsuccessful, use tfsUICredProvider to // request credentials.             tfs.Authenticate(); // User can't or won't authenticate.  Shut down the app. // Do other UI stuff.  At any time, an unauthorized exception could occur // due to password expiration, changing users by dropping and reconnecting // to the VPN, etc.  The UI app writer will need to decide whether to handle // that, and if so, call tfs.Authenticate() when catching the exception. TeamFoundationServerFactory GetServer The TeamFoundationServerFactory should be used to get an instance of a TeamFoundationServer object. When a TeamFoundationServer object is created by the factory, an instance of it will be cached so subsequent calls to the factory will return the same instance. It is important that all Team Foundation services share the same Team Foundation Sever instance to avoid multiple prompts for credentials. Logic of getting a TeamFoundationServer object: If a TeamFoundationServer object with the specified name exists in the cache, it is returned. If not, one is created with the default credentials for the current user and no credential provider. The created TeamFoundationServer object is placed in the cache and associated with the Uri resolved for the name. Each of the TeamFoundationServerFactory method signatures match the method signatures of the TeamFoundationServer constructors. Getting a Team Foundation Server: Syntax C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies

Modèle Objet: Work Items The work item object model is the public interface to the work item tracking components of Microsoft® Visual Studio 2005® Team System. It communicates with the work item tracking Web service on the application tier which communicates with the SQL Server™ database on the data tier. Consumers such as the Team Explorer or integrators can sit on top of the work item object model to interact with the work item tracking system. The root node of the work item object model is encapsulated by the WorkItemStore managed class and is one of several APIs exposed by a Team Foundation Server, encapsulated by a TeamFoundationServer class. For every TeamFoundationServer, there is exactly one WorkItemStore, which covers all the work items, fields, and stored queries defined for that Team Foundation Server. At a high level, the WorkItemStore allows users to get instances of work items, which contain information such as field values, links, and attachments. It also allows users to get information about the context of work items, such as team projects and work item types. Scenarios Here are common scenarios involving the Work item object model. Visual Studio 2005 SDK The VSIP client displays queries, results, and individual work items. It interacts with the Team Foundation work item tracking via the Work item object model. Visual Studio 2005 SDK does not have to interact with any other APIs, such as the Web service. It has one consistent API to work from and does not have to duplicate any logic for handling work items. Customers Jose, an A. Datum developer, just deployed Team Foundation at his company. He is interested in integrating work item tracking into his company's in-house development environment. He deploys a Team Foundation Server. From this object, he sees all the available services for the Team Foundation Server API, including the work item object model. He browses the work item object model to get a feel for how it works. After investigating, Jose decides to add a user interface to their development environment that leverages the Work item object model to show stored queries, run queries, and open individual work items. Tool Smiths Jill, an independent software vendor architect, sees an opportunity to build a tool that integrates Team Foundation work item tracking with Microsoft® Office Outlook® 2003. The tool allows users to see and manipulate their assigned work items from Outlook's task list. Her team codes against the work item object model and Outlook's API to query for a user's work items and add those work items to the task list. When users modify their tasks in Outlook, the tool applies the changes to the work items on the Team Foundation Server. Using the Object Model The subsequent subsections discuss the basics of using the work item object model. Getting Work Items The most basic function of the WorkItemStore is getting work items. A work item is uniquely identified by its ID (a positive integer) and Artifact URI (see the Team Foundation Linking Service document for more information about artifacts). The WorkItemStore exposes methods for getting any existing work item using either of these unique identifiers. public WorkItem GetWorkItem(int id) public WorkItem GetWorkItem(Uri uri) Additionally, every revision of a work item is stored so that users can also get work items as of a specific date/time or revision index. public WorkItem GetWorkItem(int id, DateTime at) public WorkItem GetWorkItem(int id, int revision) public WorkItem GetWorkItem(Uri uri, DateTime at) public WorkItem GetWorkItem(Uri uri, int revision) Manipulating Work Items After getting an existing WorkItem or creating a new WorkItem using the constructors below, you can read values from the work item and make edits. public WorkItem(WorkItemStore store, WorkItemType type) The major components of a work item are as follows. Store – Every work item belongs to a WorkItemStore. Project – Every work item belongs to a team project on the Team Foundation Server. Type – Every work item is an instance of a specific work item type. The work item type defines the fields, rules, and workflow for the work item. Work item types are scoped to team projects. Revision – The revision count for the work item. Revisions – The collection of all revisions of the work item. Do not get this confused with the System.History field which is a text field used to track the conversation thread for a work item. Fields – The collection of fields defined by the work item type. The value for each Field in the collection can be viewed and edited. Links – A collection of outbound links. Work items can link to each other, other artifacts, or URL/UNC paths. Attachments – A collection of file attachments that are stored with a work item on the server. The Fields, Links, and Attachments collections of a WorkItem can be viewed and edited. Once any edits are made to these parts of a WorkItem, the work item is marked as dirty via the IsDirty property. Changes to a work item are committed to the server via Save() method. Unless a work item is saved, all changes to it will be lost. When saving a work item, rules defined for the work item type will be evaluated. Violations will throw exceptions upon saving. If there are no violations, the work item is successfully saved, its revision is incremented, and its history updated with the latest changes. Note that an IsValid() method can be used to evaluate whether a work item's fields pass all rules before attempting to save the work item. Each time a work item is committed, a new revision is created for that work item. The latest revision of a work item reflects its current state, while previous revisions reflect the state of the work item at different points in its history. Different revisions of a work item are akin to different versions of source code on a server. In this model of work item revisioning, the System.History field requires special handling. This field behaves like a discussion thread where each reply to the thread is stored in a separate revision of the work item. In the work item form, the aggregated values of all revisions of the history field is shown. When editing the history field programmatically, the caller can append a new entry to the history thread by setting the fields value in the current revision to the desired text. Because previous entries in the history thread are associated with previous revisions, the latest revision of a work item can have an empty History field value even if the history thread shows text on the work item form. A good example of reading and writing to the history field is provided in the samples.

Gestion des anomalies dans Team Foundation Server Demo Gestion des anomalies dans Team Foundation Server

Ressources De manière générale Les starters kits : http://www.asp.net/downloads/starterkits/default.aspx?tabid=62 Télécharger Visual Web Developer 2005 Express Edition : http://www.microsoft.com/france/msdn/vstudio/express/vwd/default.mspx Le centre de développement ASP .NET sur MSDN : http://www.microsoft.com/france/msdn/aspnet/default.mspx

Ressources A propos de l’health monitoring A propos du Profiling ASP.NET Health Monitoring : http://msdn2.microsoft.com/en-gb/library/ms178701.aspx Vue d'ensemble du contrôle d'état ASP.NET : http://msdn2.microsoft.com/fr-fr/library/ms178703.aspx Procédure pas à pas : écoute des événements WMI lors du contrôle d'état ASP.NET : http://msdn2.microsoft.com/fr-fr/library/ms178713.aspx A propos du Profiling Visual Studio Team System 2005 Performance Tool FAQ : http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=339481&SiteID=1 A propos des Tests de Charge Test de charge avec Team System : quoi, quand, comment ? : http://blogs.microsoft.fr/antoined/archive/2005/12/20/16639.aspx