Cours C Sharp avancé : Introduction au framework .NET

1 Introduction

est la partie du Framework Microsoft .NET dédiée au développement des applications web. 

Le Framework .NET est constitué de deux parties : une librairie de classes et le CLR (Common Runtime Language).

Il existe 5 versions du Framework .NET : 1.0, 1.1, 2.0, 3.0 et 3.5. Les versions 1.x sont obsolètes. Nous étudierons ici la version 3.5.

1.1 La Librairie de classes

Le Framework .NET contient des milliers de classes que vous pouvez utiliser pour développer vos applications. Parmi ces classes, on peut citer par exemple la classe File utilisée pour manipuler des fichiers, la classe Graphics utilisée pour manipuler des images de différents formats ou la classe SmtpClient utilisée pour envoyer du courrier avec le protocole SMTP.

Ce ne sont que quelques exemples, le Framework .NET contient environ 13000 de ces classes !

Vous pouvez obtenir une liste détaillée de ces classes avec leur documentation à cette adresse :

Pour information, le Framework 2.0 contient 18619 types, 12909 classes, 401759 méthodes et 93105 propriétés publiques. Les Frameworks suivants en contiennent beaucoup plus. Evidemment, il faut connaître parfaitement toutes ces classes.

1.2 Rappel

Chaque classe contient des propriétés, des méthodes et des événements.  Les propriétés, méthodes et événements de la classe sont appelés les membres de la classe. 

Par exemple, voici quelques membres de la classe SmtpClient :

Propriétés :

Host : Le nom ou l’adresse IP du serveur mail

Port : Le numéro du port sur le serveur

Méthodes :

Send : Envoie un mail de façon synchrone 

SendAsync : Envoie un mail de façon asynchrone

Évènements 

SendCompleted : Se produit quand l’envoi d’un mail de façon asynchrone est termine.

1.3 Les Namespaces

Fort heureusement, Microsoft a divisé les classes du Framework en entités nommes « Namespaces » (espaces de nom en français).  Un namespace est une sorte de « boîte » dans laquelle des classes ayant (plus ou moins) rapport entre elles sont regroupées. Par exemple, les classes utilisées pour accéder a un serveur SQL Server sont regroupées dans un namespace nomme « .SqlClient ». Autre exemple, toutes les classes utilisées par sont regroupes dans un namespace .

1.4 Les Assemblies

Une Assembly (assemblée en français) est un fichier DLL dans lequel les classes sont stockées.  Par exemple, les classes utilisées par le namespace sont stockées dans un fichier . 

Pour faire l’analogie (en gros) avec Java,  on pourrait dire que les classes du Framework .NET sont regroupées en namespaces, (les packages), eux-mêmes regroupés en assemblies (les .jar).

Tout comme en Java, pour pouvoir utiliser une classe, il faut configurer l’application (nous verrons comment plus tard) pour qu’elle référence la bonne assembly, puis importer le namespace de la classe. 

1.5 CLR

La seconde partie du Framework .NET est le Common Language Runtime. Le Common Language Runtime (CLR pour les intimes) se charge de l’exécution de votre code. 

Quand vous écrivez une application pour le Framework .NET avec un langage comme C# ou Visual Basic .NET, votre source n’est jamais compilé directement en binaire. Le compilateur C# ou VB convertit votre code dans un langage spécial nomme MSIL

(Microsoft Intermediate Language, Langage intermédiaire Microsoft en français). Les familiers de Java sont ici en terrain connu. MSIL est une sorte d’assembleur orienté objet ( ! ), mais à la différence d’un assembleur, il n’est pas spécifique à un CPU, il est indépendant de la plate forme sur laquelle il tourne.

Lorsque l’application est exécutée, le MSIL est compile alors (en temps réel) en binaire (donc ici spécifique a la plateforme) par le JITTER (Just-In-Time compilER).

En fait, toute l’application n’est pas compilée en binaire. Seules les méthodes appelées durant l’exécution sont compilées.

