Vue d’ensemble de ASP.NET 4 et Visual Studio 2010 pour le développement web

2023-07-14

Ce document fournit une vue d’ensemble de nombreuses nouvelles fonctionnalités pour ASP.NET incluses dans the.NET Framework 4 et dans Visual Studio 2010.

Télécharger ce livre blanc

Contents

Services principaux
de fichierWeb.config _Toc253429239
Mise en cache de sortie extensible
Démarrage automatique des applications web
Redirection permanente d’une page
Réduction de l’état de session
Extension de la plage d’URL autorisées
Validation des demandes extensibles
Mise en cache d’objets et extensibilité de mise en cache d’objets
Codage d’en-têtes HTTP, d’URL et d’URL extensibles
Analyse des performances pour des applications individuelles dans un processus de travail unique
Multi-ciblage

Ajax
jQuery inclus avec Web Forms et MVC
Prise en charge du réseau de distribution de contenu
Scripts explicites ScriptManager

Web Forms
Définition des balises meta avec les propriétés Page.MetaKeywords et Page.MetaDescription
Activation de l’état d’affichage pour les contrôles individuels
Modifications apportées aux fonctionnalités du navigateur
Routage dans ASP.NET 4
Définition des ID client
Persistance de la sélection de lignes dans les contrôles de données
ASP.NET Chart Control
Filtrage des données avec le contrôle QueryExtender
Expressions de code encodées html
Modifications du modèle de projet
Améliorations css
Masquage d’éléments div autour de champs masqués
Rendu d’une table externe pour les contrôles modèle
Améliorations du contrôle ListView
Améliorations du contrôle CheckBoxList et RadioButtonList
Améliorations apportées au contrôle de menu
Assistant et CreateUserWizard Controls 56

ASP.NET MVC
Prise en charge des zones
Prise en charge de la validation des attributs d’annotation de données
Helpers avec modèle

Données dynamiques
Activation des données dynamiques pour les projets existants
Syntaxe de contrôle DynamicDataManager déclarative
Modèles d’entité
Nouveaux modèles de champ pour les URL et les adresses de messagerie
Création de liens avec le contrôle DynamicHyperLink
Prise en charge de l’héritage dans le modèle de données
Prise en charge des relations plusieurs-à-plusieurs (Entity Framework uniquement)
Nouveaux attributs pour contrôler l’affichage et la prise en charge des énumérations
Prise en charge améliorée des filtres

Améliorations apportées au développement web visual Studio 2010
Compatibilité CSS améliorée
Extraits de code HTML et JavaScript
Améliorations apportées à JavaScript IntelliSense

Déploiement d’applications web avec Visual Studio 2010
Empaquetage web

Déploiement de base de données
Publier en un clic pour les applications web
Ressources

Avertissement

Services de base

ASP.NET 4 introduit un certain nombre de fonctionnalités qui améliorent les principaux services ASP.NET, tels que la mise en cache de sortie et le stockage d’état de session.

refactorisation de fichier Web.config

Le Web.config fichier qui contient la configuration d’une application web a considérablement augmenté au cours des dernières versions du .NET Framework à mesure que de nouvelles fonctionnalités ont été ajoutées, telles que Ajax, le routage et l’intégration à IIS 7. Cela a rendu plus difficile la configuration ou le démarrage de nouvelles applications web sans un outil tel que Visual Studio. Dans .net Framework 4, les principaux éléments de configuration ont été déplacés vers le fichier et les machine.config applications héritent désormais de ces paramètres. Cela permet au Web.config fichier dans ASP.NET 4 applications d’être vide ou de contenir uniquement les lignes suivantes, qui spécifient pour Visual Studio quelle version de l’infrastructure l’application cible :

<?xml version="1.0"?>
  <configuration>
   <system.web>
    <compilation targetFramework="4.0" /> 
   </system.web>
  </configuration>

Mise en cache de sortie extensible

Depuis la publication de ASP.NET 1.0, la mise en cache de sortie a permis aux développeurs de stocker la sortie générée des pages, des contrôles et des réponses HTTP en mémoire. Sur les requêtes web suivantes, ASP.NET pouvez traiter le contenu plus rapidement en récupérant la sortie générée à partir de la mémoire au lieu de régénérer la sortie à partir de zéro. Toutefois, cette approche présente une limitation : le contenu généré doit toujours être stocké en mémoire, et sur les serveurs qui connaissent un trafic important, la mémoire consommée par la mise en cache de sortie peut concurrencer les demandes de mémoire d’autres parties d’une application web.

ASP.NET 4 ajoute un point d’extensibilité à la mise en cache de sortie qui vous permet de configurer un ou plusieurs fournisseurs de cache de sortie personnalisés. Les fournisseurs de cache de sortie peuvent utiliser n’importe quel mécanisme de stockage pour conserver le contenu HTML. Cela permet de créer des fournisseurs de cache de sortie personnalisés pour divers mécanismes de persistance, qui peuvent inclure des disques locaux ou distants, un stockage cloud et des moteurs de cache distribués.

Vous créez un fournisseur de cache de sortie personnalisé en tant que classe qui dérive du nouveau type System.Web.Caching.OutputCacheProvider . Vous pouvez ensuite configurer le fournisseur dans le fichier à l’aide Web.config de la sous-section nouveaux fournisseurs de l’élément outputCache , comme illustré dans l’exemple suivant :

<caching>
  <outputCache defaultProvider="AspNetInternalProvider">
    <providers>
      <add name="DiskCache"
          type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>
    </providers>
  </outputCache>

</caching>

Par défaut, dans ASP.NET 4, toutes les réponses HTTP, toutes les pages rendues et tous les contrôles utilisent le cache de sortie en mémoire, comme illustré dans l’exemple précédent, où l’attribut defaultProvider est défini sur AspNetInternalProvider. Vous pouvez modifier le fournisseur de cache de sortie par défaut utilisé pour une application web en spécifiant un autre nom de fournisseur pour defaultProvider.

En outre, vous pouvez sélectionner différents fournisseurs de cache de sortie par contrôle et par demande. Le moyen le plus simple de choisir un autre fournisseur de cache de sortie pour différents contrôles utilisateur web consiste à le faire de manière déclarative en utilisant le nouvel attribut providerName dans une directive de contrôle, comme illustré dans l’exemple suivant :

<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %>

La spécification d’un autre fournisseur de cache de sortie pour une requête HTTP nécessite un peu plus de travail. Au lieu de spécifier de manière déclarative le fournisseur, vous remplacez la nouvelle méthode GetOuputCacheProviderName dans le fichier pour spécifier par programmation le Global.asax fournisseur à utiliser pour une demande spécifique. L’exemple suivant vous montre comment procéder.

public override string GetOutputCacheProviderName(HttpContext context)
{
    if (context.Request.Path.EndsWith("Advanced.aspx"))
       return "DiskCache";
    else
        return base.GetOutputCacheProviderName(context);
}

Avec l’ajout de l’extensibilité du fournisseur de cache de sortie à ASP.NET 4, vous pouvez maintenant poursuivre des stratégies de mise en cache de sortie plus agressives et plus intelligentes pour vos sites Web. Par exemple, il est désormais possible de mettre en cache les 10 premières pages d’un site en mémoire, tout en mettant en cache les pages qui obtiennent moins de trafic sur le disque. Vous pouvez également mettre en cache chaque combinaison variable pour une page rendue, mais utiliser un cache distribué afin que la consommation de mémoire soit déchargée des serveurs Web frontaux.

Démarrage automatique des applications web

Certaines applications web doivent charger de grandes quantités de données ou effectuer un traitement d’initialisation coûteux avant de traiter la première demande. Dans les versions antérieures de ASP.NET, pour ces situations, vous deviez concevoir des approches personnalisées pour « réveiller » une application ASP.NET, puis exécuter du code d’initialisation pendant la méthode Application_Load dans le Global.asax fichier.

Une nouvelle fonctionnalité de scalabilité nommée démarrage automatique qui traite directement ce scénario est disponible lorsque ASP.NET 4 s’exécute sur IIS 7.5 sur Windows Server 2008 R2. La fonctionnalité de démarrage automatique fournit une approche contrôlée pour le démarrage d’un pool d’applications, l’initialisation d’une application ASP.NET, puis l’acceptation des requêtes HTTP.

Notes

Module de Warm-Up d’application IIS pour IIS 7.5

L’équipe IIS a publié la première version de test bêta du module Application Warm-Up pour IIS 7.5. Cela rend le réchauffement de vos applications encore plus facile que décrit précédemment. Au lieu d’écrire du code personnalisé, vous spécifiez les URL des ressources à exécuter avant que l’application web accepte les requêtes du réseau. Ce préchauffage se produit au démarrage du service IIS (si vous avez configuré le pool d’applications IIS comme AlwaysRunning) et lorsqu’un processus de travail IIS se recycle. Pendant le recyclage, l’ancien processus de travail IIS continue d’exécuter les demandes jusqu’à ce que le processus de travail nouvellement généré soit entièrement réchauffé, de sorte que les applications ne rencontrent aucune interruption ou d’autres problèmes dus à des caches non prêts. Notez que ce module fonctionne avec n’importe quelle version de ASP.NET, à partir de la version 2.0.

Pour plus d’informations, consultez Préchauffement des applications sur le site Web IIS.net. Pour obtenir une procédure pas à pas illustrant l’utilisation de la fonctionnalité de préchauffement, consultez Prise en main avec le module de Warm-Up d’application IIS 7.5 sur le site web IIS.net.

Pour utiliser la fonctionnalité de démarrage automatique, un administrateur IIS définit un pool d’applications dans IIS 7.5 pour qu’il soit démarré automatiquement à l’aide de la configuration suivante dans le applicationHost.config fichier :

<applicationpools>
  <add name="MyApplicationPool" startMode="AlwaysRunning" />
</applicationpools>

Étant donné qu’un pool d’applications unique peut contenir plusieurs applications, vous spécifiez des applications individuelles à démarrer automatiquement à l’aide de la configuration suivante dans le applicationHost.config fichier :

<sites>
  <site name="MySite" id="1">
    <application path="/" 
      serviceAutoStartEnabled="true"
      serviceAutoStartProvider="PrewarmMyCache" >
      <!-- Additional content -->
    </application>
  </site>

</sites>

<!-- Additional content -->

<serviceautostartproviders>
  <add name="PrewarmMyCache"
    type="MyNamespace.CustomInitialization, MyLibrary" />
</serviceautostartproviders>

Lorsqu’un serveur IIS 7.5 est démarré à froid ou qu’un pool d’applications individuel est recyclé, IIS 7.5 utilise les informations contenues dans le applicationHost.config fichier pour déterminer quelles applications web doivent être démarrées automatiquement. Pour chaque application marquée pour le démarrage automatique, IIS7.5 envoie une demande à ASP.NET 4 pour démarrer l’application dans un état pendant lequel l’application n’accepte temporairement pas les requêtes HTTP. Lorsqu’il est dans cet état, ASP.NET instancie le type défini par l’attribut serviceAutoStartProvider (comme illustré dans l’exemple précédent) et appelle son point d’entrée public.

Vous créez un type de démarrage automatique managé avec le point d’entrée nécessaire en implémentant l’interface IProcessHostPreloadClient , comme illustré dans l’exemple suivant :

public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        // Perform initialization. 
    }
}

Une fois que votre code d’initialisation s’est exécuté dans la méthode Preload et que la méthode est retournée, l’application ASP.NET est prête à traiter les demandes.

Avec l’ajout du démarrage automatique à IIS .5 et ASP.NET 4, vous disposez désormais d’une approche bien définie pour effectuer une initialisation d’application coûteuse avant de traiter la première requête HTTP. Par exemple, vous pouvez utiliser la nouvelle fonctionnalité de démarrage automatique pour initialiser une application, puis signaler à un équilibreur de charge que l’application a été initialisée et prête à accepter le trafic HTTP.

Redirection permanente d’une page

Il est courant dans les applications web de déplacer des pages et d’autres contenus au fil du temps, ce qui peut entraîner une accumulation de liens obsolètes dans les moteurs de recherche. Dans ASP.NET, les développeurs gèrent traditionnellement les requêtes vers les anciennes URL à l’aide de la méthode Response.Redirect pour transférer une requête vers la nouvelle URL. Toutefois, la méthode Redirect émet une réponse HTTP 302 Trouvée (redirection temporaire), ce qui entraîne un aller-retour HTTP supplémentaire lorsque les utilisateurs tentent d’accéder aux anciennes URL.

ASP.NET 4 ajoute une nouvelle méthode d’assistance RedirectPermanent qui facilite l’émission de réponses HTTP 301 déplacées définitivement, comme dans l’exemple suivant :

RedirectPermanent("/newpath/foroldcontent.aspx");

Les moteurs de recherche et autres agents utilisateur qui reconnaissent les redirections permanentes stockent la nouvelle URL associée au contenu, ce qui élimine les allers-retours inutiles effectués par le navigateur pour les redirections temporaires.

Réduction de l’état de session

ASP.NET fournit deux options par défaut pour stocker l’état de session dans une batterie de serveurs Web : un fournisseur d’état de session qui appelle un serveur d’état de session hors processus et un fournisseur d’état de session qui stocke des données dans une base de données Microsoft SQL Server. Étant donné que les deux options impliquent le stockage des informations d’état en dehors du processus worker d’une application web, l’état de session doit être sérialisé avant d’être envoyé au stockage distant. En fonction de la quantité d’informations qu’un développeur enregistre dans l’état de session, la taille des données sérialisées peut augmenter assez grande.

ASP.NET 4 introduit une nouvelle option de compression pour les deux types de fournisseurs d’état de session hors processus. Lorsque l’option de configuration compressionEnabled illustrée dans l’exemple suivant a la valeur true, ASP.NET compresse (et décompresse) l’état de session sérialisé à l’aide de la classe .NET Framework System.IO.Compression.GZipStream .

<sessionState
  mode="SqlServer"
  sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
  allowCustomSqlDatabase="true"
  compressionEnabled="true"
/>

Avec l’ajout simple du nouvel attribut au fichier, les Web.config applications avec des cycles d’UC de réserve sur les serveurs web peuvent réaliser des réductions substantielles de la taille des données d’état de session sérialisées.

Extension de la plage d’URL autorisées

ASP.NET 4 introduit de nouvelles options pour augmenter la taille des URL d’application. Les versions précédentes de ASP.NET longueurs de chemin d’URL limitées à 260 caractères, en fonction de la limite de chemin d’accès au fichier NTFS. Dans ASP.NET 4, vous avez la possibilité d’augmenter (ou de diminuer) cette limite en fonction de vos applications, à l’aide de deux nouveaux attributs de configuration httpRuntime . L’exemple suivant montre ces nouveaux attributs.

<httpRuntime maxUrlLength="260" maxQueryStringLength="2048" />

Pour autoriser des chemins plus longs ou plus courts (la partie de l’URL qui n’inclut pas le protocole, le nom du serveur et la chaîne de requête), modifiez l’attribut maxUrlLength . Pour autoriser des chaînes de requête plus longues ou plus courtes, modifiez la valeur de l’attribut maxQueryStringLength .

ASP.NET 4 vous permet également de configurer les caractères utilisés par le caractère d’URL case activée. Quand ASP.NET trouve un caractère non valide dans la partie chemin d’accès d’une URL, il rejette la demande et émet une erreur HTTP 400. Dans les versions précédentes de ASP.NET, les vérifications de caractères d’URL étaient limitées à un ensemble fixe de caractères. Dans ASP.NET 4, vous pouvez personnaliser l’ensemble de caractères valides à l’aide du nouvel attribut requestPathInvalidCharacters de l’élément de configuration httpRuntime , comme illustré dans l’exemple suivant :

<httpRuntime requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,:,\,?"  />

Par défaut, l’attribut requestPathInvalidCharacters définit huit caractères comme non valides. (Dans la chaîne affectée à requestPathInvalidCharacters par défaut, les caractères inférieurs à (<), supérieurs à (>) et ampèresand (&) sont encodés, car le Web.config fichier est un fichier XML.) Vous pouvez personnaliser l’ensemble de caractères non valides si nécessaire.

Notes