En réalité, le Framework .NET ne comprend qu’un seul langage : MSIL. Cependant, Microsoft va vous épargner cette tache ingrate en vous permettant de développer vos applications en Visual Basic .NET ou C#, les compilateurs MSIL de ces langages étant inclus dans le Framework .NET. 

D’autres langages existent cependant (soit libres, soit commerciaux), on peut citer : Cobol, Eiffel, Fortran, Pascal, Python, etc.… (Développer un site ?Web 2.0? en Cobol, avouez que ce n'est pas banal). Les premières versions du Framework étaient également livrées avec un compilateur Script (Le JavaScript Microsoft) et J# (Langage Java), mais il semble que ces langages ne soient plus soutenus dans les versions récentes.

Dans les faits, les développeurs utiliseront C# ou Visual . Les vrais développeurs utiliseront C#. 

Un petit mot sur la compilation

Lorsque vous créez une page web , vous créez en fait le code source d’une classe .NET (Une instance de la classe

). Le contenu entier de la page (incluant script ET contenu HTML) sont compilés dans une classe .NET

Quand vous appelez cette page via un browser, le Framework vérifie si une classe correspondent à cette page existe. Si elle n’existe pas, il compile automatiquement cette page dans une nouvelle classe et sauve la classe compilée (l’assembly) dans un dossier temporaire situé (pour le Framework 2.0) à cet emplacement :

\WINDOWS\\Framework\v2.0.50727\Temporary Files

Le 2.0.5xxx correspond à la version du Framework. Plusieurs frameworks peuvent coexister et être utilisés en même temps sur la même machine. Chaque Framework aura son propre dossier. 

Lors de la requête suivante sur cette page, la classe ne sera pas recompilée. Même si vous arrêtez le serveur web et le relancez plus tard, le Framework utilisera cette classe compilée (sauf si vous modifiez le fichier source, dans ce cas, elle est recompilée).

Quand la classe est ajoutée au dossier temporaire , une dépendance est créée entre la classe et la page source . Si la page est modifiée, la classe correspondante est automatiquement effacée pour être recompilée la prochaine fois que la page sera appelée. 

Ce procédé est nommé compilation dynamique et permet des performances qui vont bien au delà de ce que permettait ASP qui interprétait les pages à chaque requête.

1.6 Installation du framework

Il y a plusieurs façons d’installer et de développer avec le framework.

1.Le système d’exploitation

Nous utiliserons pour nos développements une machine fonctionnant sous Windows  (2000 SP4, XP SP2-3, Vista ou server), Les exemples ici utilisent XP SP3. Je préconise l’utilisation de XP pro, cette version disposant en standard du serveur web IIS. 

2. Activation d’IIS

IIS (Internet Information Server) est le serveur Web de Microsoft. Une version limitée (un seul site, une seule application) est livrée avec Windows XP Pro / Vista. Vous utiliserez IIS si vous n'utilisez pas l'environnement de développement de Microsoft qui intègre son propre serveur web (Cassini).

(Notez que si vous utilisez Windows XP ou Vista Home Edition, vous n'aurez pas le choix, IIS n'étant pas intégré au système.)

Si vous utilisez XP Pro, pour activer IIS : Panneau de Contrôle, Ajouter / Supprimer des programmes, cliquez sur Ajouter /

Supprimer des composants Windows, puis cochez la case « Internet Information Services (IIS) » 

(Note : Tous les exemples et les copies d’écrans ont été réalises sur une version US de Windows XP Pro).

3.Installez le SDK du Framework .NET

Le SDK (Software Development Kit) du Framework .NET installe toutes les assemblies sur la machine, la documentation, des exemples ainsi que les compilateurs en ligne de commande. Cette étape n’est pas indispensable si on utilise l’environnement de développement de Microsoft, mais je la recommande car elle contient des informations et des outils qu’on ne retrouve pas ailleurs.

On peut télécharger ce SDK à cette adresse :  

4) L’environnement de développement

On peut utiliser les outils en ligne de commande et Notepad (pour les courageux ou les masochistes), ou un IDE libre comme SharpDevelop () , mais je préconise l’installation de l’IDE de Microsoft : Visual Studio Web Express 2008. 