Notez ASP.NET 4 rejette toujours les chemins d’URL qui contiennent des caractères dans la plage ASCII de 0x00 à 0x1F, car il s’agit de caractères d’URL non valides tels que définis dans la RFC 2396 de l’IETF (http://www.ietf.org/rfc/rfc2396.txt). Sur les versions de Windows Server qui exécutent IIS 6 ou une version ultérieure, le pilote de périphérique de protocole http.sys rejette automatiquement les URL avec ces caractères.

Validation des demandes extensibles

ASP.NET validation des requêtes recherche les chaînes couramment utilisées dans les attaques de script intersite (XSS) dans les données de requête HTTP entrantes. Si des chaînes XSS potentielles sont trouvées, la validation de la demande signale la chaîne suspecte et retourne une erreur. La validation de requête intégrée retourne une erreur uniquement lorsqu’elle trouve les chaînes les plus courantes utilisées dans les attaques XSS. Les tentatives précédentes pour rendre la validation XSS plus agressive ont entraîné un trop grand nombre de faux positifs. Toutefois, les clients peuvent souhaiter une validation des demandes plus agressive ou, à l’inverse, peuvent vouloir relâcher intentionnellement les vérifications XSS pour des pages spécifiques ou pour des types spécifiques de demandes.

Dans ASP.NET 4, la fonctionnalité de validation des demandes a été rendue extensible afin que vous puissiez utiliser une logique de validation de requête personnalisée. Pour étendre la validation des requêtes, vous créez une classe qui dérive du nouveau type System.Web.Util.RequestValidator et vous configurez l’application (dans la section httpRuntime du Web.config fichier) pour utiliser le type personnalisé. L’exemple suivant montre comment configurer une classe de validation de requête personnalisée :

<httpRuntime requestValidationType="Samples.MyValidator, Samples" />

Le nouvel attribut requestValidationType nécessite une chaîne d’identificateur de type .NET Framework standard qui spécifie la classe qui fournit la validation des demandes personnalisées. Pour chaque requête, ASP.NET appelle le type personnalisé pour traiter chaque partie des données de requête HTTP entrantes. L’URL entrante, tous les en-têtes HTTP (à la fois les cookies et les en-têtes personnalisés) et le corps de l’entité sont tous disponibles pour inspection par une classe de validation de requête personnalisée, comme indiqué dans l’exemple suivant :

public class CustomRequestValidation : RequestValidator
{
    protected override bool IsValidRequestString(
      HttpContext context, string value, 
      RequestValidationSource requestValidationSource, 
      string collectionKey, 
      out int validationFailureIndex) 
    {...}
 }

Dans les cas où vous ne souhaitez pas inspecter un morceau de données HTTP entrantes, la classe de validation de la demande peut se replier pour laisser le ASP.NET validation de requête par défaut s’exécuter en appelant simplement base. IsValidRequestString.

Mise en cache d’objets et extensibilité de mise en cache d’objets

Depuis sa première version, ASP.NET a inclus un puissant cache d’objets en mémoire (System.Web.Caching.Cache). L’implémentation du cache a été si populaire qu’elle a été utilisée dans des applications non web. Toutefois, il est difficile pour une application Windows Forms ou WPF d’inclure une référence à System.Web.dll simplement pour pouvoir utiliser le cache d’objets ASP.NET.

Pour rendre la mise en cache disponible pour toutes les applications, .NET Framework 4 introduit un nouvel assembly, un nouvel espace de noms, certains types de base et une implémentation de mise en cache concrète. Le nouvel System.Runtime.Caching.dll assembly contient une nouvelle API de mise en cache dans l’espace de noms System.Runtime.Caching . L’espace de noms contient deux ensembles principaux de classes :

Types abstraits qui fournissent la base de la création de tout type d’implémentation de cache personnalisé.
Implémentation concrète du cache d’objets en mémoire (classe System.Runtime.Caching.MemoryCache ).

La nouvelle classe MemoryCache est modélisée étroitement sur le cache ASP.NET, et elle partage une grande partie de la logique du moteur de cache interne avec ASP.NET. Bien que les API de mise en cache publique dans System.Runtime.Caching aient été mises à jour pour prendre en charge le développement de caches personnalisés, si vous avez utilisé l’objet cache ASP.NET, vous trouverez des concepts familiers dans les nouvelles API.

Une discussion approfondie de la nouvelle classe MemoryCache et de la prise en charge des API de base nécessite un document entier. Toutefois, l’exemple suivant vous donne une idée du fonctionnement de la nouvelle API de cache. L’exemple a été écrit pour une application Windows Forms, sans dépendance sur System.Web.dll.

private void btnGet_Click(object sender, EventArgs e) 
{ 
    //Obtain a reference to the default MemoryCache instance. 
    //Note that you can create multiple MemoryCache(s) inside 
    //of a single application. 
    ObjectCache cache = MemoryCache.Default; 

    //In this example the cache is storing the contents of a file string 
    fileContents = cache["filecontents"] as string;

    //If the file contents are not currently in the cache, then 
    //the contents are read from disk and placed in the cache. 
    if (fileContents == null) 
    {
        //A CacheItemPolicy object holds all the pieces of cache 
        //dependency and cache expiration metadata related to a single 
        //cache entry. 
        CacheItemPolicy policy = new CacheItemPolicy(); 

        //Build up the information necessary to create a file dependency. 
        //In this case we just need the file path of the file on disk. 
        List filePaths = new List(); 
        filePaths.Add("c:\\data.txt"); 

        //In the new cache API, dependencies are called "change monitors". 
        //For this example we want the cache entry to be automatically expired 
        //if the contents on disk change. A HostFileChangeMonitor provides 
        //this functionality. 
        policy.ChangeMonitors.Add(new HostFileChangeMonitor(filePaths)); 

        //Fetch the file's contents 
        fileContents = File.ReadAllText("c:\\data.txt"); 

        //And then store the file's contents in the cache 
        cache.Set("filecontents", fileContents, policy); 

    } 
    MessageBox.Show(fileContents); 
}

Codage d’en-têtes HTTP, d’URL et d’URL extensibles

Dans ASP.NET 4, vous pouvez créer des routines d’encodage personnalisées pour les tâches courantes d’encodage de texte suivantes :

Encodage HTML.
Encodage d’URL.
Encodage d’attribut HTML.
Encodage des en-têtes HTTP sortants.

Vous pouvez créer un encodeur personnalisé en dérivant du nouveau type System.Web.Util.HttpEncoder , puis en configurant ASP.NET pour utiliser le type personnalisé dans la section httpRuntime du Web.config fichier, comme illustré dans l’exemple suivant :

<httpRuntime encoderType="Samples.MyCustomEncoder, Samples" />

Une fois qu’un encodeur personnalisé a été configuré, ASP.NET appelle automatiquement l’implémentation d’encodage personnalisé chaque fois que des méthodes d’encodage publiques des classes System.Web.HttpUtility ou System.Web.HttpServerUtility sont appelées. Cela permet à une partie d’une équipe de développement web de créer un encodeur personnalisé qui implémente l’encodage de caractères agressif, tandis que le reste de l’équipe de développement web continue d’utiliser les API d’encodage ASP.NET publiques. En configurant de manière centralisée un encodeur personnalisé dans l’élément httpRuntime , vous êtes assuré que tous les appels d’encodage de texte provenant des API d’encodage publiques ASP.NET sont acheminés via l’encodeur personnalisé.

Analyse des performances pour des applications individuelles dans un processus de travail unique

Afin d’augmenter le nombre de sites Web pouvant être hébergés sur un seul serveur, de nombreux hôtes exécutent plusieurs applications ASP.NET dans un seul processus de travail. Toutefois, si plusieurs applications utilisent un seul processus de travail partagé, il est difficile pour les administrateurs de serveur d’identifier une application individuelle qui rencontre des problèmes.

ASP.NET 4 tire parti de la nouvelle fonctionnalité de surveillance des ressources introduite par le CLR. Pour activer cette fonctionnalité, vous pouvez ajouter l’extrait de code de configuration XML suivant au fichier de aspnet.config configuration.

<?xml version="1.0" encoding="UTF-8" ?> 
<configuration> 
  <runtime> 
    <appDomainResourceMonitoring enabled="true"/> 
  </runtime> 

</configuration>

Notes

Remarque Le aspnet.config fichier se trouve dans le répertoire où le .NET Framework est installé. Il ne s’agit pas du Web.config fichier.

Lorsque la fonctionnalité appDomainResourceMonitoring a été activée, deux nouveaux compteurs de performances sont disponibles dans la catégorie de performances « ASP.NET Applications » : % de temps processeur managé et mémoire managée utilisée. Ces deux compteurs de performances utilisent la nouvelle fonctionnalité de gestion des ressources de domaine d’application CLR pour suivre le temps processeur estimé et l’utilisation de la mémoire managée des applications ASP.NET individuelles. Par conséquent, avec ASP.NET 4, les administrateurs disposent désormais d’une vue plus précise de la consommation de ressources des applications individuelles s’exécutant dans un seul processus de travail.

Multi-ciblage

Vous pouvez créer une application qui cible une version spécifique du .NET Framework. Dans ASP.NET 4, un nouvel attribut dans l’élément de compilation du Web.config fichier vous permet de cibler .NET Framework 4 et versions ultérieures. Si vous ciblez explicitement le .NET Framework 4 et si vous incluez des éléments facultatifs dans le Web.config fichier, tels que les entrées pour system.codedom, ces éléments doivent être corrects pour .NET Framework 4. (Si vous ne ciblez pas explicitement le .NET Framework 4, l’infrastructure cible est déduite de l’absence d’entrée dans le Web.config fichier.)

L’exemple suivant montre l’utilisation de l’attribut targetFramework dans l’élément de compilation du Web.config fichier.

<compilation targetFramework="4.0"/>

Notez les points suivants concernant le ciblage d’une version spécifique du .NET Framework :

Dans un pool d’applications .NET Framework 4, le système de build ASP.NET suppose que .NET Framework 4 est une cible si le Web.config fichier n’inclut pas l’attribut targetFramework ou si le Web.config fichier est manquant. (Vous devrez peut-être apporter des modifications de codage à votre application pour qu’elle s’exécute sous .NET Framework 4.)
Si vous incluez l’attribut targetFramework et si l’élément system.codeDom est défini dans le Web.config fichier, ce fichier doit contenir les entrées correctes pour .NET Framework 4.
Si vous utilisez la commande aspnet_compiler pour précompiler votre application (par exemple dans un environnement de build), vous devez utiliser la version correcte de la commande aspnet_compiler pour l’infrastructure cible. Utilisez le compilateur fourni avec .NET Framework 2.0 (%WINDIR%\Microsoft.NET\Framework\v2.0.50727) pour compiler pour .NET Framework 3.5 et versions antérieures. Utilisez le compilateur fourni avec .NET Framework 4 pour compiler les applications créées à l’aide de ce framework ou à l’aide de versions ultérieures.
Au moment de l’exécution, le compilateur utilise les assemblys d’infrastructure les plus récents installés sur l’ordinateur (et donc dans le GAC). Si une mise à jour est effectuée ultérieurement dans l’infrastructure (par exemple, une hypothétique version 4.1 est installée), vous pourrez utiliser les fonctionnalités de la version la plus récente de l’infrastructure, même si l’attribut targetFramework cible une version inférieure (par exemple, 4.0). (Toutefois, au moment de la conception dans Visual Studio 2010 ou lorsque vous utilisez la commande aspnet_compiler , l’utilisation de fonctionnalités plus récentes de l’infrastructure entraîne des erreurs du compilateur).

Ajax

jQuery inclus avec Web Forms et MVC

Les modèles Visual Studio pour Web Forms et MVC incluent la bibliothèque jQuery open source. Lorsque vous créez un site web ou un projet, un dossier Scripts contenant les 3 fichiers suivants est créé :

jQuery-1.4.1.js : version lisible par l’homme et non déminifiée de la bibliothèque jQuery.
jQuery-14.1.min.js : version minifiée de la bibliothèque jQuery.
jQuery-1.4.1-vsdoc.js : fichier de documentation IntelliSense pour la bibliothèque jQuery.

Incluez la version nonminifiée de jQuery lors du développement d’une application. Incluez la version réduite de jQuery pour les applications de production.

Par exemple, la page de Web Forms suivante montre comment utiliser jQuery pour modifier la couleur d’arrière-plan des contrôles TextBox ASP.NET en jaune lorsqu’ils ont le focus.

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="ShowjQuery.aspx.cs" Inherits="ShowjQuery" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">
    <title>Show jQuery</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>

        <asp:TextBox ID="txtFirstName" runat="server" />
        <br />
        <asp:TextBox ID="txtLastName" runat="server" />
    </div>
    </form>
    <script src="Scripts/jquery-1.4.1.js" type="text/javascript"></script>

    <script type="text/javascript">
    
        $("input").focus( function() { $(this).css("background-color", "yellow"); });
    
    </script>
</body>
</html>

Prise en charge du réseau de distribution de contenu

Microsoft Ajax Content Delivery Network (CDN) vous permet d’ajouter facilement ASP.NET scripts Ajax et jQuery à vos applications web. Par exemple, vous pouvez commencer à utiliser la bibliothèque jQuery simplement en ajoutant une <script> balise à votre page qui pointe vers Ajax.microsoft.com comme suit :

<script src="https://ajax.aspnetcdn.com/ajax/jquery/jquery-1.4.2.js" type="text/javascript"></script>

En tirant parti du CDN Microsoft Ajax, vous pouvez améliorer considérablement la performance de vos applications Ajax. Le contenu du CDN Microsoft Ajax est mis en cache sur des serveurs situés dans le monde entier. En outre, le CDN Microsoft Ajax permet aux navigateurs de réutiliser des fichiers JavaScript mis en cache pour les sites Web qui se trouvent dans des domaines différents.

Le réseau de distribution de contenu Microsoft Ajax prend en charge SSL (HTTPS) au cas où vous deviez servir une page web à l’aide de la couche Secure Sockets Layer.

Implémentez un secours lorsque le CDN n’est pas disponible. Testez le secours.

Pour en savoir plus sur le CDN Microsoft Ajax, visitez le site web suivant :

https://www.asp.net/ajaxlibrary/CDN.ashx

Le ASP.NET ScriptManager prend en charge le CDN Microsoft Ajax. En définissant simplement une propriété, la propriété EnableCdn, vous pouvez récupérer tous les fichiers JavaScript de l’infrastructure ASP.NET à partir du CDN :

<asp:ScriptManager ID="sm1" EnableCdn="true" runat="server" />

Une fois que vous avez défini la propriété EnableCdn sur la valeur true, l’infrastructure ASP.NET récupère tous les fichiers JavaScript de l’infrastructure ASP.NET du CDN, y compris tous les fichiers JavaScript utilisés pour la validation et le UpdatePanel. La définition de cette propriété peut avoir un impact considérable sur les performances de votre application web.

Vous pouvez définir le chemin d’accès CDN pour vos propres fichiers JavaScript à l’aide de l’attribut WebResource. La nouvelle propriété CdnPath spécifie le chemin d’accès au CDN utilisé lorsque vous définissez la propriété EnableCdn sur la valeur true :

[assembly: WebResource("Foo.js", "application/x-javascript", CdnPath = "http://foo.com/foo/bar/foo.js")]

Scripts explicites ScriptManager

Dans le passé, si vous utilisiez le ASP.NET ScriptManger, vous deviez charger l’intégralité de la bibliothèque monolithique ASP.NET Ajax. En tirant parti de la nouvelle propriété ScriptManager.AjaxFrameworkMode, vous pouvez contrôler exactement quels composants de la bibliothèque Ajax ASP.NET sont chargés et charger uniquement les composants de la bibliothèque Ajax ASP.NET dont vous avez besoin.

La propriété ScriptManager.AjaxFrameworkMode peut être définie sur les valeurs suivantes :

Activé : spécifie que le contrôle ScriptManager inclut automatiquement le fichier de script MicrosoftAjax.js, qui est un fichier de script combiné de chaque script d’infrastructure principal (comportement hérité).
Désactivé : spécifie que toutes les fonctionnalités de script Microsoft Ajax sont désactivées et que le contrôle ScriptManager ne référence aucun script automatiquement.
Explicite : spécifie que vous allez inclure explicitement des références de script à un fichier de script de base d’infrastructure individuel requis par votre page, et que vous incluez des références aux dépendances requises par chaque fichier de script.

Par exemple, si vous définissez la propriété AjaxFrameworkMode sur la valeur Explicit, vous pouvez spécifier les scripts de composant Ajax ASP.NET spécifiques dont vous avez besoin :

<asp:ScriptManager ID="sm1" AjaxFrameworkMode="Explicit" runat="server">

<Scripts>
    <asp:ScriptReference Name="MicrosoftAjaxCore.js" />
    <asp:ScriptReference Name="MicrosoftAjaxComponentModel.js" />
    <asp:ScriptReference Name="MicrosoftAjaxSerialization.js" />
    <asp:ScriptReference Name="MicrosoftAjaxNetwork.js" />    
</Scripts>
</asp:ScriptManager>

Web Forms

Web Forms est une fonctionnalité de base dans ASP.NET depuis la publication de ASP.NET 1.0. De nombreuses améliorations ont été apportées à ce domaine pour ASP.NET 4, notamment les suivantes :

Possibilité de définir des balises meta .
Contrôle accru de l’état d’affichage.
Méthodes plus simples pour utiliser les fonctionnalités du navigateur.
Prise en charge de l’utilisation du routage ASP.NET avec Web Forms.
Plus de contrôle sur les ID générés.
Possibilité de conserver les lignes sélectionnées dans les contrôles de données.
Contrôle accru du code HTML rendu dans les contrôles FormView et ListView .
Prise en charge du filtrage pour les contrôles de source de données.

Définition des balises meta avec les propriétés Page.MetaKeywords et Page.MetaDescription

ASP.NET 4 ajoute deux propriétés à la classe Page , MetaKeywords et MetaDescription. Ces deux propriétés représentent les balises meta correspondantes dans votre page, comme illustré dans l’exemple suivant :

<head id="Head1" runat="server"> 
  <title>Untitled Page</title> 
  <meta name="keywords" content="These, are, my, keywords" /> 
  <meta name="description" content="This is the description of my page" /> 
</head>

Ces deux propriétés fonctionnent de la même façon que la propriété Title de la page. Ils suivent les règles suivantes :

S’il n’existe aucune balise meta dans l’élément head qui correspond aux noms des propriétés (c’est-à-dire, name="keywords » pour Page.MetaKeywords et name="description » pour Page.MetaDescription, ce qui signifie que ces propriétés n’ont pas été définies), les balises meta sont ajoutées à la page lorsqu’elle est rendue.
S’il existe déjà des balises meta portant ces noms, ces propriétés agissent comme des méthodes get et set pour le contenu des balises existantes.

Vous pouvez définir ces propriétés au moment de l’exécution, ce qui vous permet d’obtenir le contenu à partir d’une base de données ou d’une autre source, et qui vous permet de définir dynamiquement les balises pour décrire à quoi sert une page particulière.

Vous pouvez également définir les propriétés Mots clés et Description dans la directive @ Page en haut du balisage de page Web Forms, comme dans l’exemple suivant :

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeFile="Default.aspx.cs" 
  Inherits="_Default" 
  Keywords="These, are, my, keywords" 
  Description="This is a description" %>

Cela remplacera le contenu de balise meta (le cas échéant) déjà déclaré dans la page.

Le contenu de la balise meta description est utilisé pour améliorer les aperçus des listes de recherche dans Google. (Pour plus d’informations, consultez Améliorer les extraits de code avec une méta description sur le blog Google Webmaster Central.) Google et Windows Live Search n’utilisent pas le contenu des mots clés pour quoi que ce soit, mais d’autres moteurs de recherche peuvent le faire.

Ces nouvelles propriétés sont une fonctionnalité simple, mais elles vous évitent de devoir les ajouter manuellement ou d’écrire votre propre code pour créer les balises meta .

Activation de l’état d’affichage pour les contrôles individuels

Par défaut, l’état d’affichage est activé pour la page, de sorte que chaque contrôle de la page stocke potentiellement l’état d’affichage même s’il n’est pas requis pour l’application. Les données d’état d’affichage sont incluses dans le balisage généré par une page et augmentent le temps nécessaire pour envoyer une page au client et la publier. Le stockage d’un état d’affichage supérieur à celui nécessaire peut entraîner une dégradation significative des performances. Dans les versions antérieures de ASP.NET, les développeurs pouvaient désactiver l’état d’affichage des contrôles individuels afin de réduire la taille de la page, mais devaient le faire explicitement pour les contrôles individuels. Dans ASP.NET 4, les contrôles serveur web incluent une propriété ViewStateMode qui vous permet de désactiver l’état d’affichage par défaut, puis de l’activer uniquement pour les contrôles qui en ont besoin dans la page.

La propriété ViewStateMode prend une énumération qui a trois valeurs : Enabled, Disabled et Inherit. Activé active l’état d’affichage pour ce contrôle et pour tous les contrôles enfants qui sont définis sur Hériter ou qui n’ont rien de défini. Désactivé désactive l’état d’affichage et Hérite spécifie que le contrôle utilise le paramètre ViewStateMode du contrôle parent.

L’exemple suivant montre comment fonctionne la propriété ViewStateMode . Le balisage et le code des contrôles de la page suivante incluent des valeurs pour la propriété ViewStateMode :

<form id="form1" runat="server"> 
  <script runat="server"> 
      protected override void OnLoad(EventArgs e) { 
      if (!IsPostBack) { 
        label1.Text = label2.Text = "[DynamicValue]"; 
      } 
      base.OnLoad(e); 
    } 
  </script> 
  <asp:PlaceHolder ID="PlaceHolder1" runat="server" ViewStateMode="Disabled"> 
      Disabled: <asp:Label ID="label1" runat="server" Text="[DeclaredValue]" /><br /> 
    <asp:PlaceHolder ID="PlaceHolder2" runat="server" ViewStateMode="Enabled"> 
        Enabled: <asp:Label ID="label2" runat="server" Text="[DeclaredValue]" /> 
    </asp:PlaceHolder> 
  </asp:PlaceHolder> 
  <hr /> 
  <asp:button ID="Button1" runat="server" Text="Postback" /> 
  <%-- Further markup here --%>

Comme vous pouvez le voir, le code désactive l’état d’affichage pour le contrôle PlaceHolder1. Le contrôle enfant label1 hérite de cette valeur de propriété (Inherit est la valeur par défaut de ViewStateMode pour les contrôles.) et n’enregistre donc aucun état d’affichage. Dans le contrôle PlaceHolder2, ViewStateMode étant défini sur Enabled, label2 hérite de cette propriété et enregistre l’état d’affichage. Lorsque la page est chargée pour la première fois, la propriété Text des deux contrôles Label est définie sur la chaîne « [DynamicValue] ».

L’effet de ces paramètres est que lorsque la page se charge la première fois, la sortie suivante s’affiche dans le navigateur :

Handicapés : [DynamicValue]

Activé:[DynamicValue]

Toutefois, après une publication, la sortie suivante s’affiche :

Handicapés : [DeclaredValue]

Activé:[DynamicValue]

Le contrôle label1 (dont la valeur ViewStateMode est définie sur Disabled) n’a pas conservé la valeur sur laquelle il a été défini dans le code. Toutefois, le contrôle label2 (dont la valeur ViewStateMode est définie sur Enabled) a conservé son état.

Vous pouvez également définir ViewStateMode dans la directive @ Page , comme dans l’exemple suivant :

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeBehind="Default.aspx.cs" 
  Inherits="WebApplication1._Default" 
  ViewStateMode="Disabled" %>

La classe Page n’est qu’un autre contrôle ; il agit en tant que contrôle parent pour tous les autres contrôles de la page. La valeur par défaut de ViewStateMode est Enabled pour les instances de Page. Étant donné que la valeur par défaut des contrôles est Hériter, les contrôles héritent de la valeur de propriété Enabled , sauf si vous définissez ViewStateMode au niveau de la page ou du contrôle.

La valeur de la propriété ViewStateMode détermine si l’état d’affichage est conservé uniquement si la propriété EnableViewState a la valeur true. Si la propriété EnableViewState a la valeur false, l’état d’affichage n’est pas conservé même si ViewStateMode a la valeur Enabled.

Une bonne utilisation de cette fonctionnalité est avec les contrôles ContentPlaceHolder dans master pages, où vous pouvez définir ViewStateMode sur Désactivé pour la page master, puis l’activer individuellement pour les contrôles ContentPlaceHolder qui à leur tour contiennent des contrôles qui nécessitent l’état d’affichage.

Modifications apportées aux fonctionnalités du navigateur

ASP.NET détermine les fonctionnalités du navigateur qu’un utilisateur utilise pour parcourir votre site à l’aide d’une fonctionnalité appelée fonctionnalités de navigateur. Les fonctionnalités du navigateur sont représentées par l’objet HttpBrowserCapabilities (exposé par la propriété Request.Browser ). Par exemple, vous pouvez utiliser l’objet HttpBrowserCapabilities pour déterminer si le type et la version du navigateur actuel prennent en charge une version particulière de JavaScript. Vous pouvez également utiliser l’objet HttpBrowserCapabilities pour déterminer si la demande provient d’un appareil mobile.

L’objet HttpBrowserCapabilities est piloté par un ensemble de fichiers de définition de navigateur. Ces fichiers contiennent des informations sur les fonctionnalités de navigateurs particuliers. Dans ASP.NET 4, ces fichiers de définition de navigateur ont été mis à jour pour contenir des informations sur les navigateurs et les appareils récemment introduits tels que Google Chrome, research in Motion BlackBerry smartphones et Apple iPhone.

La liste suivante présente les nouveaux fichiers de définition de navigateur :

blackberry.browser
chrome.browser
Default.browser
firefox.browser
gateway.browser
generic.browser
ie.browser
iemobile.browser
iphone.browser
opera.browser
safari.browser

Utilisation des fournisseurs de fonctionnalités de navigateur

Dans ASP.NET version 3.5 Service Pack 1, vous pouvez définir les fonctionnalités d’un navigateur des manières suivantes :

Au niveau de l’ordinateur, vous créez ou mettez à jour un .browser fichier XML dans le dossier suivant :

\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

Après avoir défini la fonctionnalité de navigateur, exécutez la commande suivante à partir de l’invite de commandes Visual Studio afin de reconstruire l’assembly des fonctionnalités du navigateur et de l’ajouter au GAC :
```
aspnet_regbrowsers.exe -I c
```
Pour une application individuelle, vous créez un .browser fichier dans le dossier de l’application App_Browsers .

Ces approches vous obligent à modifier les fichiers XML et, pour les modifications au niveau de l’ordinateur, vous devez redémarrer l’application après avoir exécuté le processus de aspnet_regbrowsers.exe.

ASP.NET 4 inclut une fonctionnalité appelée fournisseurs de fonctionnalités de navigateur. Comme son nom l’indique, cela vous permet de créer un fournisseur qui, à son tour, vous permet d’utiliser votre propre code pour déterminer les fonctionnalités du navigateur.

Dans la pratique, les développeurs ne définissent souvent pas de fonctionnalités de navigateur personnalisées. Les fichiers du navigateur sont difficiles à mettre à jour, le processus de mise à jour est assez compliqué et la syntaxe XML des .browser fichiers peut être complexe à utiliser et à définir. Ce qui faciliterait considérablement ce processus, c’est s’il existait une syntaxe de définition de navigateur commune, ou une base de données contenant des définitions de navigateur à jour, ou même un service Web pour une telle base de données. La nouvelle fonctionnalité des fournisseurs de fonctionnalités de navigateur rend ces scénarios possibles et pratiques pour les développeurs tiers.

Il existe deux approches main pour utiliser la nouvelle fonctionnalité de fournisseur de fonctionnalités de navigateur ASP.NET 4 : l’extension de la fonctionnalité de définition des fonctionnalités de navigateur ASP.NET ou son remplacement total. Les sections suivantes décrivent d’abord comment remplacer la fonctionnalité, puis comment l’étendre.

Remplacement de la fonctionnalité des fonctionnalités du navigateur ASP.NET

Pour remplacer complètement la fonctionnalité de définition des fonctionnalités du navigateur ASP.NET, procédez comme suit :

Créez une classe de fournisseur qui dérive de HttpCapabilitiesProvider et remplace la méthode GetBrowserCapabilities , comme dans l’exemple suivant :

public class CustomProvider : HttpCapabilitiesProvider 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities(); 
        Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase); 
        values[String.Empty] = request.UserAgent; 
        values["browser"] = "MyCustomBrowser"; 
        browserCaps.Capabilities = values; 
        return browserCaps;
    } 
}