Visual Studio Express 2008 est un excellent IDE gratuit qui existe en 4 versions : C#, Visual Basic, C++ et Web. Les 3 premières versions sont utilisées pour développer des applications Windows Desktop dans ces langages respectifs. La dernière version peut être utilisée en C# ou Visual Basic et sert à construire des applications web . C’est celle-ci qui nous intéresse. 

Téléchargez-la à cette adresse et installez-la :

(Les exemples donnés ici utilisent la version US de Visual Studio)

Apres l’avoir installé, vous devriez avoir quelque chose qui ressemble à ça :

2 La structure d'une application

Nous allons commencer par un exemple complexe : Afficher une page web dans laquelle se trouvent un champ de saisie et un bouton. L’utilisateur saisit son nom dans le champ de saisie, clique sur le bouton et le message « Bonjour » suivi de son nom est affiche en retour.  

Pour cet exemple nous allons utiliser des contrôles . Nous étudierons en détail ces contrôles plus loin, pour l’instant contentons-nous de les utiliser « bêtement »

Profitons-en pour faire un petit tour du propriétaire de Visual Studio Express Web 2008 (VS 2008 pour les inities).

Commençons par créer un nouveau projet : 

File -> New Web Site

Qu’avons-nous ici ?

1)  Le type de projet : En ce qui nous concerne, nous sélectionnerons Web Site

2)  L’emplacement : on peut choisir soit le file system (un emplacement sur le disque dur, le serveur web utilisé sera alors Cassini, le serveur web intégré à VS 2008), soit HTTP (à choisir si on veut utiliser un site web avec IIS, nous verrons comment faire plus tard), soit FTP.

Pour notre exemple, choisissez « file system » et un dossier de travail.

3)  On choisit le langage : les gens sérieux choisirons donc Visual C#.

Le projet est crée et nous arrivons dans l’environnement de travail VS 2008. La page par défaut créée est .

4 zones importantes :

1)  La Toolbox  [Boîte à outils] : ici sont affichés tous les contrôles utilisables dans une page . C’est également dans la toolbox que seront affichés les contrôles provenant d’autres éditeurs que Microsoft. C’est également dans cet emplacement qu’on pourra éditer les propriétés CSS en cliquant sur l’onglet « CSS Properties »

2)  L’éditeur de code. Cet éditeur est wysiwyg. Vous pouvez y travailler en 3 modes : texte (vous voyez le source),

Design (vous travaillez directement sur la page web) ou Split (vous voyez le source en haut et le rendu en bas)

3)  La structure du projet : Les fichiers sont affichés ici sous forme arborescente. Un deuxième onglet (« Database

Explorer ») est disponible, il permet de se connecter à une base de données et d’en afficher le contenu directement.

4)  Le panneau properties : affiche en permanence les propriétés et événements du contrôle sélectionné. On peut évidemment modifier les propriétés ici. Toute modification est automatiquement reportée dans le source et dans l’écran Design et réciproquement.

Allons-y !

Mettons nous en mode « Design » et déplaçons dans la fenêtre un contrôle « TextBox », un contrôle « Button » et un contrôle « Label »

Belle page n’est-ce pas ?

On peut la visualiser tout de suite via le serveur web en cliquant sur l’icône « Start Debugging » (flèche verte)

Première chose visible : Cassini, le serveur web intégré à VS 2008 est lance. Son activité est visible dans la barre de taches

:

Deuxième chose visible : une alerte demande si on autorise le debugging. Par défaut il est désactivé, en cliquant sur OK, on va autoriser le debugging pour ce site (nous verrons comment debugger un peu plus loin).

La page s’affiche dans le navigateur par défaut du système (ici IE 7) :

Evidemment, cliquer sur le bouton ne fait rien, va falloir bosser un peu.

Retour a VS.

On arrête le debug (bouton carre bleu « Stop Debugging »).

Nous allons pour cet exemple travailler uniquement en mode design. Les pros (dont nous sommes évidemment) utilisent uniquement le mode Source, mais il faut bien commencer par quelque chose.

Cliquez donc sur le bouton. Ses propriétés s’affichent à droite

Si l’envie vous prend, vous pouvez modifier ici sa couleur ou sa police, intéressons nous a l’icône « Events » (l’éclair)

Sans entrer dans les détails pour l’instant, saisissons le nom d’une fonction (helloClick) pour la propriété Click, après avoir clique sur Entrée, le source de cette fonction est affichée automatiquement. 

Tapons juste la ligne suivante :

Et relançons l’application (bouton flèche verte « Debug »)

Saisissons un nom dans le champ de saisie et cliquons sur le bouton.

Ô Magie, le message « Bonjour » suivi du nom s’affiche.

Je vous laisse à votre émotion cinq minutes et je reviens pour voir un peu en détail ce qui s’est passe.

Regardons déjà dans le « solution explorer » à quoi ressemble notre projet

Ce projet est constitué de 3 fichiers (oublions le dossier App_Data pour l’instant). 

Un fichier qui est le nom de la page web (c’est ce nom qui sera dans l’url tapée dans le browser). Cette page contient les contrôles , le code HTML, en gros toute la partie « présentation » de la page (ce n’est pas entièrement vrai, nous verrons pourquoi plus tard).

Un fichier associé à la page . Ce fichier appelé fichier « Code Behind » contient le code associé à la page. C’est ici qu’on codera la logique nécessaire à la génération du contenu de la page. Ce code peut également être directement intégré dans le fichier ASPX (plus de fichier code behind dans ce cas). Ce sera souvent le cas dans nos exemples pour rendre les sources plus concis. Je préconise cependant de mettre la partie présentation et la partie code dans deux fichiers séparés.

Notez que l’extension du  fichier est .CS (le contenu est en C#), ce sera .VB pour du code en Visual BASIC.

Enfin le fichier web.config. Ce fichier est un fichier XML qui va décrire comment doit se comporter le site web et quel est son paramétrage. Par défaut, VS 2008 préconfigure une partie de ce fichier. (Par exemple, il n’autorise pas le debugging par défaut, d’où le message affiché précédemment, le fait d’avoir autorisé le debugging à modifié un paramètre dans ce fichier).

On peut également créer des dossiers et y placer les pages ASPX et associées pour créer une arborescence dans le site.

OK, allons voir un peu le contenu de ces fichiers :

Le fichier

	<%	@PageLanguage="C#"AutoEventWireup="true"  CodeFile="" Inherits="_Default"%>

A première vue, ca ressemble beaucoup a un fichier HTML classique,  deuxième vue aussi d’ailleurs. 

Où est la différence ?

D’abord sur la 1ere ligne.

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="" Inherits="_Default" %>

Cette ligne configure les propriétés de la page. Il y en a d’autres que nous verrons plus loin, retenons CodeFile qui va indiquer le nom du fichier .cs associé et Inherits le nom de la classe associée (on la retrouvera dans le fichier .cs)

Suit le formulaire  

Haut du formulaire

Bas du formulaire

Vous noterez qu'une page est *TOUJOURS* insérée dans un formulaire. C'est le contenu de ce formulaire (tag

Haut du formulaire

Bas du formulaire

) qui est envoyée au serveur, les contrôles doivent donc être dans ce formulaire quoiqu'il arrive. 

Ceci implique donc que vous ne pouvez en aucun cas placer un formulaire dans votre page . Avec oubliez donc l'existence même du tag

Haut du formulaire

Bas du formulaire

, vous n'y avez plus droit (et d'ailleurs, je ne vois pas ce que vous feriez avec…)

Suivent enfin les contrôles

<asp:TextBoxID="TextBox1"runat="server">asp:TextBox>

 

Trois contrôles : 

  un TextBox (champ de saisie) dont l’identifiant est « TextBox1 »           un Button (Bouton) dont l’identifiant est « Button1 » et dont l’événement « onclick » appelle la fonction « helloClick »

  un Label (une zone de texte) dont l’identifiant est « Label1 »