Le code de cet exemple crée un objet HttpBrowserCapabilities , en spécifiant uniquement la fonctionnalité nommée browser et en définissant cette fonctionnalité sur MyCustomBrowser.

Inscrivez le fournisseur auprès de l’application.

Pour utiliser un fournisseur avec une application, vous devez ajouter l’attribut provider à la section browserCaps dans les Web.config fichiers ou Machine.config . (Vous pouvez également définir les attributs du fournisseur dans un élément location pour des répertoires spécifiques dans l’application, par exemple dans un dossier pour un appareil mobile spécifique.) L’exemple suivant montre comment définir l’attribut provider dans un fichier de configuration :
```
<system.web> 
<browserCaps provider="ClassLibrary2.CustomProvider, ClassLibrary2, 
  Version=1.0.0.0, Culture=neutral" /> 
</system.web>
```
Une autre façon d’inscrire la nouvelle définition de fonctionnalité de navigateur consiste à utiliser du code, comme illustré dans l’exemple suivant :
```
void Application_Start(object sender, EventArgs e) 
{ 
    HttpCapabilitiesBase.BrowserCapabilitiesProvider =
    new ClassLibrary2.CustomProvider();
    // ... 
 }
```
Ce code doit s’exécuter dans l’événement Application_Start du Global.asax fichier. Toute modification apportée à la classe BrowserCapabilitiesProvider doit se produire avant l’exécution d’un code dans l’application, afin de s’assurer que le cache reste dans un état valide pour l’objet HttpCapabilitiesBase résolu.

Mise en cache de l’objet HttpBrowserCapabilities

L’exemple précédent présente un problème : le code s’exécute chaque fois que le fournisseur personnalisé est appelé afin d’obtenir l’objet HttpBrowserCapabilities . Cela peut se produire plusieurs fois au cours de chaque requête. Dans l’exemple, le code du fournisseur ne fait pas grand-chose. Toutefois, si le code de votre fournisseur personnalisé effectue un travail important pour obtenir l’objet HttpBrowserCapabilities , cela peut affecter les performances. Pour éviter cela, vous pouvez mettre en cache l’objet HttpBrowserCapabilities . Procédez comme suit :

Créez une classe qui dérive de HttpCapabilitiesProvider, comme celle de l’exemple suivant :

public class CustomProvider : HttpCapabilitiesProvider 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        string cacheKey = BuildCacheKey(); 
        int cacheTime = GetCacheTime(); 
        HttpBrowserCapabilities browserCaps = 
        HttpContext.Current.Cache[cacheKey] as 
        HttpBrowserCapabilities; 
        if (browserCaps == null) 
        { 
            HttpBrowserCapabilities browserCaps = new 
            HttpBrowserCapabilities(); 
            Hashtable values = new Hashtable(180, 
            StringComparer.OrdinalIgnoreCase); 
            values[String.Empty] = request.UserAgent; 
            values["browser"] = "MyCustomBrowser"; 
            browserCaps.Capabilities = values; 
            HttpContext.Current.Cache.Insert(cacheKey, 
            browserCaps, null, DateTime.MaxValue, 
            TimeSpan.FromSeconds(cacheTime));
        } 
        return browserCaps; 
    } 
}

Dans l’exemple, le code génère une clé de cache en appelant une méthode BuildCacheKey personnalisée et obtient la durée de mise en cache en appelant une méthode GetCacheTime personnalisée. Le code ajoute ensuite l’objet HttpBrowserCapabilities résolu au cache. L’objet peut être récupéré à partir du cache et réutilisé sur les demandes suivantes qui utilisent le fournisseur personnalisé.

Inscrivez le fournisseur auprès de l’application comme décrit dans la procédure précédente.

Extension des fonctionnalités du navigateur ASP.NET

La section précédente a décrit comment créer un objet HttpBrowserCapabilities dans ASP.NET 4. Vous pouvez également étendre la fonctionnalité des fonctionnalités de navigateur ASP.NET en ajoutant de nouvelles définitions de fonctionnalités de navigateur à celles qui sont déjà dans ASP.NET. Vous pouvez le faire sans utiliser les définitions de navigateur XML. La procédure suivante montre comment procéder.

Créez une classe qui dérive de HttpCapabilitiesEvaluator et remplace la méthode GetBrowserCapabilities , comme illustré dans l’exemple suivant :
```
public class CustomProvider : HttpCapabilitiesEvaluator 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        HttpBrowserCapabilities browserCaps = 
        base.GetHttpBrowserCapabilities(request);
        if (browserCaps.Browser == "Unknown") 
        { 
            browserCaps = MyBrowserCapabilitiesEvaulator(request); 
        } 
        return browserCaps; 
    } 
}
```
Ce code utilise d’abord la fonctionnalité des fonctionnalités de navigateur ASP.NET pour essayer d’identifier le navigateur. Toutefois, si aucun navigateur n’est identifié en fonction des informations définies dans la requête (autrement dit, si la propriété Browser de l’objet HttpBrowserCapabilities est la chaîne « Unknown »), le code appelle le fournisseur personnalisé (MyBrowserCapabilitiesEvaluator) pour identifier le navigateur.
Inscrivez le fournisseur auprès de l’application comme décrit dans l’exemple précédent.

Extension des fonctionnalités des fonctionnalités du navigateur en ajoutant de nouvelles fonctionnalités aux définitions de fonctionnalités existantes

En plus de créer un fournisseur de définition de navigateur personnalisé et de créer dynamiquement de nouvelles définitions de navigateur, vous pouvez étendre les définitions de navigateur existantes avec des fonctionnalités supplémentaires. Cela vous permet d’utiliser une définition proche de ce que vous voulez, mais qui n’a que quelques fonctionnalités. Pour ce faire, effectuez les étapes suivantes.