Nous allons voir en détail tous ces contrôles et leur fonctionnement. Pour juste anticiper et dégrossir un peu, disons que les contrôles ont tous un attribut « runat= "server" » qui signifie que la génération de ce contrôle et ses événements se produiront sur le serveur. Le onclick du bouton ici n’est pas un événement onclick JavaScript qui se déclenche sur le client, c’est un événement qui va exécuter une fonction sur le serveur.

Puis le fichier

usingSystem;

usingSystem.Configuration;using;using;using;using.Security;

using; using.HtmlControls;using.WebControls;using.WebControls.WebParts;using; publicpartialclass_Default: .Page { protectedvoidPage_Load(objectsender,EventArgse)     {      } protectedvoidhelloClick(objectsender,EventArgse)     {         ="Bonjour "+ ;     } }

Qu’y trouvons-nous ?

Une série de directives using. Cette instruction (l’équivalent du import en java) importe les namespaces utilises dans la page. En l’occurrence nous n’utilisons pas tous ces namespaces ici, mais VS 2008 importe par défaut tous les namespaces de l’assembly et Linq.

Suit la déclaration de la classe _Default (nom donne par défaut par VS). _Default est une page , elle hérite donc de la classe Page. (Souvenez vous que dans le fichier ASPX de la propriété Inherits="_Default" indiquant que la page ASPX allait

utiliser cette classe). 

Enfin, c’est une classe partielle, une partie de son code est automatiquement généré par VS : vous noterez qu’on peut utiliser directement les contrôles définis dans la page ASPX sans les avoir redeclarés ici (ce qu’on était obligé de faire avec le Framework

1.x), c’est parce  qu’ils sont déclarés dans une autre partie de la classe, dans une dll non visible ici.

protectedvoidhelloClick(objectsender,EventArgse)

    {

        ="Bonjour "+ ;

    }

On y trouve la définition de la fonction décrite dans le fichier ASPX ici :

Que fait cette fonction ? Elle modifie la propriété « Text » du contrôle Label1 (le contenu de ce label) en y plaçant  "Bonjour"  + le contenu de la propriété Text du contrôle TextBox1 (le champ de saisie).

Puis une autre fonction : 

protectedvoidPage_Load(objectsender,EventArgse) {  }

Qu’est ce que c’est que cette fonction ?

Une page ASPX, lorsqu’elle est générée sur le serveur passe par plusieurs étapes (chargement en mémoire, traitement des évènements des contrôles, transformation des contrôles en contrôles html standards, etc.…). A chaque étape de la génération de cette page, un évènement se produit, Page_Load est l’un d’eux. 

Il y a beaucoup d’évènements. On peut affecter du code à chacun de ces évènements. 

Dans 95% (voire plus), on n’utilisera que l’évènement Page_Load qui se produit quand la page est chargée, avant que les évènements des contrôles aient eu lieu. C’est dans cette fonction qu’on va placer généralement tout le code qui va être utilisé dans la page et c’est pour ca que VS 2008 propose par défaut cette fonction vide, libre au développeur de la remplir.

Voyons un peu quelles fonctions sont appelées lors de la génération de la page :

Page_Init : Appelé lorsque l’évènement Init se déclenche. Elle est appelée avant toute opération sur la page.

Page_Load : Pendant cet événement, vous pouvez effectuer une série d'actions pour créer votre page pour la première fois ou répondre aux événements côté clients qui résultent d'une publication.

Page_DataBind : L'événement DataBind se produit quand on veut lier des données à la page (nous verrons cela plus tard).

Page_PreRender : L'événement PreRender est déclenché juste avant que l'état d'affichage soit enregistré et que les contrôles soient affichés. Vous pouvez utiliser cet événement pour effectuer toute opération de dernière minute sur vos contrôles.

Page_Unload : Une fois qu'une page a été affichée, l'événement Page_Unload se déclenche. Cet événement est approprié à la réalisation d'un travail final de nettoyage, tel que le nettoyage des connexions ouvertes de base de données, la suppression d'objets ou la fermeture de fichiers ouverts.

Il y en a d’autres mais leur utilisation est très spécifique.

Note sur Page_Load

Cette fonction est donc appelée à chaque fois que la page est générée. Que ce soit la première fois qu’elle est appelée par le browser ou suite à un évènement sur la page (un click sur le bouton va rappeler la page pour exécuter le code associé au click). 

La propriété IsPostBack de la classe Page (dont dérive notre page) permet de savoir si la page est générée suite a sa création initiale ou suite a un évènement sur cette page (on dit qu’elle est rappelée ou qu’un postback a eu lieu).

Modifions donc notre code : 

protectedvoidPage_Load(objectsender,EventArgse)

    {

if(!IsPostBack) { =" Cliquez "; }else{ =" Cliquez encore "; }

    }

La première fois qu’on appelle cette page, le texte du bouton est « Cliquez »

Puis, a chaque fois que l’utilisateur clique sur le bouton, la fonction « helloClick » est appelée sur le serveur, donc l’évènement Load est déclenché, donc la fonction Page_Load est appelée, en testant la propriété IsPostBack, on saura si la fonction est appelée lors de la création initiale de la page ou si c’est suite a un évènement sur la page.

Détail sur les évènements :

Lorsqu’une fonction est appelée par un évènement, elle passe deux paramètres :

protected void Page_Load(object sender, EventArgs e)

Le premier,  sender est l’objet sur lequel l’évènement s’est produit, ici l’objet Page, dans notre fonction helloClick, se serait le bouton Button1. Ce paramètre est utile si on fait pointer plusieurs évènements sur la même fonction.  Le deuxième paramètre va varier en fonction de l’évènement. Ici il n’y a pas d’information supplémentaire, le paramètre est donc un objet EventArgs (paramètres standards d’un évènement). 

Un click sur un contrôle ImageButton (un bouton qui est en fait une image) passera en paramètre a la place d’EventArgs un objet ImageClickEventArgs qui contient des informations supplémentaires (par exemple les coordonnées x, y de la souris lors du

click). 

En fait, la page est un contrôle comme un autre, et à ce titre, tous les contrôles ont le même cycle de vie et les mêmes évènements (Init, Load, Prerender, Dispose, …). Vous pouvez donc associer une fonction à un de ces évènements pour un contrôle précis de la page. Dans la pratique, pour éviter qu'on ne sache plus trop où et quand s'exécute le code, on se limitera aux évènements de la page.

Un peu confus ? Ca va aller en s’améliorant, ne vous inquiétez pas…

Avant de passer aux choses sérieuses, étudions notre dernier fichier, .

Pour les habitues des serveurs d’applications J2EE, on peut dire que est « l’équivalent » du fichier .

Il contient la configuration de l’application web, on peut y placer ses propres paramètres (plutôt que de les éparpiller dans des fichiers textes, ou dans la base de registres), on peut y placer également les chaines de connexions sur les bases de données, etc.… Nous n’allons pas passer en revue l’intégralité du paramétrage de ce fichier, nous y reviendrons au coup par coup selon les besoins.

Regardons juste ce que nous aurons éventuellement à modifier dans ce fichier.

AppSettings

Dans cette section, nous pourrons (éventuellement) placer des paramètres utilises par notre application :

<appSettings>

      <addkey="cle"value="value"/>

appSettings>

Et les lire avec la une méthode de la classe ConfigurationSettings.

Ex: String val = ConfigurationSettings.AppSettings("cle");

connectionStrings

<connectionStrings>

   <addname="cnx"connectionString=" localhost;Initial

Catalog=appservicesdb;Integrated                

   Security=True" providerName=".SqlClient" />

connectionStrings>

Dans cet exemple, nous définissons une connexion sur une base de données SQL Server. Nous verrons plus loin comment utiliser ces connexions.

Assemblies