Créez une classe qui dérive de HttpCapabilitiesEvaluator et remplace la méthode GetBrowserCapabilities , comme illustré dans l’exemple suivant :
```
public class CustomProvider : HttpCapabilitiesEvaluator 
{ 
    public override HttpBrowserCapabilities 
    GetBrowserCapabilities(HttpRequest request) 
    { 
        HttpBrowserCapabilities browserCaps = 
          base.GetHttpBrowserCapabilities(request); 
        if (browserCaps.Browser == "Unknown") 
        { 
            browserCaps = MyBrowserCapabilitiesEvaulator(request); 
        } 
        return browserCaps; 
    }
}
```
L’exemple de code étend la classe ASP.NET HttpCapabilitiesEvaluator existante et obtient l’objet HttpBrowserCapabilities qui correspond à la définition de requête actuelle à l’aide du code suivant :
```
HttpBrowserCapabilities browserCaps = 
    base.GetHttpBrowserCapabilities(request);
```
Le code peut ensuite ajouter ou modifier une fonctionnalité pour ce navigateur. Il existe deux façons de spécifier une nouvelle fonctionnalité de navigateur :
- Ajoutez une paire clé/valeur à l’objet IDictionary exposé par la propriété Capabilities de l’objet HttpCapabilitiesBase . Dans l’exemple précédent, le code ajoute une fonctionnalité nommée MultiTouch avec la valeur true.
- Définissez les propriétés existantes de l’objet HttpCapabilitiesBase . Dans l’exemple précédent, le code définit la propriété Frames sur true. Cette propriété est simplement un accesseur pour l’objet IDictionary exposé par la propriété Capabilities .
  
  Notes
  
  Remarque Ce modèle s’applique à n’importe quelle propriété de HttpBrowserCapabilities, y compris les adaptateurs de contrôle.
Inscrivez le fournisseur auprès de l’application comme décrit dans la procédure précédente.

Routage dans ASP.NET 4

ASP.NET 4 ajoute la prise en charge intégrée de l’utilisation du routage avec Web Forms. Le routage vous permet de configurer une application pour accepter les URL de requête qui ne sont pas mappées à des fichiers physiques. Au lieu de cela, vous pouvez utiliser le routage pour définir des URL significatives pour les utilisateurs et qui peuvent faciliter l’optimisation des moteurs de recherche (SEO) pour votre application. Par exemple, l’URL d’une page qui affiche des catégories de produits dans une application existante peut ressembler à l’exemple suivant :

http://website/products.aspx?categoryid=12

En utilisant le routage, vous pouvez configurer l’application pour qu’elle accepte l’URL suivante pour afficher les mêmes informations :

http://website/products/software

Le routage a été disponible depuis ASP.NET 3.5 SP1. (Pour obtenir un exemple d’utilisation du routage dans ASP.NET 3.5 SP1, consultez l’entrée Utilisation du routage avec WebForms sur le blog de Phil Haack.) Toutefois, ASP.NET 4 inclut certaines fonctionnalités qui facilitent l’utilisation du routage, notamment les suivantes :

Classe PageRouteHandler , qui est un gestionnaire HTTP simple que vous utilisez lorsque vous définissez des itinéraires. La classe transmet les données à la page vers laquelle la requête est acheminée.
Les nouvelles propriétés HttpRequest.RequestContext et Page.RouteData (qui est un proxy pour l’objet HttpRequest.RequestContext.RouteData ). Ces propriétés facilitent l’accès aux informations transmises à partir de l’itinéraire.
Les nouveaux générateurs d’expressions suivants, qui sont définis dans System.Web.Compilation.RouteUrlExpressionBuilder et System.Web.Compilation.RouteValueExpressionBuilder :
RouteUrl, qui fournit un moyen simple de créer une URL qui correspond à une URL d’itinéraire dans un contrôle serveur ASP.NET.
RouteValue, qui fournit un moyen simple d’extraire des informations de l’objet RouteContext .
Classe RouteParameter , qui facilite la transmission des données contenues dans un objet RouteContext à une requête pour un contrôle de source de données (similaire à FormParameter).

Routage des pages Web Forms

L’exemple suivant montre comment définir un itinéraire Web Forms à l’aide de la nouvelle méthode MapPageRoute de la classe Route :

public class Global : System.Web.HttpApplication 
{ 
    void Application_Start(object sender, EventArgs e) 
    { 
        RouteTable.Routes.MapPageRoute("SearchRoute", 
          "search/{searchterm}", "~/search.aspx"); 
        RouteTable.Routes.MapPageRoute("UserRoute", 
          "users/{username}", "~/users.aspx"); 
    } 
}

ASP.NET 4 introduit la méthode MapPageRoute . L’exemple suivant est équivalent à la définition SearchRoute indiquée dans l’exemple précédent, mais utilise la classe PageRouteHandler .

RouteTable.Routes.Add("SearchRoute", new Route("search/{searchterm}", 
  new PageRouteHandler("~/search.aspx")));

Le code de l’exemple mappe l’itinéraire à une page physique (dans la première route, à ~/search.aspx). La première définition de route spécifie également que le paramètre nommé searchterm doit être extrait de l’URL et passé à la page.

La méthode MapPageRoute prend en charge les surcharges de méthode suivantes :

MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess)
MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary defaults)
MapPageRoute(string routeName, string routeUrl, string physicalFile, bool checkPhysicalUrlAccess, RouteValueDictionary defaults, RouteValueDictionary constraints)

Le paramètre checkPhysicalUrlAccess spécifie si la route doit case activée les autorisations de sécurité pour la page physique acheminée vers (dans ce cas, search.aspx) et les autorisations sur l’URL entrante (dans ce cas, search/{searchterm}). Si la valeur de checkPhysicalUrlAccess est false, seules les autorisations de l’URL entrante sont vérifiées. Ces autorisations sont définies dans le fichier à l’aide Web.config de paramètres tels que les suivants :

<configuration> 
  <location path="search.aspx"> 
    <system.web> 
      <authorization> 
        <allow roles="admin"/> 
        <deny users="*"/> 
      </authorization> 
    </system.web> 
  </location> 
  <location path="search"> 
    <system.web> 
      <authorization> 
        <allow users="*"/> 
      </authorization> 
    </system.web> 
  </location> 

</configuration>

Dans l’exemple de configuration, l’accès à la page search.aspx physique est refusé pour tous les utilisateurs, à l’exception de ceux qui sont dans le rôle d’administrateur. Lorsque le paramètre checkPhysicalUrlAccess a la valeur true (qui est sa valeur par défaut), seuls les utilisateurs administrateurs sont autorisés à accéder à l’URL /search/{searchterm}, car la page physique search.aspx est limitée aux utilisateurs de ce rôle. Si checkPhysicalUrlAccess a la valeur false et que le site est configuré comme indiqué dans l’exemple précédent, tous les utilisateurs authentifiés sont autorisés à accéder à l’URL /search/{searchterm}.

Lecture des informations de routage dans une page de Web Forms

Dans le code de la page physique Web Forms, vous pouvez accéder aux informations que le routage a extraites de l’URL (ou à d’autres informations qu’un autre objet a ajoutées à l’objet RouteData) à l’aide de deux nouvelles propriétés : HttpRequest.RequestContext et Page.RouteData. (Page.RouteData encapsule HttpRequest.RequestContext.RouteData.) L’exemple suivant montre comment utiliser Page.RouteData.

protected void Page_Load(object sender, EventArgs e) 
{ 
    string searchterm = Page.RouteData.Values["searchterm"] as string; 
    label1.Text = searchterm; 
}

Le code extrait la valeur qui a été passée pour le paramètre searchterm, comme défini dans l’exemple de route précédemment. Considérez l’URL de requête suivante :

http://localhost/search/scott/

Lorsque cette demande est effectuée, le mot « scott » est affiché dans la search.aspx page.

Accès aux informations de routage dans le balisage

La méthode décrite dans la section précédente montre comment obtenir des données de routage dans le code dans une page de Web Forms. Vous pouvez également utiliser des expressions dans le balisage qui vous donnent accès aux mêmes informations. Les générateurs d’expressions sont un moyen puissant et élégant d’utiliser du code déclaratif. (Pour plus d’informations, consultez l’entrée Express Yourself With Custom Expression Builders sur le blog de Phil Haack.)

ASP.NET 4 inclut deux nouveaux générateurs d’expressions pour le routage Web Forms. L’exemple suivant montre comment les utiliser.

<asp:HyperLink ID="HyperLink1" runat="server" 
  NavigateUrl="<%$RouteUrl:SearchTerm=scott%>">Search for Scott</asp:HyperLink>

Dans l’exemple, l’expression RouteUrl est utilisée pour définir une URL basée sur un paramètre de route. Cela vous évite d’avoir à coder en dur l’URL complète dans le balisage et vous permet de modifier la structure d’URL ultérieurement sans nécessiter de modification de ce lien.

En fonction de l’itinéraire défini précédemment, ce balisage génère l’URL suivante :

http://localhost/search/scott

ASP.NET détermine automatiquement l’itinéraire correct (c’est-à-dire, il génère l’URL correcte) en fonction des paramètres d’entrée. Vous pouvez également inclure un nom de route dans l’expression, ce qui vous permet de spécifier un itinéraire à utiliser.

L’exemple suivant montre comment utiliser l’expression RouteValue .

<asp:Label ID="Label1" runat="server" Text="<%$RouteValue:SearchTerm%>" />

Lorsque la page qui contient ce contrôle s’exécute, la valeur « scott » s’affiche dans l’étiquette.

L’expression RouteValue simplifie l’utilisation des données de routage dans le balisage et évite d’avoir à utiliser la syntaxe Page.RouteData["x"] plus complexe dans le balisage.

Utilisation des données de routage pour les paramètres de contrôle de source de données

La classe RouteParameter vous permet de spécifier les données de routage comme valeur de paramètre pour les requêtes dans un contrôle de source de données. Il fonctionne de la même manière que la classe, comme illustré dans l’exemple suivant :

<asp:sqldatasource id="SqlDataSource1" runat="server" 
    connectionstring="<%$ ConnectionStrings:MyNorthwind %>" 
    selectcommand="SELECT CompanyName,ShipperID FROM Shippers where 
      CompanyName=@companyname" 
  <selectparameters> 
    <asp:routeparameter name="companyname" RouteKey="searchterm" /> 
  </selectparameters> 

</asp:sqldatasource>

Dans ce cas, la valeur du paramètre d’itinéraire searchterm sera utilisée pour le @companyname paramètre dans l’instruction Select .

Définition des ID client

La nouvelle propriété ClientIDMode résout un problème de longue date dans ASP.NET, à savoir la façon dont les contrôles créent l’attribut id pour les éléments qu’ils affichent. Il est important de connaître l’attribut id pour les éléments rendus si votre application inclut un script client qui référence ces éléments.

L’attribut id en HTML qui est rendu pour les contrôles serveur web est généré en fonction de la propriété ClientID du contrôle. Jusqu’à ASP.NET 4, l’algorithme de génération de l’attribut id à partir de la propriété ClientID a consisté à concaténer le conteneur de noms (le cas échéant) avec l’ID et, dans le cas de contrôles répétés (comme dans les contrôles de données), à ajouter un préfixe et un nombre séquentiel. Bien que cela ait toujours garanti que les ID des contrôles de la page sont uniques, l’algorithme a donné lieu à des ID de contrôle qui n’étaient pas prévisibles et qui étaient donc difficiles à référencer dans le script client.

La nouvelle propriété ClientIDMode vous permet de spécifier plus précisément la façon dont l’ID client est généré pour les contrôles. Vous pouvez définir la propriété ClientIDMode pour n’importe quel contrôle, y compris pour la page. Les paramètres possibles sont les suivants :

AutoID : cela équivaut à l’algorithme de génération des valeurs de propriété ClientID qui a été utilisé dans les versions antérieures de ASP.NET.
Statique : spécifie que la valeur ClientID sera identique à l’ID sans concaténer les ID des conteneurs de nommage parents. Cela peut être utile dans les contrôles utilisateur web. Étant donné qu’un contrôle utilisateur web peut se trouver sur différentes pages et dans différents contrôles de conteneur, il peut être difficile d’écrire un script client pour les contrôles qui utilisent l’algorithme AutoID , car vous ne pouvez pas prédire quelles seront les valeurs d’ID.
Prévisible : cette option est principalement destinée aux contrôles de données qui utilisent des modèles répétitifs. Il concatène les propriétés d’ID des conteneurs de nommage du contrôle, mais les valeurs ClientID générées ne contiennent pas de chaînes telles que « ctlxxx ». Ce paramètre fonctionne conjointement avec la propriété ClientIDRowSuffix du contrôle. Vous définissez la propriété ClientIDRowSuffix sur le nom d’un champ de données et la valeur de ce champ est utilisée comme suffixe pour la valeur ClientID générée. En règle générale, vous utilisez la clé primaire d’un enregistrement de données comme valeur ClientIDRowSuffix .
Hériter : ce paramètre est le comportement par défaut des contrôles ; il spécifie que la génération d’ID d’un contrôle est identique à son parent.

Vous pouvez définir la propriété ClientIDMode au niveau de la page. Cela définit la valeur ClientIDMode par défaut pour tous les contrôles de la page active.

La valeur ClientIDMode par défaut au niveau de la page est AutoID et la valeur ClientIDMode par défaut au niveau du contrôle est Hériter. Par conséquent, si vous ne définissez cette propriété nulle part dans votre code, tous les contrôles seront définis par défaut sur l’algorithme AutoID .

Vous définissez la valeur au niveau de la page dans la directive @ Page , comme illustré dans l’exemple suivant :

<%@ Page Language="C#" AutoEventWireup="true" 
  CodeFile="Default.aspx.cs" 
  Inherits="_Default" 
  ClientIDMode="Predictable" %>

Vous pouvez également définir la valeur ClientIDMode dans le fichier de configuration, soit au niveau de l’ordinateur (ordinateur) soit au niveau de l’application. Cela définit le paramètre ClientIDMode par défaut pour tous les contrôles de toutes les pages de l’application. Si vous définissez la valeur au niveau de l’ordinateur, il définit le paramètre ClientIDMode par défaut pour tous les sites Web sur cet ordinateur. L’exemple suivant montre le paramètre ClientIDMode dans le fichier de configuration :

<system.web> 
  <pages clientIDMode="Predictable"></pages> 
</system.web>

Comme indiqué précédemment, la valeur de la propriété ClientID est dérivée du conteneur de nommage du parent d’un contrôle. Dans certains scénarios, par exemple lorsque vous utilisez master pages, les contrôles peuvent se retrouver avec des ID comme ceux dans le code HTML affiché suivant :

<div id="ctl00_ContentPlaceHolder1_ParentPanel"> 
  <div id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1"> 
    <input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1" 
      type="text" value="Hello!" 
      id="ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1" /> 
</div>

Bien que l’élément d’entrée indiqué dans le balisage (à partir d’un contrôle TextBox) ne soit que deux conteneurs de nommage en profondeur dans la page (les contrôles ContentPlaceholder imbriqués), en raison de la façon dont master pages sont traitées, le résultat final est un ID de contrôle semblable à ce qui suit :

ctl00_ContentPlaceHolder1_ParentPanel_NamingPanel1_TextBox1