<assemblies>

   <addassembly=", Version=3.5.0.0, Culture=neutral,    

    PublicKeyToken=B77A5C561934E089"/>

   <addassembly=".Extensions, Version=3.5.0.0, Culture=neutral,

PublicKeyToken=31BF3856AD364E35"/>

   <addassembly=".DataSetExtensions, Version=3.5.0.0, Culture=neutral,

PublicKeyToken=B77A5C561934E089"/>

   <addassembly=", Version=3.5.0.0, Culture=neutral, 

    PublicKeyToken=B77A5C561934E089"/>

assemblies>

Ici sont définies les assemblies qui vont être utilisées dans l’application web. On pourra ensuite importer avec la directive using les namespaces de ces assemblies dont nous avons besoin. Notez que si l’assembly n’est pas référencée ici, l’import dans la page aspx provoquera une erreur. Toujours pour faire une analogie avec Java, on peut dire que cette section est en fait le classpath.

Notez également que l’assembly est définie par son nom suivis de paramètres optionnels comme la version (il est possible de référencer plusieurs versions de la même assembly et d’utiliser des namespaces provenant de plusieurs versions), la culture (ici neutral, une assembly peut être liée a une culture particulière, par exemple en-US  ou fr, elle sera utilisée en fonction de la culture sélectionnée dans la page) et enfin une clef publique unique qui permet de vérifier que la dll correspondante n’a pas été remplacée par une autre a l’insu de l’administrateur du site.

A priori, vous ne devriez pas, pour commencer, avoir besoin de bricoler d’autres sections de ce fichier.

3 Les contrôles

Entrons donc dans le vif du sujet. Les contrôles (ceux disponibles dans la toolbox et dont nous avons vu trois spécimen) sont la clef de voute d’. Un contrôle est une classe qui s’exécute sur le serveur et renvoie en retour un contenu à afficher dans le navigateur.

Le Framework inclut en standard environ 70 contrôles, et des sociétés tierces en proposent des centaines d’autres ! Ces contrôles vous permettent quasiment tout, de la simple ligne de texte a la bannière de publicité en passant par le traitement de texte intégré ou le tableau affichant les données d’une base.

Ces contrôles sont divisés en 8 groupes :

Les contrôles standards : Ils vous permettent d’utiliser les éléments de base des formulaires comme les boutons, les champs de saisie, les labels.

Les contrôles de validation : Ils vous permettent de valider un formulaire avant de soumettre ses données au serveur.

Les contrôles "riches" : Ils affichent des objets plus complexes comme les calendriers, les wizards, les boutons pour uploader des fichiers, les bannières de publicités ou les éditeurs de texte

Les contrôles de données : Ils vous permettent de travailler avec des données comme par exemples des données issues d’une base de données. Vous pouvez utiliser ces contrôles pour afficher, modifier, supprimer ou ajouter des données.            Les contrôles de navigation : Ils vous permettent d’afficher des éléments de navigation dans le site comme les menus, les arbres ou les breadcrumbs

Les contrôles de login : Ils affichent des boites de login avec nom d’utilisateur et mot de passe, vous permettent de modifier les mots de passe ou d’afficher des formulaire d’enregistrement

Enfin, les contrôles HTML. Ils vous permettent de transformer n’importe quel tag HTML standard en control

3.1 Viewstate

Avant de voir les contrôles en détail, abordons une caractéristique très importante et intéressante d’ : le viewstate.

Le protocole http, comme vous devez le savoir et un protocole « stateless » (sans état) : Chaque fois que vous demandez l’affichage d’une page d’un site, pour le serveur web, vous êtes une personne complètement différente et nouvelle.

Le Framework cependant permet de dépasser cette limitation du protocole http. Par exemple, si vous assignez une valeur à la propriété Text d’un label, comme nous l’avons fait, le contrôle conservera cette valeur durant toutes les requêtes qui seront faites sur cette page.

Pour mieux comprendre, prenons cet exemple : (Attention, pour des raisons de concision, le code qui se trouve normalement dans la page est ici directement dans la page aspx. Pour cela, il est juste place dans un tag