Cet ID est garanti pour être unique dans la page, mais est inutilement long pour la plupart des fins. Imaginez que vous souhaitez réduire la longueur de l’ID rendu et avoir plus de contrôle sur la façon dont l’ID est généré. (Par exemple, vous souhaitez éliminer les préfixes « ctlxxx ». Le moyen le plus simple d’y parvenir consiste à définir la propriété ClientIDMode comme illustré dans l’exemple suivant :

<tc:NamingPanel runat="server" ID="ParentPanel" ClientIDMode="Static"> 
  <tc:NamingPanel runat="server" ID="NamingPanel1" ClientIDMode="Predictable"> 
    <asp:TextBox ID="TextBox1" runat="server" Text="Hello!"></asp:TextBox> 
  </tc:NamingPanel> 

</tc:NamingPanel>

Dans cet exemple, la propriété ClientIDMode est définie sur Static pour l’élément NamingPanel le plus externe et définie sur Prédictible pour l’élément NamingControl interne. Ces paramètres entraînent le balisage suivant (le reste de la page et la page master sont supposés être identiques à ceux de l’exemple précédent) :

<div id="ParentPanel"> 
  <div id="ParentPanel_NamingPanel1"> 
    <input name="ctl00$ContentPlaceHolder1$ParentPanel$NamingPanel1$TextBox1" 
        type="text" value="Hello!" id="ParentPanel_NamingPanel1_TextBox1" /> 
</div>

Le paramètre Static a pour effet de réinitialiser la hiérarchie de noms pour tous les contrôles à l’intérieur de l’élément NamingPanel le plus externe et d’éliminer les ID ContentPlaceHolder et MasterPage de l’ID généré. (L’attribut name des éléments rendus n’étant pas affecté, la fonctionnalité de ASP.NET normale est conservée pour les événements, l’état d’affichage, etc.) La réinitialisation de la hiérarchie de noms a pour effet secondaire que même si vous déplacez le balisage des éléments NamingPanel vers un autre contrôle ContentPlaceholder , les ID client rendus restent les mêmes.

Notes

Remarque Il vous appartient de vous assurer que les ID de contrôle rendus sont uniques. Si ce n’est pas le cas, elle peut interrompre toutes les fonctionnalités qui nécessitent des ID uniques pour des éléments HTML individuels, comme la fonction client document.getElementById .

Création d’ID client prévisibles dans les contrôles Data-Bound

Les valeurs ClientID générées pour les contrôles dans un contrôle de liste liée aux données par l’algorithme hérité peuvent être longues et ne sont pas vraiment prévisibles. La fonctionnalité ClientIDMode peut vous aider à mieux contrôler la façon dont ces ID sont générés.

Le balisage de l’exemple suivant inclut un contrôle ListView :

<asp:ListView ID="ListView1" runat="server" DataSourceID="SqlDataSource1" 
    OnSelectedIndexChanged="ListView1_SelectedIndexChanged" 
    ClientIDMode="Predictable" 
    RowClientIDRowSuffix="ProductID"> 
</asp:ListView>

Dans l’exemple précédent, les propriétés ClientIDMode et RowClientIDRowSuffix sont définies dans le balisage. La propriété ClientIDRowSuffix ne peut être utilisée que dans les contrôles liés aux données, et son comportement diffère selon le contrôle que vous utilisez. Les différences sont les suivantes :

Contrôle GridView : vous pouvez spécifier le nom d’une ou plusieurs colonnes dans la source de données, qui sont combinées au moment de l’exécution pour créer les ID client. Par exemple, si vous définissez RowClientIDRowSuffix sur « ProductName, ProductId », les ID de contrôle pour les éléments rendus auront un format semblable à ce qui suit :

rootPanel_GridView1_ProductNameLabel_Chai_1

Contrôle ListView : vous pouvez spécifier une colonne unique dans la source de données qui est ajoutée à l’ID client. Par exemple, si vous définissez ClientIDRowSuffix sur « ProductName », les ID de contrôle rendus auront un format semblable à ce qui suit :
```
rootPanel_ListView1_ProductNameLabel_1
```
Dans ce cas, la fin 1 est dérivée de l’ID de produit de l’élément de données actuel.
Contrôle répéteur : ce contrôle ne prend pas en charge la propriété ClientIDRowSuffix . Dans un contrôle Repeater , l’index de la ligne actuelle est utilisé. Lorsque vous utilisez ClientIDMode="Prédictible » avec un contrôle Repeater , les ID client sont générés au format suivant :
```
Repeater1_ProductNameLabel_0
```
La fin 0 est l’index de la ligne active.

Les contrôles FormView et DetailsView n’affichent pas plusieurs lignes, ils ne prennent donc pas en charge la propriété ClientIDRowSuffix .

Persistance de la sélection de lignes dans les contrôles de données

Les contrôles GridView et ListView peuvent permettre aux utilisateurs de sélectionner une ligne. Dans les versions précédentes de ASP.NET, la sélection a été basée sur l’index de ligne de la page. Par exemple, si vous sélectionnez le troisième élément de la page 1, puis passez à la page 2, le troisième élément de cette page est sélectionné.

La sélection persistante était initialement prise en charge uniquement dans les projets de données dynamiques dans .NET Framework 3.5 SP1. Lorsque cette fonctionnalité est activée, l’élément sélectionné actuel est basé sur la clé de données de l’élément. Cela signifie que si vous sélectionnez la troisième ligne de la page 1 et passez à la page 2, rien n’est sélectionné à la page 2. Lorsque vous revenez à la page 1, la troisième ligne est toujours sélectionnée. La sélection persistante est désormais prise en charge pour les contrôles GridView et ListView dans tous les projets à l’aide de la propriété EnablePersistedSelection , comme illustré dans l’exemple suivant :

<asp:GridView id="GridView2" runat="server" EnablePersistedSelection="true"> 
</asp:GridView>

contrôle graphique ASP.NET

Le contrôle graphique ASP.NET étend les offres de visualisation des données dans .NET Framework. À l’aide du contrôle Graphique , vous pouvez créer des pages ASP.NET qui ont des graphiques intuitifs et visuellement attrayants pour une analyse statistique ou financière complexe. Le contrôle graphique ASP.NET a été introduit en tant que complément de la version 3.5 SP1 de .NET Framework et fait partie de la version .NET Framework 4.

Le contrôle comprend les fonctionnalités suivantes :

35 types de graphiques distincts.
Nombre illimité de zones de graphique, de titres, de légendes et d’annotations.
Une grande variété de paramètres d’apparence pour tous les éléments de graphique.
Prise en charge 3D pour la plupart des types de graphiques.
Étiquettes de données intelligentes qui peuvent s’adapter automatiquement aux points de données.
Bandes de lignes, sauts d’échelle et mise à l’échelle logarithmique.
Plus de 50 formules financières et statistiques pour l'analyse et la transformation de données.
Liaison et manipulation simples des données de graphique.
Prise en charge des formats de données courants tels que les dates, les heures et les devises.
Prise en charge de l’interactivité et de la personnalisation pilotée par les événements, y compris les événements de clic du client à l’aide d’Ajax.
Gestion d'état.
Flux binaires.

Les figures suivantes illustrent des exemples de graphiques financiers générés par le contrôle graphique ASP.NET.

Quatre exemples de graphiques financiers produits par le contrôle graphique ASP.NET.

Figure 2 : exemples de contrôle graphique ASP.NET

Pour obtenir d’autres exemples d’utilisation du contrôle Graphique ASP.NET, téléchargez l’exemple de code dans la page Exemples d’environnement pour les contrôles Microsoft Chart sur le site Web MSDN. Vous trouverez d’autres exemples de contenu de la communauté sur le Forum de contrôle des graphiques.

Ajout du contrôle graphique à une page ASP.NET

L’exemple suivant montre comment ajouter un contrôle Graphique à une page ASP.NET à l’aide du balisage. Dans l’exemple, le contrôle Graphique produit un histogramme pour les points de données statiques.

<asp:Chart ID="Chart1" runat="server"> 
  <Series> 
    <asp:Series Name="Series1" ChartType="Column"> 
      <Points> 
        <asp:DataPoint AxisLabel="Product A" YValues="345"/> 
        <asp:DataPoint AxisLabel="Product B" YValues="456"/> 
        <asp:DataPoint AxisLabel="Product C" YValues="125"/> 
        <asp:DataPoint AxisLabel="Product D" YValues="957"/> &

      lt;/Points> 
    </asp:Series> 
  </Series> 
  <ChartAreas> 
    <asp:ChartArea Name="ChartArea1"> 
      <AxisY IsLogarithmic="True" /> 
    </asp:ChartArea> 
  </ChartAreas> 
  <Legends> 
    <asp:Legend Name="Legend1" Title="Product Sales" /> 
  </Legends> 

</asp:Chart>

Utilisation de graphiques 3D

Le contrôle Chart contient une collection ChartAreas , qui peut contenir des objets ChartArea qui définissent les caractéristiques des zones de graphique. Par exemple, pour utiliser 3D pour une zone de graphique, utilisez la propriété Area3DStyle comme dans l’exemple suivant :

<asp:ChartArea Name="ChartArea1"> 
  <area3dstyle 
      Rotation="10" 
      Perspective="10" 
      Enable3D="True" 
      Inclination="15" 
      IsRightAngleAxes="False" 
      WallWidth="0" 
      IsClustered="False" /> 
      
  <%-- Additional markup here --%> 
</asp:ChartArea>

La figure ci-dessous montre un graphique 3D avec quatre séries du type graphique à barres .

Graphique à barres 3 dimensions montrant quatre séries du type de graphique à barres.

Figure 3 : Graphique à barres 3D

Utilisation des sauts d’échelle et des échelles logarithmiques

Les sauts d’échelle et les échelles logarithmiques sont deux façons supplémentaires d’ajouter de la sophistication au graphique. Ces fonctionnalités sont spécifiques à chaque axe d’une zone de graphique. Par exemple, pour utiliser ces fonctionnalités sur l’axe Y principal d’une zone de graphique, utilisez les propriétés AxisY.IsLogarithmic et ScaleBreakStyle dans un objet ChartArea . L’extrait de code suivant montre comment utiliser des sauts d’échelle sur l’axe Y principal.

<asp:ChartArea Name="ChartArea1">

  <axisy>

    <ScaleBreakStyle 
        BreakLineStyle="Wave" 
        CollapsibleSpaceThreshold="40" 
        Enabled="True" />
  </axisy>

<%-- Additional markup here --%>
</asp:ChartArea>

La figure ci-dessous montre l’axe Y avec les sauts d’échelle activés.

Graphique à barres qui montre l’axe Y avec les sauts d’échelle activés.

Figure 4 : Sauts d’échelle

Filtrage des données avec le contrôle QueryExtender

Une tâche très courante pour les développeurs qui créent des pages web pilotées par les données consiste à filtrer les données. Pour cela, la génération de clauses Where dans les contrôles de source de données est traditionnellement effectuée. Cette approche peut être compliquée et, dans certains cas, la syntaxe Where ne vous permet pas de tirer parti de toutes les fonctionnalités de la base de données sous-jacente.

Pour faciliter le filtrage, un nouveau contrôle QueryExtender a été ajouté dans ASP.NET 4. Ce contrôle peut être ajouté aux contrôles EntityDataSource ou LinqDataSource afin de filtrer les données retournées par ces contrôles. Étant donné que le contrôle QueryExtender s’appuie sur LINQ, le filtre est appliqué sur le serveur de base de données avant que les données ne soient envoyées à la page, ce qui entraîne des opérations très efficaces.

Le contrôle QueryExtender prend en charge diverses options de filtre. Les sections suivantes décrivent ces options et fournissent des exemples de leur utilisation.

Rechercher

Pour l’option de recherche, le contrôle QueryExtender effectue une recherche dans les champs spécifiés. Dans l’exemple suivant, le contrôle utilise le texte entré dans le contrôle TextBoxSearch et recherche son contenu dans les ProductName colonnes et Supplier.CompanyName dans les données retournées à partir du contrôle LinqDataSource .

<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:SearchExpression DataFields="ProductName, Supplier.CompanyName" 
      SearchType="StartsWith"> 
    <asp:ControlParameter ControlID="TextBoxSearch" /> 
  </asp:SearchExpression> 
</asp:QueryExtender>

Plage

L’option de plage est similaire à l’option de recherche, mais spécifie une paire de valeurs pour définir la plage. Dans l’exemple suivant, le contrôle QueryExtender recherche la UnitPrice colonne dans les données retournées par le contrôle LinqDataSource . La plage est lue à partir des contrôles TextBoxFrom et TextBoxTo de la page.

<asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:RangeExpression DataField="UnitPrice" MinType="Inclusive" 
      MaxType="Inclusive"> 
    <asp:ControlParameter ControlID="TextBoxFrom" /> 
    <asp:ControlParameter ControlID="TexBoxTo" /> 
  </asp:RangeExpression> 

</asp:QueryExtender>

PropertyExpression

L’option d’expression de propriété vous permet de définir une comparaison avec une valeur de propriété. Si l’expression prend la valeur true, les données en cours d’examen sont retournées. Dans l’exemple suivant, le contrôle QueryExtender filtre les données en comparant les données de la Discontinued colonne à la valeur du contrôle CheckBoxDiscontinued sur la page.

<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products">
</asp:LinqDataSource>
<asp:QueryExtender TargetControlID="dataSource" runat="server">
   <asp:PropertyExpression>
      <asp:ControlParameter ControlID="CheckBoxDiscontinued" Name="Discontinued" />
   </asp:PropertyExpression>
</asp:QueryExtender>

CustomExpression

Enfin, vous pouvez spécifier une expression personnalisée à utiliser avec le contrôle QueryExtender . Cette option vous permet d’appeler une fonction dans la page qui définit une logique de filtre personnalisée. L’exemple suivant montre comment spécifier de manière déclarative une expression personnalisée dans le contrôle QueryExtender .

<asp:LinqDataSource ID="dataSource" runat="server" TableName="Products"> 
</asp:LinqDataSource> 
<asp:QueryExtender TargetControlID="dataSource" runat="server"> 
  <asp:CustomExpression OnQuerying="FilterProducts" /> 
</asp:QueryExtender>

L’exemple suivant montre la fonction personnalisée appelée par le contrôle QueryExtender . Dans ce cas, au lieu d’utiliser une requête de base de données qui inclut une clause Where , le code utilise une requête LINQ pour filtrer les données.

protected void FilterProducts(object sender, CustomExpressionEventArgs e) 
{ 
    e.Query = from p in e.Query.Cast() 
      where p.UnitPrice >= 10 
      select p; 
}

Ces exemples montrent qu’une seule expression est utilisée dans le contrôle QueryExtender à la fois. Toutefois, vous pouvez inclure plusieurs expressions dans le contrôle QueryExtender .

Expressions de code encodées html

Certains sites ASP.NET (en particulier avec ASP.NET MVC) s’appuient fortement sur l’utilisation <%= expression %> de la syntaxe (souvent appelées « pépites de code ») pour écrire du texte dans la réponse. Lorsque vous utilisez des expressions de code, il est facile d’oublier d’encoder le texte au format HTML. Si le texte provient d’une entrée utilisateur, il peut laisser des pages ouvertes à une attaque XSS (Cross Site Scripting).

ASP.NET 4 introduit la nouvelle syntaxe suivante pour les expressions de code :

<%: expression %>

Cette syntaxe utilise l’encodage HTML par défaut lors de l’écriture dans la réponse. Cette nouvelle expression se traduit efficacement par ce qui suit :

<%= HttpUtility.HtmlEncode(expression) %>

Par exemple, <% : Request["UserInput"] %> effectue l’encodage HTML sur la valeur de Request["UserInput"].

L’objectif de cette fonctionnalité est de permettre de remplacer toutes les instances de l’ancienne syntaxe par la nouvelle syntaxe afin que vous ne soyez pas obligé de décider à chaque étape laquelle utiliser. Toutefois, il existe des cas dans lesquels le texte en cours de sortie est destiné à être HTML ou est déjà encodé, auquel cas cela peut entraîner un double encodage.

Dans ce cas, ASP.NET 4 introduit une nouvelle interface, IHtmlString, ainsi qu’une implémentation concrète, HtmlString. Les instances de ces types vous permettent d’indiquer que la valeur de retour est déjà correctement encodée (ou examinée) pour l’affichage au format HTML, et que, par conséquent, la valeur ne doit pas être codée de nouveau en HTML. Par exemple, les éléments suivants ne doivent pas être (et ne sont pas) encodés au format HTML :

<%: new HtmlString("<strong>HTML that is not encoded</strong>") %>

ASP.NET méthodes d’assistance MVC 2 ont été mises à jour pour fonctionner avec cette nouvelle syntaxe afin qu’elles ne soient pas encodées doublement, mais uniquement lorsque vous exécutez ASP.NET 4. Cette nouvelle syntaxe ne fonctionne pas lorsque vous exécutez une application à l’aide de ASP.NET 3.5 SP1.

N’oubliez pas que cela ne garantit pas la protection contre les attaques XSS. Par exemple, le code HTML qui utilise des valeurs d’attribut qui ne sont pas entre guillemets peut contenir une entrée utilisateur qui est toujours sensible. Notez que la sortie des contrôles ASP.NET et des ASP.NET les helpers MVC inclut toujours des valeurs d’attribut entre guillemets, ce qui est l’approche recommandée.

De même, cette syntaxe n’effectue pas d’encodage JavaScript, par exemple lorsque vous créez une chaîne JavaScript basée sur une entrée utilisateur.

Modifications du modèle de projet

Dans les versions antérieures de ASP.NET, lorsque vous utilisez Visual Studio pour créer un projet de site web ou un projet d’application web, les projets résultants contiennent uniquement une page Default.aspx, un fichier par défaut Web.config et le App_Data dossier, comme illustré dans l’illustration suivante :

Capture d’écran du menu fichier Visual Studio. Un exemple de nouveau projet est mis en surbrillance montrant le fichier et le dossier par défaut.

Visual Studio prend également en charge un type de projet site web vide, qui ne contient aucun fichier, comme illustré dans la figure suivante :

Capture d’écran du menu Fichier Visual Studio. Un exemple de répertoire de projet ne contient aucun fichier ou dossier.

Le résultat est que pour les débutants, il y a très peu d’aide sur la façon de créer une application web de production. Par conséquent, ASP.NET 4 introduit trois nouveaux modèles, un pour un projet d’application web vide, et un pour un projet d’application web et de site web.

Modèle d’application web vide

Comme son nom l’indique, le modèle Application web vide est un projet d’application web dépouillée. Vous sélectionnez ce modèle de projet dans la boîte de dialogue Nouveau projet de Visual Studio, comme illustré dans la figure suivante :

(Cliquez pour afficher l’image en taille réelle)

Lorsque vous créez une application web vide ASP.NET, Visual Studio crée la disposition de dossier suivante :

Capture d’écran montrant le menu fichier Visual Studio. Le fichier intitulé Web dot config est mis en surbrillance.

Ceci est similaire à la disposition Site web vide des versions antérieures de ASP.NET, à une exception près. Dans Visual Studio 2010, les projets d’application web vide et de site web vide contiennent le fichier minimal Web.config suivant qui contient les informations utilisées par Visual Studio pour identifier l’infrastructure ciblée par le projet :

! <?xml version =

Sans cette propriété targetFramework , Visual Studio cible par défaut .NET Framework 2.0 afin de préserver la compatibilité lors de l’ouverture d’applications plus anciennes.

Modèles d’application web et de projet de site web

Les deux autres nouveaux modèles de projet fournis avec Visual Studio 2010 contiennent des modifications majeures. La figure suivante montre la disposition du projet qui est créée lorsque vous créez un projet d’application web. (La disposition d’un projet de site web est pratiquement identique.)

Le projet inclut un certain nombre de fichiers qui n’ont pas été créés dans les versions antérieures. En outre, le nouveau projet d’application web est configuré avec la fonctionnalité d’appartenance de base, ce qui vous permet de commencer rapidement à sécuriser l’accès à la nouvelle application. En raison de cette inclusion, le Web.config fichier du nouveau projet inclut des entrées utilisées pour configurer l’appartenance, les rôles et les profils. L’exemple suivant montre le fichier d’un Web.config nouveau projet d’application web. (Dans ce cas, roleManager est désactivé.)

(Cliquez pour afficher l’image en taille réelle)

Le projet contient également un deuxième Web.config fichier dans le Account répertoire. Le deuxième fichier de configuration permet de sécuriser l’accès à la page ChangePassword.aspx pour les utilisateurs non connectés. L’exemple suivant montre le contenu du deuxième Web.config fichier.

<?xml version=

Les pages créées par défaut dans les nouveaux modèles de projet contiennent également plus de contenu que dans les versions précédentes. Le projet contient une page et un fichier CSS de master par défaut, et la page par défaut (Default.aspx) est configurée pour utiliser la page master par défaut. Le résultat est que lorsque vous exécutez l’application web ou le site Web pour la première fois, la page par défaut (accueil) est déjà fonctionnelle. En fait, elle est similaire à la page par défaut que vous voyez lorsque vous démarrez une nouvelle application MVC.

(Cliquez pour afficher l’image en taille réelle)

L’objectif de ces modifications apportées aux modèles de projet est de fournir des conseils sur la façon de commencer à créer une nouvelle application web. Avec un balisage sémantiquement correct et strict conforme À la norme XHTML 1.0 et une disposition spécifiée à l’aide de CSS, les pages des modèles représentent les meilleures pratiques pour créer ASP.NET 4 applications web. Les pages par défaut ont également une disposition à deux colonnes que vous pouvez facilement personnaliser.

Par exemple, imaginez que pour une nouvelle application web, vous souhaitez modifier certaines couleurs et insérer le logo de votre entreprise à la place du logo My ASP.NET Application. Pour ce faire, vous créez un répertoire sous Content pour stocker l’image de votre logo :

Capture d’écran montrant un répertoire de fichiers avec un dossier images contenant un fichier de logo.

Pour ajouter l’image à la page, ouvrez le fichier, recherchez le Site.Master texte My ASP.NET Application et remplacez-le par un élément image dont l’attribut src est défini sur la nouvelle image de logo, comme dans l’exemple suivant :

(Cliquez pour afficher l’image en taille réelle)

Vous pouvez ensuite accéder au fichier Site.css et modifier les définitions de classe CSS pour modifier la couleur d’arrière-plan de la page ainsi que celle de l’en-tête.

Le résultat de ces modifications est que vous pouvez afficher une page d’accueil personnalisée avec très peu d’effort :

(Cliquez pour afficher l’image en taille réelle)

Améliorations css

L’un des principaux domaines de travail de ASP.NET 4 a été d’aider à rendre le code HTML conforme aux dernières normes HTML. Cela inclut des modifications apportées à la façon dont ASP.NET contrôles serveur web utilisent des styles CSS.

Paramètre de compatibilité pour le rendu

Par défaut, lorsqu’une application web ou un site web cible le .NET Framework 4, l’attribut controlRenderingCompatibilityVersion de l’élément pages est défini sur « 4.0 ». Cet élément est défini dans le fichier au niveau Web.config de l’ordinateur et s’applique par défaut à toutes les applications ASP.NET 4 :

<system.web> 
  <pages controlRenderingCompatibilityVersion="3.5|4.0"/> 
</system.web>

La valeur de controlRenderingCompatibility est une chaîne, qui autorise les définitions de nouvelles versions potentielles dans les versions ultérieures. Dans la version actuelle, les valeurs suivantes sont prises en charge pour cette propriété :

"3.5". Ce paramètre indique le rendu et le balisage hérités. Le balisage rendu par les contrôles est 100 % rétrocompatible et le paramètre de la propriété xhtmlConformance est respecté.
"4.0". Si la propriété a ce paramètre, ASP.NET contrôles serveur Web effectuent les opérations suivantes :
La propriété xhtmlConformance est toujours traitée comme « Strict ». Par conséquent, les contrôles restituent le balisage XHTML 1.0 strict.
La désactivation des contrôles non d’entrée ne rend plus les styles non valides.
Les éléments div autour des champs masqués sont désormais stylés afin qu’ils n’interfèrent pas avec les règles CSS créées par l’utilisateur.
Les contrôles de menu affichent un balisage sémantiquement correct et conforme aux directives d’accessibilité.
Les contrôles de validation ne rendent pas les styles inline.
Les contrôles qui étaient précédemment rendus border="0 » (contrôles qui dérivent du contrôle Table ASP.NET et du contrôle image ASP.NET) ne rendent plus cet attribut.

Désactivation des contrôles

Dans ASP.NET 3.5 SP1 et versions antérieures, l’infrastructure affiche l’attribut désactivé dans le balisage HTML pour tout contrôle dont la propriété Enabled est définie sur false. Toutefois, selon la spécification HTML 4.01, seuls les éléments d’entrée doivent avoir cet attribut.

Dans ASP.NET 4, vous pouvez définir la propriété controlRenderingCompatibilityVersion sur « 3.5 », comme dans l’exemple suivant :

<system.web> 
  <pages controlRenderingCompatibilityVersion="3.5"/> 
</system.web>

Vous pouvez créer un balisage pour un contrôle Label comme suit, ce qui désactive le contrôle :

<asp:Label id="Label" runat="server" Text="Test" Enabled="false">

Le contrôle Label affiche le code HTML suivant :

<span id="Label1" disabled="disabled">Test</span>

Dans ASP.NET 4, vous pouvez définir controlRenderingCompatibilityVersion sur « 4.0 ». Dans ce cas, seuls les contrôles qui affichent les éléments d’entrée affichent un attribut désactivé lorsque la propriété Enabled du contrôle a la valeur false. Les contrôles qui ne rendent pas les éléments d’entrée HTML affichent plutôt un attribut de classe qui fait référence à une classe CSS que vous pouvez utiliser pour définir un look désactivé pour le contrôle. Par exemple, le contrôle Label indiqué dans l’exemple précédent génère le balisage suivant :

<span id="Span1" class="aspnetdisabled">Test</span>

La valeur par défaut de la classe spécifiée pour ce contrôle est « aspNetDisabled ». Toutefois, vous pouvez modifier cette valeur par défaut en définissant la propriété statique DisabledCssClass statique de la classe WebControl . Pour les développeurs de contrôles, le comportement à utiliser pour un contrôle spécifique peut également être défini à l’aide de la propriété SupportsDisabledAttribute .

Masquage d’éléments div autour de champs masqués

ASP.NET versions 2.0 et ultérieures rendent les champs masqués spécifiques au système (tels que l’élément masqué utilisé pour stocker les informations d’état de la vue) à l’intérieur de l’élément div afin de se conformer à la norme XHTML. Toutefois, cela peut entraîner un problème lorsqu’une règle CSS affecte des éléments div sur une page. Par exemple, une ligne d’un pixel peut apparaître dans la page autour des éléments div masqués. Dans ASP.NET 4, les éléments div qui entourent les champs masqués générés par ASP.NET ajouter une référence de classe CSS comme dans l’exemple suivant :

<div class="aspNetHidden">...</div>

Vous pouvez ensuite définir une classe CSS qui s’applique uniquement aux éléments masqués générés par ASP.NET, comme dans l’exemple suivant :

<style type="text/css"> 
  DIV# aspNetHidden {border:0;} 

</style>

Rendu d’une table externe pour les contrôles modèle

Par défaut, les contrôles serveur web ASP.NET suivants qui prennent en charge les modèles sont automatiquement encapsulés dans une table externe utilisée pour appliquer des styles inline :

Formview
Connexion
Passwordrecovery
ChangePassword
Assistant
CreateUserWizard

Une nouvelle propriété nommée RenderOuterTable a été ajoutée à ces contrôles qui permet de supprimer la table externe du balisage. Par exemple, considérez l’exemple suivant de contrôle FormView :

<asp:FormView ID="FormView1" runat="server"> 
  <ItemTemplate> 
      Content 
  </ItemTemplate> 

</asp:FormView>

Ce balisage affiche la sortie suivante dans la page, qui comprend une table HTML :

<table cellspacing="0" border="0" id="Table1" style="border-collapse:collapse;"> 
  <tr> 
    <td colspan="2"> 
      Content 
    </td> 
  </tr> 

</table>

Pour empêcher le rendu de la table, vous pouvez définir la propriété RenderOuterTable du contrôle FormView, comme dans l’exemple suivant :

<asp:FormView ID="FormView1" runat="server" RenderOuterTable="false">

L’exemple précédent affiche la sortie suivante, sans les éléments table, tr et td :

Contenu

Cette amélioration peut faciliter le style du contenu du contrôle avec CSS, car aucune étiquette inattendue n’est rendue par le contrôle.

Notes

Remarque Cette modification désactive la prise en charge de la fonction de format automatique dans le concepteur Visual Studio 2010, car il n’existe plus d’élément de table qui peut héberger des attributs de style générés par l’option de format automatique.

Améliorations du contrôle ListView

L’utilisation du contrôle ListView a été facilitée dans ASP.NET 4. La version antérieure du contrôle exigeait que vous spécifiiez un modèle de disposition qui contenait un contrôle serveur avec un ID connu. Le balisage suivant montre un exemple typique d’utilisation du contrôle ListView dans ASP.NET 3.5.

<asp:ListView ID="ListView1" runat="server"> 
  <LayoutTemplate> 
    <asp:PlaceHolder ID="ItemPlaceHolder" runat="server"></asp:PlaceHolder> 
  </LayoutTemplate> 
  <ItemTemplate> 
    <% Eval("LastName")%> 
  </ItemTemplate> 
</asp:ListView>

Dans ASP.NET 4, le contrôle ListView ne nécessite pas de modèle de disposition. Le balisage indiqué dans l’exemple précédent peut être remplacé par le balisage suivant :

<asp:ListView ID="ListView1" runat="server"> 
  <ItemTemplate> 
    <% Eval("LastName")%> 
  </ItemTemplate> 

</asp:ListView>

Améliorations du contrôle CheckBoxList et RadioButtonList

Dans ASP.NET 3.5, vous pouvez spécifier la disposition pour CheckBoxList et RadioButtonList à l’aide des deux paramètres suivants :

Flux. Le contrôle restitue les éléments d’étendue pour contenir son contenu.
Table. Le contrôle restitue un élément de table pour contenir son contenu.

L’exemple suivant montre le balisage pour chacun de ces contrôles.

<asp:CheckBoxList ID="CheckBoxList1" runat="server" RepeatLayout="Flow"> 
  <asp:ListItem Text="CheckBoxList" Value="cbl" /> 
</asp:CheckBoxList> 

<asp:RadioButtonList runat="server" RepeatLayout="Table"> 
  <asp:ListItem Text="RadioButtonList" Value="rbl" /> 
</asp:RadioButtonList>

Par défaut, les contrôles affichent du code HTML semblable à ce qui suit :

<span id="Span2"><input id="CheckBoxList1_0" type="checkbox" 
    name="CheckBoxList1$0" /><label for="CheckBoxList1_0">CheckBoxList</label></span> 
    
<table id="RadioButtonList1" border="0"> 
  <tr> 
    <td><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></td> 
  </tr> 

</table>

Étant donné que ces contrôles contiennent des listes d’éléments, pour afficher un code HTML sémantiquement correct, ils doivent afficher leur contenu à l’aide d’éléments de liste HTML (li). Cela facilite la lecture de pages Web à l’aide de la technologie d’assistance et facilite le style des contrôles à l’aide de CSS.

Dans ASP.NET 4, les contrôles CheckBoxList et RadioButtonList prennent en charge les nouvelles valeurs suivantes pour la propriété RepeatLayout :

OrderedList : le contenu est rendu sous forme d’éléments li au sein d’un élément ol .
UnorderedList : le contenu est rendu sous forme d’éléments li au sein d’un élément ul .

L’exemple suivant montre comment utiliser ces nouvelles valeurs.

<asp:CheckBoxList ID="CheckBoxList1" runat="server" 
      RepeatLayout="OrderedList">
  <asp:ListItem Text="CheckBoxList" Value="cbl" />
</asp:CheckBoxList>

<asp:RadioButtonList ID="RadioButtonList1" runat="server"  
      RepeatLayout="UnorderedList">
  <asp:ListItem Text="RadioButtonList" Value="rbl" />
</asp:RadioButtonList>

Le balisage précédent génère le code HTML suivant :

<ol id="CheckBoxList1">

  <li><input id="CheckBoxList1_0" type="checkbox" name="CheckBoxList1$0" value="cbl" /><label for="CheckBoxList1_0">CheckBoxList</label></li>
</ol>
    
<ul id="RadioButtonList1">
  <li><input id="RadioButtonList1_0" type="radio" name="RadioButtonList1" value="rbl" /><label for="RadioButtonList1_0">RadioButtonList</label></li>

</ul>

Notes

Remarque Si vous définissez RepeatLayout sur OrderedList ou UnorderedList, la propriété RepeatDirection ne peut plus être utilisée et lève une exception au moment de l’exécution si la propriété a été définie dans votre balisage ou votre code. La propriété n’aurait aucune valeur, car la disposition visuelle de ces contrôles est définie à l’aide de CSS à la place.

Avant ASP.NET 4, le contrôle Menu a rendu une série de tables HTML. Cela rendait plus difficile l’application de styles CSS en dehors de la définition des propriétés inline et n’était pas non plus conforme aux normes d’accessibilité.

Dans ASP.NET 4, le contrôle affiche désormais le code HTML à l’aide d’un balisage sémantique qui se compose d’une liste et d’éléments de liste non triés. L’exemple suivant montre le balisage dans une page ASP.NET pour le contrôle Menu .

<asp:Menu ID="Menu1" runat="server"> 
  <Items> <asp:MenuItem Text="Home" Value="Home" /> 
    <asp:MenuItem Text="About" Value="About" /> 
  </Items> 

</asp:Menu>

Lorsque la page s’affiche, le contrôle produit le code HTML suivant (le code onclick a été omis pour des motifs de clarté) :

<div id="Menu1"> 
  <ul> 
    <li><a href="#" onclick="...">Home</a></li> 
    <li><a href="#" onclick="...">About</a></li> 
  </ul> 

</div> 
<script type="text/javascript"> 
  new Sys.WebForms.Menu('Menu1'); 
</script>

Outre les améliorations apportées au rendu, la navigation au clavier du menu a été améliorée à l’aide de la gestion des focus. Lorsque le contrôle Menu obtient le focus, vous pouvez utiliser les touches de direction pour parcourir les éléments. Le contrôle Menu joint désormais les rôles et attributs des applications Internet enrichies accessibles (ARIA) pour améliorerl’accessibilité.

Les styles du contrôle de menu sont rendus dans un bloc de style en haut de la page, plutôt qu’en ligne avec les éléments HTML rendus. Si vous souhaitez prendre le contrôle total sur le style du contrôle, vous pouvez définir la nouvelle propriété IncludeStyleBlock sur false, auquel cas le bloc de style n’est pas émis. Une façon d’utiliser cette propriété consiste à utiliser la fonctionnalité de mise en forme automatique dans le concepteur Visual Studio pour définir l’apparence du menu. Vous pouvez ensuite exécuter la page, ouvrir la source de la page, puis copier le bloc de style rendu dans un fichier CSS externe. Dans Visual Studio, annulez le style et définissez IncludeStyleBlock surfalse. Le résultat est que l’apparence du menu est définie à l’aide de styles dans une feuille de style externe.

Assistant et Créer des contrôlesUserWizard

L’Assistant ASP.NET et les contrôles CreateUserWizard prennent en charge les modèles qui vous permettent de définir le code HTML qu’ils affichent. (CreateUserWizard dérive de l’Assistant.) L’exemple suivant montre le balisage d’un contrôle CreateUserWizard entièrement modèle :

<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="0"> 
  <HeaderTemplate> 
  </HeaderTemplate>
 
  <SideBarTemplate> 
  </SideBarTemplate>
 
  <StepNavigationTemplate> 
  </StepNavigationTemplate> 

  <StartNavigationTemplate> 
  </StartNavigationTemplate> 

  <FinishNavigationTemplate> 
  </FinishNavigationTemplate> 

  <WizardSteps> 
    <asp:CreateUserWizardStep ID="CreateUserWizardStep1" runat="server"> 
      <ContentTemplate> 
      </ContentTemplate>

      <CustomNavigationTemplate> 
      </CustomNavigationTemplate>

    </asp:CreateUserWizardStep>
 
    <asp:CompleteWizardStep ID="CompleteWizardStep1" runat="server"> 
      <ContentTemplate> 
      </ContentTemplate> 
    </asp:CompleteWizardStep> 

  </WizardSteps> 

</asp:CreateUserWizard>

Le contrôle affiche le code HTML comme suit :

<table cellspacing="0" cellpadding="0" border="0" id="CreateUserWizard1" style="border-collapse:collapse;"> 
  <tr> 
    <td>Header</td> 
  </tr> 
  <tr style="height:100%;"> 
    <td> 
      <table cellspacing="0" cellpadding="0" border="0" style="height:100%;width:100%;border-collapse:collapse;"> 
        <tr> 
          <td style="height:100%;width:100%;"></td> 
        </tr> 
      </table> 
    </td> 
  </tr> 
  <tr> 
    <td align="right"></td> 
  </tr> 

</table>

Dans ASP.NET 3.5 SP1, même si vous pouvez modifier le contenu du modèle, vous avez toujours un contrôle limité sur la sortie du contrôle Assistant . Dans ASP.NET 4, vous pouvez créer un modèle LayoutTemplate et insérer des contrôles PlaceHolder (à l’aide de noms réservés) pour spécifier la façon dont vous souhaitez que le contrôle Assistant s’affiche. L’exemple suivant illustre cela :

<asp:CreateUserWizard ID="CreateUserWizard1" runat="server" ActiveStepIndex="1"> 
  <LayoutTemplate> 
    <asp:PlaceHolder ID="headerPlaceholder" runat="server" /> 
    <asp:PlaceHolder ID="sideBarPlaceholder" runat="server" /> 
    <asp:PlaceHolder id="wizardStepPlaceholder" runat="server" /> 
    <asp:PlaceHolder id="navigationPlaceholder" runat="server" /> 
  </LayoutTemplate> 
  <HeaderTemplate> 
    Header 
  </HeaderTemplate> 
  <WizardSteps> 
    <asp:CreateUserWizardStep runat="server"> 
      <ContentTemplate> 
      </ContentTemplate> 
    </asp:CreateUserWizardStep> 
    <asp:CompleteWizardStep runat="server"> 
      <ContentTemplate> 
      </ContentTemplate> 
    </asp:CreateUserWizardStep> 
  </WizardSteps> 

</asp:CreateUserWizard>

L’exemple contient les espaces réservés nommés suivants dans l’élément LayoutTemplate :

headerPlaceholder : au moment de l’exécution, il est remplacé par le contenu de l’élément HeaderTemplate .
sideBarPlaceholder : au moment de l’exécution, il est remplacé par le contenu de l’élément SideBarTemplate .
wizardStepPlaceHolder : au moment de l’exécution, il est remplacé par le contenu de l’élément WizardStepTemplate .
navigationPlaceholder : au moment de l’exécution, il est remplacé par tous les modèles de navigation que vous avez définis.

Le balisage de l’exemple qui utilise des espaces réservés affiche le code HTML suivant (sans le contenu réellement défini dans les modèles) :

<span>
</span>

Le seul code HTML qui n’est pas défini par l’utilisateur est un élément span . (Nous prévoyons que dans les versions ultérieures, même l’élément span ne sera pas rendu.) Cela vous donne désormais un contrôle total sur la quasi-totalité du contenu généré par le contrôle Assistant .

ASP.NET MVC

ASP.NET MVC a été introduit en tant que framework complémentaire pour ASP.NET 3.5 SP1 en mars 2009. Visual Studio 2010 inclut ASP.NET MVC 2, qui inclut de nouvelles fonctionnalités et fonctionnalités.

Prise en charge des zones

Les zones vous permettent de regrouper des contrôleurs et des vues dans des sections d’une application volumineuse en un isolement relatif des autres sections. Chaque zone peut être implémentée sous la forme d’un projet MVC ASP.NET distinct qui peut ensuite être référencé par l’application main. Cela permet de gérer la complexité lorsque vous créez une application volumineuse et facilite la collaboration de plusieurs équipes sur une seule application.

Prise en charge de la validation des attributs Data-Annotation

Les attributs DataAnnotations vous permettent d’attacher une logique de validation à un modèle à l’aide d’attributs de métadonnées. Les attributs DataAnnotations ont été introduits dans ASP.NET données dynamiques dans ASP.NET 3.5 SP1. Ces attributs ont été intégrés dans le classeur de modèle par défaut et fournissent un moyen piloté par les métadonnées de valider l’entrée utilisateur.

Helpers avec modèle

Les assistances avec modèle vous permettent d’associer automatiquement des modèles de modification et d’affichage à des types de données. Par exemple, vous pouvez utiliser un modèle d’assistance pour spécifier qu’un élément d’interface utilisateur du sélecteur de date est automatiquement rendu pour une valeur System.DateTime . Cela est similaire aux modèles de champ dans ASP.NET données dynamiques.

Les méthodes Html.EditorFor et Html.DisplayFor helper ont une prise en charge intégrée pour le rendu des types de données standard ainsi que des objets complexes avec plusieurs propriétés. Ils personnalisent également le rendu en vous permettant d’appliquer des attributs d’annotation de données tels que DisplayName et ScaffoldColumn à l’objet ViewModel .

Souvent, vous souhaitez personnaliser davantage la sortie des helpers de l’interface utilisateur et avoir un contrôle total sur ce qui est généré. Les méthodes Html.EditorFor et Html.DisplayFor helper prennent en charge cette opération à l’aide d’un mécanisme de création de modèles qui vous permet de définir des modèles externes qui peuvent remplacer et contrôler la sortie rendue. Les modèles peuvent être rendus individuellement pour une classe.

Dynamic Data

Les données dynamiques ont été introduites dans la version de .NET Framework 3.5 SP1 à la mi-2008. Cette fonctionnalité offre de nombreuses améliorations pour la création d’applications pilotées par les données, notamment les suivantes :

Expérience RAD pour créer rapidement un site Web piloté par les données.
Validation automatique basée sur des contraintes définies dans le modèle de données.
Possibilité de modifier facilement le balisage généré pour les champs des contrôles GridView et DetailsView à l’aide de modèles de champs qui font partie de votre projet de données dynamiques.

Notes

Remarque Pour plus d’informations, consultez la documentation données dynamiques dans MSDN Library.

Pour ASP.NET 4, les données dynamiques ont été améliorées pour donner aux développeurs encore plus de puissance pour créer rapidement des sites Web pilotés par les données.

Activation des données dynamiques pour les projets existants

Les fonctionnalités de données dynamiques fournies dans .NET Framework 3.5 SP1 ont apporté de nouvelles fonctionnalités telles que les suivantes :

Modèles de champ : ils fournissent des modèles basés sur des types de données pour les contrôles liés aux données. Les modèles de champ offrent un moyen plus simple de personnaliser l’apparence des contrôles de données que d’utiliser des champs de modèle pour chaque champ.
Validation : les données dynamiques vous permettent d’utiliser des attributs sur les classes de données pour spécifier la validation pour des scénarios courants tels que les champs obligatoires, la vérification de plage, la vérification de type, la correspondance de modèles à l’aide d’expressions régulières et la validation personnalisée. La validation est appliquée par les contrôles de données.

Toutefois, ces fonctionnalités avaient les conditions suivantes :

La couche d’accès aux données devait être basée sur Entity Framework ou LINQ to SQL.
Les seuls contrôles de source de données pris en charge pour ces fonctionnalités étaient les contrôles EntityDataSource ou LinqDataSource .
Les fonctionnalités nécessitaient un projet web qui avait été créé à l’aide des modèles Données dynamiques ou Entités de données dynamiques afin d’avoir tous les fichiers nécessaires pour prendre en charge la fonctionnalité.

L’un des principaux objectifs de la prise en charge des données dynamiques dans ASP.NET 4 est d’activer les nouvelles fonctionnalités de Données dynamiques pour n’importe quelle application ASP.NET. L’exemple suivant montre le balisage des contrôles qui peuvent tirer parti de la fonctionnalité Données dynamiques dans une page existante.

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="True" 
    DataKeyNames="ProductID" DataSourceID="LinqDataSource1"> 
</asp:GridView> 
<asp:LinqDataSource ID="LinqDataSource1" runat="server" 
    ContextTypeName="DataClassesDataContext" EnableDelete="True" EnableInsert="True" 
    EnableUpdate="True" TableName="Products"> 

</asp:LinqDataSource>

Dans le code de la page, le code suivant doit être ajouté afin d’activer la prise en charge des données dynamiques pour ces contrôles :

GridView1.EnableDynamicData(typeof(Product));

Lorsque le contrôle GridView est en mode édition, Dynamic Data valide automatiquement que les données entrées sont au format approprié. Si ce n’est pas le cas, un message d’erreur s’affiche.

Cette fonctionnalité offre également d’autres avantages, tels que la possibilité de spécifier des valeurs par défaut pour le mode d’insertion. Sans Données dynamiques, pour implémenter une valeur par défaut pour un champ, vous devez attacher à un événement, localiser le contrôle (à l’aide de FindControl) et définir sa valeur. Dans ASP.NET 4, l’appel EnableDynamicData prend en charge un deuxième paramètre qui vous permet de transmettre les valeurs par défaut pour n’importe quel champ de l’objet, comme illustré dans cet exemple :

DetailsView1.EnableDynamicData(typeof(Product), new { ProductName = "DefaultName" });

Syntaxe de contrôle DynamicDataManager déclarative

Le contrôle DynamicDataManager a été amélioré afin que vous puissiez le configurer de manière déclarative, comme avec la plupart des contrôles dans ASP.NET, au lieu de le configurer uniquement dans le code. Le balisage du contrôle DynamicDataManager ressemble à l’exemple suivant :

<asp:DynamicDataManager ID="DynamicDataManager1" runat="server" 
    AutoLoadForeignKeys="true"> 
  <DataControls> 
    <asp:DataControlReference ControlID="GridView1" /> 
  </DataControls> 

</asp:DynamicDataManager> 
<asp:GridView id="GridView1" runat="server" 
</asp:GridView>

Ce balisage active le comportement des données dynamiques pour le contrôle GridView1 référencé dans la section DataControls du contrôle DynamicDataManager .

Modèles d’entité

Les modèles d’entité offrent un nouveau moyen de personnaliser la disposition des données sans vous obliger à créer une page personnalisée. Les modèles de page utilisent le contrôle FormView (au lieu du contrôle DetailsView , comme utilisé dans les modèles de page dans les versions antérieures de Données dynamiques) et le contrôle DynamicEntity pour afficher les modèles d’entité. Cela vous donne plus de contrôle sur le balisage rendu par Dynamic Data.

La liste suivante montre la nouvelle disposition de répertoire de projet qui contient des modèles d’entité :

\DynamicData\EntityTemplates
\DynamicData\EntityTemplates\Default.ascx
\DynamicData\EntityTemplates\Default_Edit.ascx
\DynamicData\EntityTemplates\Default_Insert.ascx

Le EntityTemplate répertoire contient des modèles permettant d’afficher des objets de modèle de données. Par défaut, les objets sont rendus à l’aide du Default.ascx modèle, qui fournit un balisage qui ressemble exactement au balisage créé par le contrôle DetailsView utilisé par Dynamic Data dans ASP.NET 3.5 SP1. L’exemple suivant montre le balisage du Default.ascx contrôle :

<asp:EntityTemplate runat="server" ID="TemplateContainer1"> 
  <ItemTemplate> 
    <tr 
      <td> 
        <asp:Label ID="Label1" runat="server" OnInit="Label_Init" /> 
      </td> 
      <td> 
        <asp:DynamicControl runat="server" OnInit="DynamicControl_Init" /> 
      </td> 
    </tr> 
  </ItemTemplate> 

</asp:EntityTemplate>

Les modèles par défaut peuvent être modifiés pour modifier l’apparence de l’ensemble du site. Il existe des modèles pour les opérations d’affichage, de modification et d’insertion. De nouveaux modèles peuvent être ajoutés en fonction du nom de l’objet de données afin de modifier l’apparence d’un seul type d’objet. Par exemple, vous pouvez ajouter le modèle suivant :

\DynamicData\EntityTemplates\Products.aspx

Le modèle peut contenir le balisage suivant :

<tr> 
  <td>Name</td> 
  <td><asp:DynamicControl runat="server" DataField="ProductName" /></td> 
  <td>Category</td> 
  <td><asp:DynamicControl runat="server" DataField="Category" /></td> 

</tr>

Les nouveaux modèles d’entité sont affichés sur une page à l’aide du nouveau contrôle DynamicEntity . Au moment de l’exécution, ce contrôle est remplacé par le contenu du modèle d’entité. Le balisage suivant montre le contrôle FormView dans le modèle de Detail.aspx page qui utilise le modèle d’entité. Notez l’élément DynamicEntity dans le balisage.

<asp:FormView runat="server" ID="FormView1" 
    DataSourceID="DetailsDataSource" 
    OnItemDeleted="FormView1_ItemDeleted"> 
  <ItemTemplate> 
    <table class="DDDetailsTable" cellpadding="6"> 
      <asp:DynamicEntity runat="server" /> 
      <tr class="td"> 
        <td colspan="2"> 
          <asp:DynamicHyperLink ID="EditHyperLink" runat="server" 
              Action="Edit" Text="Edit" /> 
          <asp:LinkButton ID="DeleteLinkButton" runat="server" 
              CommandName="Delete" 
              CausesValidation="false" 
              OnClientClick='return confirm("Are you sure you want to delete this item?");' 
              Text="Delete" /> 
        </td> 
      </tr> 
    </table> 
  </ItemTemplate> 

</asp:FormView>

Nouveaux modèles de champ pour les URL et les adresses Email

ASP.NET 4 introduit deux nouveaux modèles de champs intégrés, EmailAddress.ascx et Url.ascx. Ces modèles sont utilisés pour les champs marqués comme EmailAddress ou Url avec l’attribut DataType . Pour les objets EmailAddress , le champ s’affiche sous la forme d’un lien hypertexte créé à l’aide du protocole mailto : . Lorsque les utilisateurs cliquent sur le lien, il ouvre le client de messagerie de l’utilisateur et crée un message squelette. Les objets tapés en tant qu’URL s’affichent sous forme de liens hypertexte ordinaires.

L’exemple suivant montre comment les champs sont marqués.

[DataType(DataType.EmailAddress)] 
public object HomeEmail { get; set; } 

[DataType(DataType.Url)] 
public object Website { get; set; }

Création de liens avec le contrôle DynamicHyperLink

Dynamic Data utilise la nouvelle fonctionnalité de routage ajoutée dans .NET Framework 3.5 SP1 pour contrôler les URL que les utilisateurs finaux voient lorsqu’ils accèdent au site Web. Le nouveau contrôle DynamicHyperLink facilite la création de liens vers des pages dans un site de données dynamiques. L’exemple suivant montre comment utiliser le contrôle DynamicHyperLink :

<asp:DynamicHyperLink ID="ListHyperLink" runat="server" 
    Action="List" TableName="Products"> 
    Show all products 
</asp:DynamicHyperLink>

Ce balisage crée un lien qui pointe vers la page Liste de la Products table en fonction des itinéraires définis dans le Global.asax fichier. Le contrôle utilise automatiquement le nom de table par défaut sur lequel la page Données dynamiques est basée.

Prise en charge de l’héritage dans le modèle de données

Entity Framework et LINQ to SQL prennent en charge l’héritage dans leurs modèles de données. Une base de données contenant une table peut en être un InsurancePolicy exemple. Il peut également contenir des CarPolicy tables et HousePolicy qui ont les mêmes champs que InsurancePolicy , puis ajouter d’autres champs. Les données dynamiques ont été modifiées pour comprendre les objets hérités dans le modèle de données et pour prendre en charge la structure des tables héritées.

Prise en charge des relations plusieurs-à-plusieurs (Entity Framework uniquement)

Entity Framework offre une prise en charge complète des relations plusieurs-à-plusieurs entre les tables, qui est implémentée en exposant la relation en tant que collection sur un objet Entity . De nouveaux ManyToMany.ascx modèles de ManyToMany_Edit.ascx champ ont été ajoutés pour fournir une prise en charge de l’affichage et de la modification des données impliquées dans les relations plusieurs-à-plusieurs.

Nouveaux attributs pour contrôler l’affichage et la prise en charge des énumérations

DisplayAttribute a été ajouté pour vous donner un contrôle supplémentaire sur la façon dont les champs sont affichés. L’attribut DisplayName dans les versions antérieures de Dynamic Data vous a permis de modifier le nom utilisé comme légende pour un champ. La nouvelle classe DisplayAttribute vous permet de spécifier d’autres options d’affichage d’un champ, telles que l’ordre dans lequel un champ est affiché et si un champ sera utilisé comme filtre. L’attribut fournit également un contrôle indépendant du nom utilisé pour les étiquettes d’un contrôle GridView , du nom utilisé dans un contrôle DetailsView , du texte d’aide du champ et du filigrane utilisé pour le champ (si le champ accepte l’entrée de texte).

La classe EnumDataTypeAttribute a été ajoutée pour vous permettre de mapper des champs à des énumérations. Lorsque vous appliquez cet attribut à un champ, vous spécifiez un type d’énumération. Dynamic Data utilise le nouveau Enumeration.ascx modèle de champ pour créer une interface utilisateur pour afficher et modifier des valeurs d’énumération. Le modèle mappe les valeurs de la base de données aux noms de l’énumération.

Prise en charge améliorée des filtres

Données dynamiques 1.0 livrées avec des filtres intégrés pour les colonnes booléennes et les colonnes à clé étrangère. Les filtres ne vous permettaient pas de spécifier s’ils étaient affichés ou dans quel ordre ils étaient affichés. Le nouvel attribut DisplayAttribute résout ces deux problèmes en vous permettant de contrôler si une colonne est affichée en tant que filtre et dans quel ordre elle sera affichée.

Une autre amélioration est que la prise en charge du filtrage a été réécrite pour utiliser la nouvelle fonctionnalité de Web Forms. Cela vous permet de créer des filtres sans avoir besoin de connaître le contrôle de source de données avec lequel les filtres seront utilisés. Avec ces extensions, les filtres ont également été transformés en contrôles de modèle, ce qui vous permet d’en ajouter de nouveaux. Enfin, la classe DisplayAttribute mentionnée précédemment autorise le remplacement du filtre par défaut, de la même manière que UIHint autorise le remplacement du modèle de champ par défaut pour une colonne.

Améliorations apportées au développement web visual Studio 2010

Le développement web dans Visual Studio 2010 a été amélioré pour une plus grande compatibilité CSS, une productivité accrue grâce aux extraits de code HTML et ASP.NET de balisage et au nouveau JavaScript IntelliSense dynamique.

Compatibilité CSS améliorée

Le concepteur Visual Web Developer dans Visual Studio 2010 a été mis à jour pour améliorer la conformité aux normes CSS 2.1. Le concepteur préserve mieux l’intégrité de la source HTML et est plus robuste que dans les versions précédentes de Visual Studio. Sous le capot, des améliorations architecturales ont également été apportées qui permettront d’améliorer à l’avenir le rendu, la disposition et la facilité d’entretien.

Extraits de code HTML et JavaScript

Dans l’éditeur HTML, IntelliSense complète automatiquement les noms de balise. La fonctionnalité Extraits de code IntelliSense complète automatiquement les balises entières et bien plus encore. Dans Visual Studio 2010, les extraits de code IntelliSense sont pris en charge pour JavaScript, ainsi que C# et Visual Basic, qui étaient pris en charge dans les versions antérieures de Visual Studio.

Visual Studio 2010 comprend plus de 200 extraits de code qui vous permettent de remplir automatiquement les balises ASP.NET et HTML courantes, y compris les attributs obligatoires (tels que runat="server ») et les attributs communs spécifiques à une balise (tels que ID, DataSourceID, ControlToValidate et Text).

Vous pouvez télécharger des extraits de code supplémentaires ou écrire vos propres extraits de code qui encapsulent les blocs de balisage que vous ou votre équipe utilisez pour les tâches courantes.

Améliorations apportées à JavaScript IntelliSense

Dans Visual 2010, JavaScript IntelliSense a été repensé pour offrir une expérience d’édition encore plus riche. IntelliSense reconnaît désormais les objets qui ont été générés dynamiquement par des méthodes telles que registerNamespace et par des techniques similaires utilisées par d’autres frameworks JavaScript. Les performances ont été améliorées pour analyser les grandes bibliothèques de scripts et afficher IntelliSense avec peu ou pas de délai de traitement. La compatibilité a été considérablement améliorée pour prendre en charge presque toutes les bibliothèques tierces et prendre en charge divers styles de codage. Les commentaires de documentation sont désormais analysés au fur et à mesure que vous tapez et sont immédiatement exploités par IntelliSense.

Déploiement d’applications web avec Visual Studio 2010

Lorsque les développeurs ASP.NET déploient une application web, ils rencontrent souvent des problèmes tels que les suivants :

Le déploiement sur un site d’hébergement partagé nécessite des technologies telles que FTP, qui peuvent être lentes. En outre, vous devez effectuer manuellement des tâches telles que l’exécution de scripts SQL pour configurer une base de données et vous devez modifier les paramètres IIS, comme la configuration d’un dossier de répertoire virtuel en tant qu’application.
Dans un environnement d’entreprise, outre le déploiement des fichiers d’application web, les administrateurs doivent souvent modifier ASP.NET fichiers de configuration et les paramètres IIS. Les administrateurs de base de données doivent exécuter une série de scripts SQL pour que la base de données d’application soit en cours d’exécution. Ces installations nécessitent beaucoup de main-d’œuvre, prennent souvent des heures et doivent être documentées avec soin.

Visual Studio 2010 inclut des technologies qui répondent à ces problèmes et qui vous permettent de déployer en toute transparence des applications web. L’une de ces technologies est l’outil de déploiement web IIS (MsDeploy.exe).

Les fonctionnalités de déploiement web dans Visual Studio 2010 incluent les principaux domaines suivants :

Empaquetage web
transformation Web.config
Déploiement de base de données
Publier en un clic pour les applications web

Les sections suivantes fournissent des détails sur ces fonctionnalités.

Empaquetage web

Visual Studio 2010 utilise l’outil MSDeploy pour créer un fichier compressé (.zip) pour votre application, appelé package web. Le fichier de package contient des métadonnées relatives à votre application, ainsi que le contenu suivant :

Paramètres IIS, qui incluent les paramètres du pool d’applications, les paramètres de page d’erreur, etc.
Contenu web réel, qui comprend les pages Web, les contrôles utilisateur, le contenu statique (images et fichiers HTML), etc.
SQL Server schémas et données de base de données.
Certificats de sécurité, composants à installer dans le GAC, paramètres du Registre, etc.

Un package web peut être copié sur n’importe quel serveur, puis installé manuellement à l’aide du Gestionnaire DES SERVICES Internet. Vous pouvez également installer le package à l’aide de commandes de ligne de commande ou d’API de déploiement pour un déploiement automatisé.

Visual Studio 2010 fournit des tâches et des cibles MSBuild intégrées pour créer des packages Web. Pour plus d’informations, consultez ASP.NET Vue d’ensemble du déploiement d’un projet d’application web sur le site Web MSDN et 10 + 20 raisons pour lesquelles vous devez créer un package web sur le blog de Vishal Joshi.

transformation Web.config

Pour le déploiement d’applications web, Visual Studio 2010 introduit la transformation de document XML (XDT), qui est une fonctionnalité qui vous permet de transformer un Web.config fichier des paramètres de développement en paramètres de production. Les paramètres de transformation sont spécifiés dans les fichiers de transformation nommés web.debug.config, web.release.config, et ainsi de suite. (Les noms de ces fichiers correspondent aux configurations MSBuild.) Un fichier de transformation inclut uniquement les modifications que vous devez apporter à un fichier déployé Web.config . Vous spécifiez les modifications à l’aide d’une syntaxe simple.

L’exemple suivant montre une partie d’un web.release.config fichier qui peut être produite pour le déploiement de votre configuration de mise en production. L’mot clé remplacer dans l’exemple spécifie que, pendant le déploiement, le nœud connectionString dans le Web.config fichier sera remplacé par les valeurs répertoriées dans l’exemple.

<connectionStrings xdt:Transform="Replace"> 
  <add name="BlogDB" connectionString="connection string detail]" /> 

</connectionStrings>

Pour plus d’informations, consultez Web.config Syntaxe de transformation pour le déploiement de projet d’application web sur le site Web MSDN etDéploiement web : Web.Config Transformation sur Vishal Joshi’s blog.

Déploiement de base de données

Un package de déploiement Visual Studio 2010 peut inclure des dépendances sur SQL Server bases de données. Dans le cadre de la définition du package, vous fournissez les chaîne de connexion pour votre base de données source. Lorsque vous créez le package Web, Visual Studio 2010 crée des scripts SQL pour le schéma de base de données et éventuellement pour les données, puis les ajoute au package. Vous pouvez également fournir des scripts SQL personnalisés et spécifier la séquence dans laquelle ils doivent s’exécuter sur le serveur. Au moment du déploiement, vous fournissez un chaîne de connexion approprié pour le serveur cible ; le processus de déploiement utilise ensuite cette chaîne de connexion pour exécuter les scripts qui créent le schéma de base de données et ajoutent les données.

En outre, à l’aide de la publication en un clic, vous pouvez configurer le déploiement pour publier votre base de données directement lorsque l’application est publiée sur un site d’hébergement partagé distant. Pour plus d’informations, consultez Guide pratique pour déployer une base de données avec un projet d’application web sur le site web MSDN et Déploiement de base de données avec VS 2010 sur le blog de Vishal Joshi.

One-Click Publier pour les applications web

Visual Studio 2010 vous permet également d’utiliser le service de gestion à distance IIS pour publier une application web sur un serveur distant. Vous pouvez créer un profil de publication pour votre compte d’hébergement ou pour tester des serveurs ou des serveurs intermédiaires. Chaque profil peut enregistrer les informations d’identification appropriées en toute sécurité. Vous pouvez ensuite déployer sur n’importe quel serveur cible en un seul clic à l’aide de la barre d’outils Publier en un clic sur le web. Avec Visual Studio 2010, vous pouvez également publier à l’aide de la ligne de commande MSBuild. Cela vous permet de configurer votre environnement de génération d’équipe pour inclure la publication dans un modèle d’intégration continue.

Pour plus d’informations, consultez Guide pratique pour déployer un projet d’application web à l’aide de One-Click publier et déployer web sur le site web MSDN et Publier web 1 clic avec VS 2010 sur le blog de Vishal Joshi. Pour afficher des présentations vidéo sur le déploiement d’applications web dans Visual Studio 2010, consultez VS 2010 for Web Developer Previews sur le blog de Vishal Joshi.

Ressources

Les sites web suivants fournissent des informations supplémentaires sur ASP.NET 4 et Visual Studio 2010.

ASP.NET 4 : documentation officielle de ASP.NET 4 sur le site Web MSDN.
https://www.asp.net/ — Site web de l’équipe ASP.NET.
https://www.asp.net/dynamicdata/ et ASP.NET carte de contenu de données dynamiques : ressources en ligne sur le site d’équipe ASP.NET et dans la documentation officielle pour ASP.NET données dynamiques.
https://www.asp.net/ajax/— Ressource web main pour ASP.NET développement Ajax.
https://devblogs.microsoft.com/dotnet/category/aspnet/ — Blog de l’équipe de développeur Visual Web, qui contient des informations sur les fonctionnalités de Visual Studio 2010.
ASP.NET WebStack : ressource Web main pour les versions préliminaires de ASP.NET.

Clause d'exclusion de responsabilité

Ce document est une version préliminaire et peut être modifié substantiellement avant le lancement de la mise en production commerciale finale du logiciel qu’il décrit.

Les informations contenues dans le présent document reflètent l'opinion de Microsoft Corporation sur les sujets abordés à la date de publication. Microsoft se doit de s'adapter aux conditions fluctuantes du marché, et cette opinion ne peut être considérée comme un engagement de sa part. Microsoft ne peut garantir la véracité de toute information présentée après la date de publication.

Ce livre blanc est fourni à titre d'information uniquement. MICROSOFT NE FOURNIT AUCUNE GARANTIE, EXPRESSE, IMPLICITE OU LÉGALE, QUANT AUX INFORMATIONS CONTENUES DANS CE DOCUMENT.

L’utilisateur est tenu d’observer la réglementation relative aux droits d’auteur applicable dans son pays. Aucune partie de ce document ne peut être reproduite, stockée ou introduite dans un système de restitution, ou transmise à quelque fin ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement ou autre) sans la permission expresse et écrite de Microsoft Corporation.

Les produits mentionnés dans ce document peuvent faire l'objet de brevets, de dépôts de brevets en cours, de marques, de droits d'auteur ou d'autres droits de propriété intellectuelle et industrielle de Microsoft. Sauf stipulation expresse contraire d'un contrat de licence écrit de Microsoft, la fourniture de ce document n'a pas pour effet de vous concéder une licence sur ces brevets, marques, droits d'auteur ou autres droits de propriété intellectuelle.

Sauf indication contraire, les exemples d’entreprises, d’organisations, de produits, de noms de domaine, d’adresses e-mail, de logos, de personnes, de lieux et d’événements représentés dans les présentes sont fictifs, et aucune association avec une société réelle, organization, produit, nom de domaine, adresse e-mail, logo, personne, lieu ou événement n’est prévue ou ne doit être déduite.

Microsoft et Windows sont soit des marques déposées de Microsoft Corporation, soit des marques de Microsoft Corporation aux États-Unis d'Amérique et/ou dans d'autres pays.

Les noms des sociétés et des produits mentionnés dans le présent document peuvent être des marques de leurs propriétaires respectifs.

Partager via

Vue d’ensemble de ASP.NET 4 et Visual Studio 2010 pour le développement web

Services de base

refactorisation de fichier Web.config

Mise en cache de sortie extensible

Démarrage automatique des applications web

Redirection permanente d’une page

Réduction de l’état de session

Extension de la plage d’URL autorisées

Validation des demandes extensibles

Mise en cache d’objets et extensibilité de mise en cache d’objets

Codage d’en-têtes HTTP, d’URL et d’URL extensibles

Analyse des performances pour des applications individuelles dans un processus de travail unique

Multi-ciblage

Ajax

jQuery inclus avec Web Forms et MVC

Prise en charge du réseau de distribution de contenu

Scripts explicites ScriptManager

Web Forms

Définition des balises meta avec les propriétés Page.MetaKeywords et Page.MetaDescription

Activation de l’état d’affichage pour les contrôles individuels

Modifications apportées aux fonctionnalités du navigateur

Utilisation des fournisseurs de fonctionnalités de navigateur

Remplacement de la fonctionnalité des fonctionnalités du navigateur ASP.NET

Mise en cache de l’objet HttpBrowserCapabilities

Extension des fonctionnalités du navigateur ASP.NET

Extension des fonctionnalités des fonctionnalités du navigateur en ajoutant de nouvelles fonctionnalités aux définitions de fonctionnalités existantes

Routage dans ASP.NET 4

Routage des pages Web Forms

Lecture des informations de routage dans une page de Web Forms

Accès aux informations de routage dans le balisage

Utilisation des données de routage pour les paramètres de contrôle de source de données

Définition des ID client

Création d’ID client prévisibles dans les contrôles Data-Bound

Persistance de la sélection de lignes dans les contrôles de données

contrôle graphique ASP.NET

Ajout du contrôle graphique à une page ASP.NET

Utilisation de graphiques 3D

Utilisation des sauts d’échelle et des échelles logarithmiques

Filtrage des données avec le contrôle QueryExtender

Rechercher

Plage

PropertyExpression

CustomExpression

Expressions de code encodées html

Modifications du modèle de projet

Modèle d’application web vide

Modèles d’application web et de projet de site web

Améliorations css

Paramètre de compatibilité pour le rendu

Désactivation des contrôles

Masquage d’éléments div autour de champs masqués

Rendu d’une table externe pour les contrôles modèle

Améliorations du contrôle ListView

Améliorations du contrôle CheckBoxList et RadioButtonList

Améliorations apportées au contrôle de menu

Assistant et Créer des contrôlesUserWizard

ASP.NET MVC

Prise en charge des zones

Prise en charge de la validation des attributs Data-Annotation

Helpers avec modèle

Dynamic Data

Activation des données dynamiques pour les projets existants

Syntaxe de contrôle DynamicDataManager déclarative

Modèles d’entité

Nouveaux modèles de champ pour les URL et les adresses Email

Création de liens avec le contrôle DynamicHyperLink

Prise en charge de l’héritage dans le modèle de données

Prise en charge des relations plusieurs-à-plusieurs (Entity Framework uniquement)

Nouveaux attributs pour contrôler l’affichage et la prise en charge des énumérations

Prise en charge améliorée des filtres

Améliorations apportées au développement web visual Studio 2010

Compatibilité CSS améliorée

Extraits de code HTML et JavaScript

Améliorations apportées à JavaScript IntelliSense

Déploiement d’applications web avec Visual Studio 2010

Empaquetage web

transformation Web.config

Déploiement de base de données

One-Click Publier pour les applications web