Nouveautés dans ASP.NET 4 et Visual Web Developer

Le .NET Framework version 4 inclut des améliorations pour ASP.NET 4 dans certains domaines ciblés. Visual Studio 2010 et Microsoft Visual Web Developer Express incluent également des améliorations et de nouvelles fonctionnalités pour un développement Web optimisé. Ce document fournit une vue d'ensemble des nombreuses fonctionnalités incluses dans la prochaine version.

Cette rubrique contient les sections suivantes :

ASP.NET 4 présente de nombreuses fonctionnalités qui améliorent les services ASP.NET principaux tels que la mise en cache de sortie et le stockage d'état de session.

Refactorisation du fichier Web.config

Le fichier Web.config qui contient les informations de configuration pour une application Web a grandi considérablement au fil des versions précédentes du .NET Framework au fur et à mesure que des nouvelles fonctionnalités ont été ajoutées. Dans le .NET Framework 4, les principaux éléments de configuration ont été déplacés vers le fichier machine.config, et les applications héritent désormais de ces paramètres. Cela permet au fichier Web.config des applications ASP.NET 4 d'être vide ou de spécifier uniquement la version de l'infrastructure que l'application cible, comme indiqué dans l'exemple suivant :

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

Mise en cache de sortie extensible

Depuis le lancement d'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. Lors des requêtes Web suivantes, ASP.NET peut servir plus rapidement le contenu en extrayant la sortie générée de la mémoire au lieu de la générer de nouveau ex nihilo. Toutefois, cette approche a des limites : le contenu généré doit toujours être stocké en mémoire. Sur les serveurs sur lesquels le trafic est très dense, les besoins en mémoire pour la mise en cache de sortie peuvent compromettre ceux d'autres parties d'une application Web.

ASP.NET 4 renforce l'extensibilité de la mise en cache de sortie, ce qui vous permet de configurer un ou plusieurs fournisseurs de cache de sortie personnalisés. Les fournisseurs de cache de sortie peuvent utiliser un mécanisme de stockage pour rendre le contenu HTML persistant. Ces options de stockage peuvent inclure des disques locaux ou distants, un stockage en nuage et des moteurs de cache distribués.

L'extensibilité des fournisseurs de cache de sortie dans ASP.NET 4 vous permet de concevoir des stratégies de mise en cache de sortie plus agressives et plus intelligentes pour les sites Web. Par exemple, vous pouvez créer un fournisseur de cache de sortie qui met en mémoire cache les 10 pages les plus visitées d'un site, tous en mettant en cache les pages dont le trafic est plus faible sur un disque. Vous pouvez également mettre en cache chaque variation de combinaison pour une page rendue, mais utiliser un cache distribué afin de décharger la consommation de mémoire des serveurs Web frontaux.

Vous créez un fournisseur de cache de sortie personnalisé en tant que classe qui dérive du type OutputCacheProvider. Vous pouvez ensuite configurer le fournisseur dans le fichier Web.config à l'aide de la nouvelle sous-section providers de l'élément outputCache.

Pour plus d'informations et pour obtenir des exemples qui indiquent comment configurer le cache de sortie, consultez outputCache, élément de caching (Schéma des paramètres ASP.NET). Pour plus d'informations sur les classes qui prennent en charge la mise en cache, consultez la documentation des classes OutputCache et OutputCacheProvider.

Par défaut, dans ASP.NET 4, toutes les réponses HTTP, pages rendues et contrôles utilisent le cache de sortie en mémoire. L'attribut defaultProvider pour ASP.NET est AspNetInternalProvider. Vous pouvez modifier le fournisseur de cache de sortie par défaut utilisé pour une application Web en spécifiant un nom de fournisseur différent pour l'attribut defaultProvider.

De plus, vous pouvez sélectionner des fournisseurs de cache de sortie différents pour un contrôle individuel et des requêtes individuelles, et spécifier par programmation le fournisseur à utiliser. Pour plus d'informations, consultez la méthode HttpApplication.GetOutputCacheProviderName(HttpContext). La façon la plus simple de choisir un fournisseur de cache de sortie différent pour des contrôles utilisateur Web différents consiste à le faire de façon déclarative en utilisant le nouvel attribut providerName dans une page ou une directive de contrôle, comme indiqué dans l'exemple suivant :

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

Applications Web à démarrage automatique

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

Pour ce scénario, une nouvelle fonctionnalité de démarrage automatique est disponible lorsqu'ASP.NET 4 s'exécute sur IIS 7.5, sur Windows Server 2008 R2. La fonctionnalité fournit une approche contrôlée pour le démarrage d'un pool d'applications, l'initialisation d'une application ASP.NET et l'acceptation des requêtes HTTP. Elle vous permet d'effectuer l'initialisation coûteuse des applications avant de traiter la première requête HTTP.

Pour plus d'informations sur la fonctionnalité de démarrage automatique, consultez What's New for ASP.NET 4 White Paper.

Redirection définitive d'une page

Le contenu d'une application Web est souvent déplacé pendant la durée de vie de l'application. Ces déplacements peuvent rendre des liens obsolètes, notamment les liens retournés par les moteurs de recherche.

Dans ASP.NET, les développeurs ont traditionnellement géré les requêtes d'URL anciennes à l'aide de la méthode Redirect pour transférer une requête à la nouvelle URL. Toutefois, la méthode Redirect émet une réponse HTTP 302 (Trouvé) (laquelle est utilisée pour une redirection temporaire). Cela engendre un aller-retour HTTP supplémentaire.

ASP.NET 4 ajoute une méthode d'assistance RedirectPermanent qui facilite l'émission de réponses HTTP 301 (Déplacement définitif), comme indiqué dans l'exemple suivant :

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

Les moteurs de recherche et d'autres agents utilisateurs qui reconnaissent les redirections définitives stockent la nouvelle URL associée au contenu, ce qui élimine l'aller-retour inutile effectué par le navigateur pour les redirections temporaires.

Compression de l'état de session

Par défaut, ASP.NET fournit deux options de stockage de l'état de session dans une batterie de serveurs Web. La première option est un fournisseur d'état de session qui appelle un serveur d'état de session hors processus. La seconde option est 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 stockent les informations d'état en dehors du processus de travail d'une application Web, l'état de session doit être sérialisé avant d'être envoyé au stockage étendu. Si une grande quantité de données est enregistrée dans l'état de session, la taille des données sérialisées peut devenir considérable.

ASP.NET 4 présente une nouvelle option de compression pour ces deux genres de fournisseurs d'état de session hors processus. En utilisant cette option, les applications qui ont des cycles processeur de rechange sur les serveurs Web peuvent réduire considérablement la taille des données d'état de session sérialisées.

Vous pouvez définir cette option à l'aide du nouvel attribut compressionEnabled de l'élément sessionState dans le fichier de configuration. Lorsque l'option de configuration compressionEnabled a la valeur true, ASP.NET compresse (et décompresse) l'état de session sérialisé à l'aide de la classe GZipStream du .NET Framework .

Développement de la plage d'URL autorisées

ASP.NET 4 présente de nouvelles options pour le développement de la taille des URL d'application. Les versions antérieures d'ASP.NET limitaient la longueur de chemin d'accès de l'URL à 260 caractères, selon la limite de chemin d'accès de fichier NTFS. Dans ASP.NET 4, vous avez la possibilité d'augmenter (ou de diminuer) cette limite en fonction de vos applications, grâce à deux nouveaux attributs de l'élément de configuration httpRuntime. L'exemple suivant montre l'utilisation de ces nouveaux attributs.

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

ASP.NET 4 vous permet également de configurer les caractères utilisés par la vérification des caractères d'URL. Lorsqu'ASP.NET trouve un caractère non valide dans la partie de chemin d'accès d'une URL, il rejette la requête et émet un code d'état HTTP 400 (Requête incorrecte). Dans les versions précédentes d'ASP.NET, la vérification des caractères d'URL était limitée à un ensemble fixe de caractères. Dans ASP.NET 4, vous pouvez personnaliser l'ensemble de caractères valides à l'aide du nouvel attribut requestPathInvalidChars de l'élément de configuration httpRuntime, comme le montre l'exemple suivant :

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

(Dans la chaîne assignée par défaut à requestPathInvalidChars, les caractères inférieur à (<), supérieur à (>) et perluète (&) sont encodés car fichier Web.config est un fichier XML.) Par défaut, l'attribut requestPathInvalidChars définit huit caractères comme non valides.

RemarqueRemarque

ASP.NET 4 rejette toujours les chemins d'accès d'URL qui contiennent des caractères de la plage ASCII comprise entre 0x00 et 0x1F, car il s'agit des caractères d'URL non valides comme définis dans le document RFC 2396 de l'IETF (consultez http://www.ietf.org/rfc/rfc2396.txt sur le site Web IETF). Sous les versions de Windows Server qui exécutent IIS 6 ou version ultérieure, le pilote de périphérique de protocole http.sys rejette automatiquement les URL qui contiennent ces caractères.

La validation de la requête ASP.NET recherche des chaînes couramment utilisées pour les attaques des scripts intersites (XSS) dans les données de requêtes HTTP entrantes. Si les chaînes XSS potentielles sont trouvées, la validation de la requête signale la chaîne suspecte et retourne une erreur. La validation de la requête intégrée retourne une erreur uniquement lorsqu'elle trouve les chaînes les plus communément utilisées dans les attaques XSS. Des tentatives préalables pour rendre la validation XSS plus agressive ont retourné un nombre de faux positifs trop élevé. Toutefois, vous pouvez souhaiter que la validation de la requête soit plus agressive. Inversement, vous pouvez souhaiter assouplir intentionnellement les contrôles XSS pour des pages spécifiques ou pour des types de requêtes spécifiques.

Dans ASP.NET 4, la fonctionnalité de validation de la requête a été rendue extensible afin que vous puissiez utiliser la logique de validation de la requête personnalisée. Pour étendre la validation de la requête, vous devez créer une classe qui dérive de la nouvelle classe System.Web.Util.RequestValidator, et configurer l'application pour qu'elle utilise le type personnalisé (dans la section httpRuntime du fichier Web.config). Pour plus d'informations, consultez System.Web.Util.RequestValidator.

Mise en cache d'objets et extensibilité de la mise en cache d'objets

Depuis sa première version, ASP.NET inclut un cache d'objets en mémoire puissant (System.Web.Caching.Cache). L'implémentation de cache a eu un tel succès qu'elle est utilisé dans les applications non-Web. Toutefois, il est maladroit qu'un formulaire Windows Forms ou une application WPF inclue une référence à System.Web.dll seulement pour pouvoir utiliser le cache d'objets ASP.NET. Pour rendre la mise en cache disponible pour toutes les applications, le .NET Framework 4 présente un nouvel assembly, un nouvel espace de noms, quelques types de base et une implémentation de mise en cache concrète. Le nouvel assembly System.Runtime.Caching.dll contient une nouvelle API de mise en cache dans l'espace de noms System.Runtime.Caching. L'espace de noms contient deux principaux ensembles de classes :

  • des types abstraits qui fournissent la base de la génération de n'importe quel type d'implémentation de cache personnalisée ;

  • une implémentation de cache d'objets en mémoire concrète (classe MemoryCache ).

La nouvelle classe MemoryCache s'inspire très largement du cache ASP.NET, et partage une grande partie de la logique de moteur de cache interne avec ASP.NET. Bien que les API de mise en cache publiques de l'espace de noms 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 d'ASP.NET, vous retrouverez des concepts qui vous sont familiers dans les nouvelles API.

Encodage HTML, URL et d'en-têtes HTTP extensible

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

  • Encodage HTML.

  • Encodage URL.

  • Encodage d'attribut HTML.

  • Encodage d'en-têtes HTTP sortants.

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

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

Une fois un encodeur personnalisé configuré, ASP.NET appelle automatiquement l'implémentation d'encodage personnalisée à chaque fois que les méthodes d'encodage publiques des classes HttpUtility ou HttpServerUtility sont appelées. Une partie d'une équipe de développement Web peut ainsi créer un encodeur personnalisé qui implémente le codage de caractères agressif, alors que le reste de l'équipe de développement Web continue à 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 certain que tous les appels d'encodage de texte provenant des API d'encodage ASP.NET publiques sont routés via l'encodeur personnalisé.

Analyse des performances d'applications individuelles d'un processus de travail unique

Afin d'augmenter le nombre de sites Web pouvant être hébergés sur un même serveur, de nombreux hébergeurs exécutent plusieurs applications ASP.NET dans un seul processus de travail. Toutefois, si plusieurs applications utilisent un même processus de travail partagé, les administrateurs du serveur peuvent avoir du mal à identifier une application qui rencontre des problèmes.

ASP.NET 4 tire parti des nouvelles fonctionnalités d'analyse des ressource présentées dans le CLR. Pour activer ces fonctionnalités, vous pouvez ajouter l'extrait de code de configuration XML suivant au fichier de configuration aspnet.config.

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

(Le fichier aspnet.config se trouve dans le répertoire d'installation du .NET Framework. Il ne s'agit pas du fichier Web.config d'application.) Lorsque la fonction appDomainResourceMonitoring a été activée, deux nouveaux compteurs de performance sont disponibles dans la catégorie de performance « ASP.NET Applications »: % Managed Processor Time et Managed Memory Used. Ces deux compteurs de performance utilisent la nouvelle fonctionnalité de gestion des ressources du domaine d'application du CLR pour effectuer le suivi du temps processeur estimé et de l'utilisation de la mémoire managée de chaque application ASP.NET. Par conséquent, avec ASP.NET 4, les administrateurs ont désormais une vue plus détaillée de la consommation de ressources de chaque application exécutée dans un même processus de travail.

jQuery dans les Web Forms et MVC

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

  • jQuery-1.4.1.js : version explicite et non réduite de la bibliothèque jQuery. (La réduction consiste à supprimer les caractères inutiles du code pour en réduire la taille et ainsi améliorer les temps de charge et d'exécution.)

  • jQuery-14.1.min.js : version réduite de la bibliothèque jQuery.

  • jQuery-1.4.1-vsdoc.js : fichier de documentation IntelliSense pour la bibliothèque jQuery.

Incluez la version non réduite de jQuery pendant que vous développez une application. Incluez la version réduite de la bibliothèque jQuery pour les applications de production.

Prise en charge du réseau de distribution de contenu

Le réseau de distribution de contenu (CDN) Microsoft Ajax permet d'ajouter facilement des scripts ASP.NET Ajax et jQuery à vos applications Web. Par exemple, vous pouvez commencer à utiliser la bibliothèque jQuery simplement en ajoutant un élément script à votre page qui pointe vers Ajax.microsoft.com, comme indiqué dans l'exemple suivant :

<script src="http://ajax.microsoft.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 qui sont répartis à travers le monde. 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 CDN Microsoft Ajax prend en charge le protocole SSL (https://) au cas où vous deviez traiter une page Web qui utilise le protocole SSL.

Le contrôle ScriptManager ASP.NET prend en charge le CDN Microsoft Ajax. Définissez la propriété EnableCdn comme indiqué dans l'exemple suivant pour extraire du CDN tous les fichiers JavaScript de l'infrastructure ASP.NET :

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

Lorsque la propriété EnableCdn a la valeur true, l'infrastructure ASP.NET extrait du CDN tous les fichiers JavaScript de l'infrastructure ASP.NET, notamment tous les fichiers JavaScript utilisés pour la validation et pour le contrôle UpdatePanel. Cela peut avoir un impact considérable sur la performance de votre application Web.

Vous pouvez définir le chemin d'accès du CDN pour vos propres fichiers JavaScript à l'aide de l'attribut WebResourceAttribute. La nouvelle propriété CdnPath spécifie le chemin d'accès du CDN utilisé lorsque vous affectez la valeur true à la propriété EnableCdn, comme le montre l'exemple suivant :

[assembly: WebResource("Example.js", "application/x-javascript", CdnPath ="http://contoso.com/app/site/Example.js")]

Pour plus d'informations sur le CDN Microsoft Ajax, consultez Microsoft Ajax Content Delivery Network sur le site Web ASP.NET.

Scripts explicites ScriptManager

Si vous avez utilisé l'élément ScriptManager ASP.NET dans les versions antérieures d'ASP.NET, votre application Web devait charger l'intégralité de la bibliothèque ASP.NET Ajax. En tirant parti de la nouvelle propriété AjaxFrameworkMode, vous pouvez contrôler exactement quels composants de la bibliothèque ASP.NET Ajax sont chargés. Pour plus d'informations, consultez la propriété AjaxFrameworkMode.

Web Forms est une fonctionnalité principale d'ASP.NET depuis ASP.NET 1.0. De nombreuses améliorations ont été effectuées dans ce domaine pour ASP.NET 4, notamment celles qui suivent :

  • Capacité de définir des balises meta.

  • Meilleur contrôle de l'état d'affichage.

  • Prise en charge des navigateurs et des appareils récemment sortis.

  • Plus grande facilité d'utilisation des fonctionnalités de navigateur.

  • Prise en charge de l'utilisation du routage ASP.NET avec Web Forms.

  • Meilleur contrôle sur les ID générés.

  • Capacité de rendre les lignes sélectionnées persistantes dans les contrôles de données.

  • Meilleur contrôle sur le HTML rendu dans les contrôles FormView et ListView.

  • Prise en charge du filtrage pour les contrôles de source de données.

  • Prise en charge améliorée des normes Web et de l'accessibilité

  • Modifications du modèle du projet.

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

Deux propriétés ont été ajoutées à la classe Page : MetaKeywords et MetaDescription. Ces deux propriétés représentent les balises meta correspondantes dans le HTML rendu pour une page, comme indiqué dans l'exemple suivant :

<head id="Head1" runat="server">
  <title>Untitled Page</title>
  <meta name="keywords" content="keyword1, keyword2' />
  <meta name="description" content="Description of my page" />
</head>

Ces deux propriétés fonctionnent comme la propriété Title et peuvent être définies dans la directive @ Page. Pour plus d'informations, consultez Page.MetaKeywords et Page.MetaDescription.

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

Une nouvelle propriété a été ajoutée à la classe Control : ViewStateMode. Vous pouvez utiliser cette propriété pour désactiver l'état d'affichage pour tous les contrôles d'une page sauf ceux pour lesquels vous activez explicitement l'état d'affichage.

Les données d'état d'affichage sont incluses dans le HTML d'une page et augmentent le délai d'envoi d'une page au client et sa publication (postback). Le fait de stocker davantage d'état d'affichage qu'il n'est nécessaire peut engendrer une baisse significative des performances. Dans les versions antérieures d'ASP.NET, vous pouviez réduire l'impact de l'état d'affichage sur les performances d'une page en désactivant l'état d'affichage pour des contrôles spécifiques. Mais parfois, il est plus facile d'activer l'état d'affichage pour certains contrôles qui en ont besoin, plutôt que de le désactiver pour les nombreux contrôles qui n'en ont pas besoin.

Pour plus d'informations, consultez Control.ViewStateMode.

Prise en charge des navigateurs et des appareils récemment sortis

ASP.NET inclut une fonction nommée fonctionnalités de navigateur qui vous permet de déterminer les fonctionnalités du navigateur de l'utilisateur. Les fonctionnalités de navigateur sont représentées par l'objet HttpBrowserCapabilities stocké dans la propriété HttpRequest.Browser. Les informations relatives aux fonctionnalités d'un navigateur particulier sont définies par un fichier de définition de navigateur. Dans ASP.NET 4, ces fichiers de définition de navigateur ont été mis à jour pour contenir des informations sur les navigateurs et appareils récents tels que Google Chrome, Research dans les téléphones de type smartphone Motion BlackBerry et Apple iPhone. Les fichiers de définition de navigateur existants ont également été mis à jour. Pour plus d'informations, consultez Comment : mettre à niveau une application Web ASP.NET vers ASP.NET 4 et Fonctionnalités des contrôles serveur Web ASP.NET et du navigateur.

Les fichiers de définition de navigateur inclus dans ASP.NET 4 figurent dans la liste suivante :

•blackberry.browser

•chrome.browser

•Default.browser

•firefox.browser

•gateway.browser

•generic.browser

•ie.browser

•iemobile.browser

•iphone.browser

•opera.browser

•safari.browser

Une nouvelle façon de définir des fonctionnalités de navigateur

ASP.NET 4 inclut une nouvelle fonctionnalité appelée fournisseurs de fonctionnalités de navigateur. Comme son nom le suggère, cette fonctionnalité vous permet de créer un fournisseur qui à son tour vous permet d'écrire du code personnalisé pour déterminer des fonctionnalités de navigateur.

Dans ASP.NET version 3.5 Service Pack 1, vous définissez des fonctionnalités de navigateur dans un fichier XML. Ce fichier réside dans un dossier au niveau de l'ordinateur ou un dossier au niveau de l'application. La plupart des développeurs n'ont pas besoin de personnaliser ces fichiers, mais pour ceux qui ont besoin de le faire, l'approche du fournisseur peut s'avérer plus facile que la gestion d'une syntaxe XML complexe. L'approche du fournisseur permet de simplifier le processus en implémentant une syntaxe de définition de navigateur commune ou une base de données qui contient des définitions de navigateur à jour, ou même un service Web pour une telle base de données.

Pour plus d'informations sur le nouveau fournisseur de fonctionnalités de navigateur, consultez Nouveautés du livre blanc ASP.NET 4.

Routage dans ASP.NET 4

ASP.NET 4 renforce la prise en charge intégrée du routage à l'aide de Web Forms. Le routage est une fonctionnalité introduite dans ASP.NET 3.5 SP1 qui vous permet de configurer une application afin d'utiliser des URL explicites pour les utilisateurs et les moteurs de recherche parce qu'elles n'ont pas à spécifier des noms de fichiers physiques. Cette fonctionnalité peut rendre votre site plus convivial et votre contenu plus détectable par les moteurs de recherche.

Par exemple, l'URL d'une page qui affiche des catégories de produits dans votre application peut ressembler à l'exemple suivant :

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

En utilisant le routage, vous pouvez utiliser l'URL suivante pour rendre les mêmes informations :

http://website/products/software

La deuxième URL permet à l'utilisateur de savoir à quoi s'attendre et peut donner des classements considérablement améliorés dans les résultats des moteurs de recherche.

Les nouvelles fonctionnalités incluent les suivantes :

  • La classe PageRouteHandler est un gestionnaire HTTP simple que vous utilisez lorsque vous définissez des itinéraires. Vous ne devez plus écrire un gestionnaire d'itinéraires personnalisé.

  • Les propriétés HttpRequest.RequestContext et Page.RouteData facilitent l'accès aux informations passées dans les paramètres d'URL.

    • L'expression RouteUrl offre un moyen simple de créer une URL routée dans le balisage.

    • L'expression The RouteValue offre un moyen simple d'extraire des valeurs de paramètres d'URL dans le balisage.

  • La classe RouteParameter facilite le passage de valeurs de paramètres d'URL à une requête pour un contrôle de source de données (semblable à FormParameter).

  • Vous ne devez plus modifier le fichier Web.config pour activer le routage.

Pour plus d'informations sur le routage, consultez les rubriques suivantes :

Définition d'ID clients

La nouvelle propriété ClientIDMode facilite l'écriture d'un script client qui fait référence à des éléments HTML rendus pour des contrôles serveur. L'augmentation de l'utilisation de Microsoft Ajax rend le besoin de procéder ainsi plus courant. Par exemple, vous pouvez avoir un contrôle de données qui rend une longue liste de produits accompagnés de leur prix et souhaiter utiliser le script client pour effectuer un appel de service Web afin de mettre à jour des prix individuels dans la liste à mesure qu'ils changent sans actualiser la page entière.

En général, vous obtenez une référence à un élément HTML dans le script client à l'aide de la méthode document.GetElementById. Vous passez à cette méthode la valeur de l'attribut id de l'élément HTML que vous souhaitez référencer. Dans le cas d'éléments rendus pour des contrôles serveur ASP.NET, les versions antérieures d'ASP.NET risquent de rendre cette opération difficile ou impossible. Vous ne pouviez pas toujours prévoir quelles valeurs d'ID ASP.NET générerait, ou ASP.NET pouvait générer des valeurs d'ID très longues. Le problème s'avérait particulièrement difficile pour les contrôles de données qui généraient plusieurs lignes pour une instance unique du contrôle dans votre balisage.

ASP.NET 4 ajoute deux nouveaux algorithmes pour la génération d'attributs id. Ces algorithmes peuvent générer des attributs id plus faciles à utiliser dans le script client parce qu'ils sont plus prédictibles et plus simples, donc plus faciles à utiliser. Pour plus d'informations sur l'utilisation des nouveaux algorithmes, consultez les rubriques suivantes :

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

Les contrôles GridView et ListView permettent aux utilisateurs de sélectionner une ligne. Dans les versions antérieures d'ASP.NET, la sélection de ligne se basait sur l'index de ligne dans la page. Par exemple, si vous sélectionnez le troisième élément dans la page 1, puis accédez à la page 2, le troisième élément dans la page 2 est sélectionné. Dans la plupart des cas, il est plus souhaitable de ne pas sélectionner de lignes dans la page 2. ASP.NET 4 prend en charge la sélection rendue persistante, une nouvelle fonctionnalité qui était initialement prise en charge uniquement dans les projets Dynamic Data dans le .NET Framework 3.5 SP1. Lorsque cette fonctionnalité est activée, l'élément sélectionné est basé sur la clé de données de ligne. Cela signifie que si vous sélectionnez la troisième ligne dans la page 1, puis accédez à la page 2, rien n'est sélectionné dans la page 2. Lorsque vous revenez à la page 1, la troisième ligne est encore sélectionnée. Il s'agit d'un comportement beaucoup plus naturel que le comportement dans les versions antérieures d'ASP.NET. La sélection rendue persistante est maintenant prise en charge pour les contrôles GridView et ListView dans tous les projets. Vous pouvez activer cette fonctionnalité dans le contrôle GridView, par exemple, en définissant la propriété EnablePersistedSelection, comme indiqué dans l'exemple suivant :

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

Améliorations du contrôle FormView

Le contrôle FormView est amélioré afin de faciliter la stylisation du contenu du contrôle à l'aide de CSS. Dans les versions antérieures d'ASP.NET, le contrôle FormView rendait son contenu à l'aide d'un modèle d'élément. Cela rendait la stylisation plus difficile dans le balisage parce que des balises de ligne et de cellule de table inattendues étaient rendues par le contrôle. Le contrôle FormView prend en charge la propriété RenderOuterTable, une propriété dans ASP.NET 4. Lorsque cette propriété a la valeur false, comme indiqué dans l'exemple suivant, les balises de table ne sont pas rendues. Cela peut faciliter l'application du style CSS au contenu du contrôle.

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

Pour plus d'informations, consultez Vue d'ensemble du contrôle serveur Web FormView.

Améliorations du contrôle ListView

Le contrôle ListView, introduit dans ASP.NET 3.5, possède toutes les fonctionnalités du contrôle GridView tout en vous donnant un contrôle total sur la sortie. Ce contrôle a été rendu plus facile à utiliser dans ASP.NET 4. La version antérieure du contrôle exigeait la spécification d'un modèle de mise en page qui contenait un contrôle serveur doté d'un ID connu. Le balisage suivant présente 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 requiert pas de modèle de mise en page. Le balisage indiqué dans l'exemple précédent peut être remplacée par le balisage suivant :

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

Pour plus d'informations, consultez Vue d'ensemble du contrôle serveur Web ListView.

Filtrage de données avec le contrôle QueryExtender

Le filtrage des données est une tâche très courante pour les développeurs qui créent des pages Web pilotées par des données. Cette tâche s'effectue traditionnellement en générant des clauses Where dans les contrôles de source de données. Cette approche peut s'avérer compliquée, et dans certains cas la syntaxe Where ne vous permet pas de tirer parti des fonctionnalités complètes de la base de données sous-jacente.

Pour simplifier le filtrage, un nouveau contrôle QueryExtender a été ajouté dans ASP.NET 4. Ce contrôle peut être ajouté à des contrôles EntityDataSource ou LinqDataSource pour filtrer les données qu'ils retournent. Le contrôle QueryExtender repose sur LINQ, mais il n'est pas nécessaire de savoir comment écrire des requêtes LINQ pour utiliser l'extendeur de requête.

Le contrôle QueryExtender prend en charge diverses options de filtrage. Voici la liste des options de filtrage QueryExtender.

Terme

Définition

SearchExpression

Recherche des valeurs de chaîne dans un champ ou des champs et les compare à une valeur de chaîne spécifiée.

RangeExpression

Recherche des valeurs incluses dans une plage spécifiée par une paire de valeurs dans un ou plusieurs champs.

PropertyExpression

Compare une valeur spécifiée à une valeur de propriété dans un champ. Si l'expression prend la valeur true, les données en cours d'examen sont retournées.

OrderByExpression

Trie des données selon une colonne et un sens de tri spécifiés.

CustomExpression

Appelle une fonction qui définit un filtre personnalisé dans la page.

Pour plus d'informations, consultez QueryExtenderVue d'ensemble du contrôle serveur Web QueryExtender.

Prise en charge améliorée des normes Web et de l'accessibilité

Les versions antérieures des contrôles ASP.NET rendent parfois un balisage non conforme aux normes HTML, XHTML ou d'accessibilité. ASP.NET 4 élimine la plupart de ces exceptions.

Pour plus d'informations sur la satisfaction des normes d'accessibilité par le HTML rendu par chaque contrôle, consultez Contrôles et accessibilité ASP.NET.

CSS pour les contrôles désactivables

Dans ASP.NET 3.5, lorsqu'un contrôle est désactivé (consultez WebControl.Enabled), un attribut disabled est ajouté à l'élément HTML rendu. Par exemple, le balisage suivant crée un contrôle Label qui est désactivé :

<asp:Label id="Label1" runat="server"

  Text="Test" Enabled="false" />

Dans ASP.NET 3.5, les paramètres du contrôle précédent génèrent le HTML suivant :

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

En langage HTML 4.01, l'attribut disabled n'est pas considéré comme valide sur les éléments span. Il est uniquement valide sur les éléments input parce qu'il spécifie qu'ils ne sont pas accessibles. Pour les éléments en mode affichage uniquement tels que les éléments span, les navigateurs prennent généralement en charge le rendu d'un aspect désactivé, mais une page Web qui se repose sur ce comportement non standard n'est pas fiable d'après les normes d'accessibilité.

Pour les éléments en mode affichage uniquement, vous devez utiliser CSS pour indiquer un aspect visuel désactivé. Par conséquent, ASP.NET 4 génère par défaut le HTML suivant pour les paramètres du contrôle mentionné précédemment :

<span id="Label1" class="aspNetDisabled">Test</span>

Vous pouvez modifier la valeur de l'attribut class rendu par défaut lorsqu'un contrôle est désactivé en définissant la propriété DisabledCssClass.

CSS pour les contrôles de validation

Dans ASP.NET 3.5, les contrôles de validation rendent la couleur par défaut red sous la forme d'un style intraligne. Par exemple, le balisage suivant crée un contrôle RequiredFieldValidator :

<asp:RequiredFieldValidator ID="RequiredFieldValidator1" runat="server"

  ErrorMessage="Required Field" ControlToValidate="RadioButtonList1" />

ASP.NET 3.5 rend le HTML suivant pour le contrôle du validateur :

<span id="RequiredFieldValidator1"

  style="color:Red;visibility:hidden;">RequiredFieldValidator</span>

Par défaut, ASP.NET 4 ne rend pas de style intraligne pour définir la couleur rouge. Un style intraligne est utilisé uniquement pour masquer ou afficher le validateur, comme indiqué dans l'exemple suivant :

<span id="RequiredFieldValidator1"

  style"visibility:hidden;">RequiredFieldValidator</span>

Par conséquent, ASP.NET 4 n'affiche pas automatiquement les messages d'erreur en rouge. Pour plus d'informations sur l'utilisation de CSS pour spécifier un style visuel pour un contrôle de validation, consultez Validation des entrées d'utilisateur dans des pages Web ASP.NET.

CSS pour l'élément div des champs masqués

ASP.NET utilise des champs masqués pour stocker des informations d'état telles que l'état d'affichage et l'état du contrôle. Ces champs masqués sont contenus par un élément div. Dans ASP.NET 3.5, cet élément div n'a pas d'attribut class ni d'attribut id. Par conséquent, les règles CSS qui affectent tous les éléments div peuvent provoquer involontairement la visibilité de cet élément div. Pour éviter ce problème, ASP.NET 4 rend l'élément div pour les champs masqués avec une classe CSS que vous pouvez utiliser pour différencier les champs masqués div des autres champs. La valeur de la nouvelle classe est illustrée dans l'exemple suivant :

<div class="aspNetHidden">

CSS pour les contrôles Table, Image et ImageButton

Par défaut, dans ASP.NET 3.5, certains contrôles affectent à l'attribut border du HTML rendu la valeur zéro (0). L'exemple suivant montre le HTML généré par le contrôle Table dans ASP.NET 3.5 :

<table id="Table2" border="0">

Les contrôles Image et ImageButton procèdent également ainsi. Étant donné que cette opération n'est pas nécessaire et qu'elle fournit des informations de mise en forme visuelle qui devraient être fournies à l'aide de CSS, l'attribut n'est pas généré dans ASP.NET 4.

CSS pour les contrôles UpdatePanel et UpdateProgress

Dans ASP.NET 3.5, les contrôles UpdatePanel et UpdateProgress ne prennent pas en charge les attributs expando. Il est donc impossible de définir une classe CSS sur les élémentsHTML dont ils effectuent le rendu. Dans ASP.NET 4, ces contrôles ont été modifiés afin d'accepter les attributs expando, comme indiqué dans l'exemple suivant :

<asp:UpdatePanel runat="server" class="myStyle">

</asp:UpdatePanel>

Le HTML suivant est rendu pour ce balisage :

<div id="ctl00_MainContent_UpdatePanel1" class="expandoclass">

</div>

Suppression de tables externes inutiles

Dans ASP.NET 3.5, le HTML rendu pour les contrôles suivants est inclus dans un wrapper dans un élément table dont l'objectif est d'appliquer des styles intralignes au contrôle entier :

Si vous utilisez des modèles pour personnaliser l'apparence de ces contrôles, vous pouvez spécifier des styles CSS dans le balisage que vous fournissez dans les modèles. Dans ce cas, aucune table externe supplémentaire n'est requise. Dans ASP.NET 4, vous pouvez empêcher le rendu de la table en affectant à la nouvelle propriété RenderOuterTable la valeur false.

Modèles de disposition pour les contrôles d'Assistants

Dans ASP.NET 3.5, les contrôles Wizard et CreateUserWizard génèrent un élément table HTML utilisé pour la mise en forme visuelle. Dans ASP.NET 4 vous pouvez utiliser un élément LayoutTemplate pour spécifier la disposition. Dans ce cas, l'élément HTML table n'est pas généré. Dans ce modèle, vous créez des contrôles d'espace réservé pour indiquer à quel emplacement les éléments doivent être insérés dynamiquement dans le contrôle. (ce modèle est similaire au modèle du contrôle ListView) Pour plus d'informations, consultez la propriété Wizard.LayoutTemplate.

Nouvelles options de mise en forme HTML pour les contrôles CheckBoxList et RadioButtonList

ASP.NET 3.5 utilise des éléments de table HTML pour mettre en forme la sortie des contrôles CheckBoxList et RadioButtonList. Pour fournir une alternative qui n'utilise pas de tables pour la mise en forme visuelle, ASP.NET 4 ajoute deux nouvelles options à l'énumération RepeatLayout :

  • UnorderedList . Cette option engendre la mise en forme de la sortie HTML à l'aide d'éléments ul et li plutôt que d'une table.

  • OrderedList . Cette option engendre la mise en forme de la sortie HTML à l'aide d'éléments ol et li plutôt que d'une table.

Pour obtenir des exemples de rendu du HTML pour les nouvelles options, consultez l'énumération RepeatLayout.

Éléments Header et Footer pour le contrôle Table

Dans ASP.NET 3.5, le contrôle Table peut être configuré pour effectuer le rendu d'éléments thead et tfoot en affectant à la propriété TableSection la classe TableHeaderRow et la classe TableFooterRow. Dans ASP.NET 4, ces propriétés ont les valeurs appropriées par défaut.

CSS et prise en charge ARIA pour le contrôle Menu

Dans ASP.NET 3.5, le contrôle Menu utilise des éléments table HTML pour la mise en forme visuelle, et dans certaines configurations, il n'est pas accessible par clavier. ASP.NET 4 remédie à ces problèmes et améliore l'accessibilité des façons suivantes :

  • Le code HTML généré est structuré sous forme de liste non triée (éléments ul et li).

  • CSS est utilisée pour la mise en forme visuelle.

  • Le menu se comporte conformément aux normes ARIA pour l'accès au clavier. Vous pouvez utiliser les touches de direction pour parcourir les éléments de menu. (Pour plus d'informations sur ARIA, consultez Accessibilité dans Visual Studio et ASP.NET.)

  • Les attributs de propriété et de rôle ARIA sont ajoutés au code HTML généré. (Des attributs sont ajoutés en utilisant JavaScript plutôt qu'inclus dans le HTML, pour éviter de générer du code HTML qui provoquerait des erreurs de validation de balisage.)

Le rendu des styles pour le contrôle Menu est effectué dans un bloc style en haut de la page, plutôt qu'entre les lignes des éléments HTML rendus. Si vous souhaitez utiliser un fichier CSS distinct afin de pouvoir modifier les styles de menu, vous pouvez affecter à la nouvelle propriété IncludeStyleBlock du contrôle Menu la valeur false ; dans ce cas, le bloc de style n'est pas généré.

XHTML valide pour le contrôle HtmlForm

Dans ASP.NET 3.5, le contrôle HtmlForm (lequel est créé implicitement par la balise <form runat="server">) effectue le rendu d'un élément form HTML qui possède à la fois des attributs name et id. L'attribut name est déconseillé en XHTML 1.1. Par conséquent, ce contrôle n'effectue pas le rendu de l'attribut name dans ASP.NET 4.

Conservation de la compatibilité descendante dans le rendu de contrôle

Un site Web ASP.NET existant peut comporter du code qui suppose que les contrôles effectuent le rendu du code HTML comme ils le font dans ASP.NET 3.5. Pour éviter de provoquer des problèmes de compatibilité descendante lorsque vous mettez à niveau le site vers ASP.NET 4, ASP.NET peut continuer à générer le code HTML comme il le fait dans ASP.NET 3.5 après la mise à niveau du site. Pour ce faire, vous pouvez affecter à l'attribut controlRenderingCompatibilityVersion de l'élément pages la valeur « 3.5 » dans le fichier Web.config d'un site Web ASP.NET 4, comme indiqué dans l'exemple suivant :

<system.web>

  <pages controlRenderingCompatibilityVersion="3.5"/>

</system.web>

Si ce paramètre est omis, la valeur par défaut est la même que la version d'ASP.NET que le site Web cible. (Pour plus d'informations sur le multi-ciblage dans ASP.NET, consultez Multi-ciblage du .NET Framework pour les projets Web ASP.NET.)

Dans les versions antérieures d'ASP.NET, lorsque vous utilisiez Visual Studio pour créer un projet de site Web ou d'application Web, les projets résultants contenaient uniquement une page Default.aspx, un fichier Web.config par défaut et le dossier App_Data. Visual Studio prend également en charge un type de projet de site Web vide, qui ne contient aucun fichier. Un débutant n'a alors que très peu d'aide pour générer une application Web de production. Par conséquent, ASP.NET 4 présente trois nouveaux modèles, un pour un projet d'application Web vide, un pour un projet d'application Web et un pour un projet de site Web :

  • modèles de projets d'application Web et de site Web vides. Ils sont semblables à la disposition de site Web vide des versions antérieures d'ASP.NET, sauf qu'ils contiennent un fichier Web.config qui spécifie la version ciblée du .NET Framework.

  • Modèles de projets d'application Web et de site Web. Ils incluent plusieurs fichiers qui n'ont pas été créés dans les versions antérieures. Les fichiers supplémentaires fournissent des fonctionnalités d'appartenance de base, une page maître et une page de contenu qui l'utilise, et des fichiers AJAX et CSS. Le but de ces modifications apportées aux modèles de projet est de fournir une aide pour commencer à générer une nouvelle application Web.

Pour plus d'informations, consultez Modèles Visual Studio pour les projets Web.

ASP.NET MVC aide les développeurs Web à générer des sites Web standard faciles à maintenir, dans la mesure où il diminue la dépendance dans les couches d'application à l'aide du modèle MVC (Model-View-Controller). MVC fournit un contrôle complet sur le balisage de page. Il améliore également la testabilité en prenant en charge de manière inhérente le développement axé sur des tests (TDD, Test Driven Development).

Les sites Web créés à l'aide d'ASP.NET MVC ont une architecture modulaire. Celle-ci permet aux membres d'une équipe de travailler indépendamment sur les différents modules et d'améliorer leur collaboration. Par exemple, les développeurs peuvent travailler sur les couches modèle et contrôleur (données et logique), pendant que le concepteur travaille sur l'affichage (présentation).

Pour accéder aux didacticiels, aux procédures pas à pas, au contenu conceptuel, à des exemples de code et à une référence d'API complète, consultez ASP.NET MVC 2.

Dynamic Data a été introduit dans la version finale du .NET Framework 3.5 SP1 au milieu de l'année 2008. Cette fonctionnalité fournit de nombreuses améliorations pour la création d'applications pilotées par des données, telles que les suivantes :

  • Expérience RAD pour la génération rapide d'un site Web piloté par des 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 dans les contrôles GridView et DetailsView à l'aide des modèles de champ qui font partie de votre projet Dynamic Data.

Dans ASP.NET 4, Dynamic Data a été amélioré pour permettre aux développeurs de générer encore plus rapidement des sites Web pilotés par des données. Pour plus d'informations, consultez Organigramme des informations relatives à Dynamic Data ASP.NET.

Activation de Dynamic Data pour les contrôles liés aux données individuels dans les applications Web existantes

Vous pouvez utiliser des fonctionnalités Dynamic Data dans des applications Web ASP.NET existantes qui n'utilisent pas la génération de modèles automatique en activant Dynamic Data pour certains contrôles liés aux données. Dynamic Data offre la présentation et la prise en charge des couches de données pour restituer ces contrôles. Lorsque vous activez Dynamic Data pour des contrôles liés aux données, vous bénéficiez des avantages suivants :

  • Définition de valeurs par défaut pour des champs de données. Dynamic Data vous permet de fournir des valeurs par défaut au moment de l'exécution pour les champs dans un contrôle de données.

  • Interaction avec la base de données sans créer ni enregistrer de modèle de données.

  • Validation automatique des données entrées par l'utilisateur sans écrire aucun code.

Pour plus d'informations, consultez Procédure pas à pas : activation de Dynamic Data dans des contrôles liés aux données ASP.NET.

Syntaxe déclarative du contrôle DynamicDataManager

Le contrôle DynamicDataManager a été amélioré afin que vous puissiez le configurer de façon déclarative, comme la plupart des contrôles dans ASP.NET, et non uniquement dans le code. La marque 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> 

Cette marque active le comportement Dynamic Data pour le contrôle GridView1 référencé dans la section DataControls du contrôle DynamicDataManager.

Modèles d'entités

Les modèles d'entité offrent une nouvelle méthode pour personnaliser la disposition des données sans devoir créer une page personnalisée. Les modèles de page utilisent le contrôle FormView à la place du contrôle DetailsView, qui était utilisé dans les modèles de page des versions antérieures de Dynamic Data. Les modèles de page utilisent également le contrôle DynamicEntity pour restituer des modèles d'entité. Vous bénéficiez donc d'un plus grand contrôle sur la marque rendue par Dynamic Data.

Pour plus d'informations sur les modèles d'entité, consultez ASP.NET 4 and Visual Studio 2010 Web Development Overview (format .pdf) sur le site Web ASP.NET.

Nouveaux modèles de champs pour les URL et les adresses de messagerie

ASP.NET 4 présente 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 à l'aide de l'attribut DataTypeAttribute. 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 de type Url s'affichent sous la forme de liens hypertexte ordinaires.

L'exemple suivant montre comment marquer des champs.

[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 le .NET Framework 3.5 SP1 pour contrôler les URL que les utilisateurs voient quand ils accèdent au site Web. Le nouveau contrôle DynamicHyperLink facilite la création de liens vers les pages d'un site Dynamic Data.

Pour plus d'informations, consultez Comment : créer des liens d'action de table dans Dynamic Data.

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

ADO.NET Entity Framework et LINQ to SQL prennent en charge l'héritage dans leurs modèles de données. Une base de données qui possède une table InsurancePolicy peut en être l'exemple. Cette base de données peut également contenir des tables CarPolicy et HousePolicy qui ont les mêmes champs que la table InsurancePolicy, puis y ajouter d'autres champs. Dynamic Data a été modifié pour comprendre les objets hérités dans le modèle de données et prendre en charge la génération de modèles automatique pour les tables héritées.

Pour plus d'informations, consultez Procédure pas à pas : mappage de l'héritage table par hiérarchie dans Dynamic Data.

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

Entity Framework offre une prise en charge enrichie des relations plusieurs à plusieurs entre les tables, laquelle est implémentée en exposant la relation sous la forme d'une collection sur un objet Entity. De nouveaux modèles de champs (ManyToMany.ascx et ManyToMany_Edit.ascx) ont été ajoutés pour assurer la prise en charge de l'affichage et de la modification des données impliquées dans les relations plusieurs à plusieurs.

Pour plus d'informations, consultez Utilisation de relations plusieurs à plusieurs dans Dynamic Data.

Nouveaux attributs pour contrôler l'affichage et prendre en charge les énumérations

L'objet DisplayAttribute a été ajouté pour vous donner un meilleur contrôle sur l'affichage des champs. L'attribut DisplayNameAttribute dans les versions antérieures de Dynamic Data vous permettait de modifier le nom utilisé en tant que légende pour un champ. La nouvelle classe DisplayAttribute vous permet de spécifier davantage d'options d'affichage pour un champ, telles que l'ordre dans lequel un champ s'affiche et s'il est utilisé comme filtre. L'attribut offre également un contrôle indépendant du nom utilisé pour les étiquettes dans un contrôle GridView, du nom utilisé dans un contrôle DetailsView, du texte de l'aide sur le champ et du filigrane utilisé pour le champ (si le champ accepte la saisie 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 modèle de champ Enumeration.ascx pour créer l'interface utilisateur utilisée pour l'affichage et la modification de valeurs d'énumération. Le modèle mappe les valeurs de la base de données aux noms dans l'énumération.

Prise en charge améliorée des filtres

Dynamic Data 1.0 comportait des filtres intégrés pour les colonnes booléennes et les colonnes de clés étrangères. Ces filtres ne vous permettaient pas de spécifier l'ordre dans lequel ils s'affichaient. Le nouvel attribut DisplayAttribute y remédie en vous permettant de contrôler si une colonne s'affiche sous forme de filtre et dans quel ordre elle s'affiche.

Une autre amélioration concerne la réécriture de la prise en charge du filtrage afin d'utiliser la nouvelle fonctionnalité QueryExtender de Web Forms. Cette fonctionnalité vous permet de créer des filtres sans connaître le contrôle de source de données avec lequel les filtres seront utilisés. En complément de 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 permet au filtre par défaut d'être substitué, de la même façon qu'UIHint permet au modèle de champ par défaut d'une colonne d'être substitué.

Pour plus d'informations, consultez Procédure pas à pas : filtrage de lignes dans des tables qui ont une relation parent-enfant et QueryableFilterRepeater.

Le contrôle de graphique ASP.NET vous permet de créer des applications de pages ASP.NET qui incluent des graphiques simples et intuitifs en vue d'effectuer des analyses financières ou statistiques complexes. Le contrôle de graphique prend en charge les fonctionnalités suivantes :

  • Séries de données, zones de graphique, axes, légendes, étiquettes, titres, etc.

  • Liaison de données.

  • Manipulation de données (copie, fractionnement, fusion, alignement, regroupement, tri, recherche et filtrage).

  • Formules statistiques et formules financières.

  • Apparence de graphique avancée (3D, anticrénelage, surbrillance et perspective).

  • Événements et personnalisations.

  • Interactivité et Microsoft Ajax.

  • Prise en charge du réseau de distribution de contenu Ajax, qui offre un moyen optimisé d'ajouter Microsoft Ajax Library et des scripts jQuery à vos applications Web.

Pour plus d'informations, consultez Vue d'ensemble du contrôle serveur Web Chart.

Les sections suivantes fournissent des informations sur les améliorations et les nouvelles fonctionnalités de Visual Studio 2010 et Visual Web Developer Express.

Le concepteur de pages Web dans Visual Studio 2010 a été amélioré pour une meilleure compatibilité CSS ; il inclut une prise en charge supplémentaire des extraits de code de balisage HTML et ASP.NET, et il comporte une version remaniée d'IntelliSense pour JScript.

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 le code source HTML et est plus fiable que dans les versions antérieures de Visual Studio.

Extraits de code HTML et JavaScript

Dans l'éditeur HTML, IntelliSense complète automatiquement les noms de balises. La fonctionnalité Extraits de code IntelliSense complète automatiquement des balises entières entre autres. Dans Visual Studio 2010, les extraits de code IntelliSense sont pris en charge pour JScript, ainsi que C# et Visual Basic, qui étaient pris en charge dans les versions antérieures de Visual Studio.

Visual Studio 2010 inclut plus de 200 extraits de code qui vous permettent de compléter automatiquement les balises ASP.NET et HTML courantes, notamment les attributs obligatoires (tels que runat="server") et les attributs courants spécifiques à une balise (tels que les attributs 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. (Pour plus d'informations sur les extraits de code HTML, consultez Procédure pas à pas : utilisation d'extraits HTML.)

Améliorations de JavaScript IntelliSense

Dans Visual 2010, JScript IntelliSense a été remanié afin d'offrir une expérience de modification encore plus riche. IntelliSense reconnaît maintenant les objets générés dynamiquement par les méthodes telles que registerNamespace et par les techniques semblables utilisées par d'autres infrastructures JavaScript. Les performances ont été améliorées pour analyser de grandes bibliothèques de scripts et afficher IntelliSense avec peu ou pas de délai de traitement. La compatibilité a été augmentée considérablement pour prendre en charge presque toutes les bibliothèques tierces et des styles de programmation divers. Les commentaires sur la documentation sont maintenant analysés lors de la frappe et immédiatement exploités par IntelliSense.

Déploiement d'applications Web avec Visual Studio 2010

Pour les projets d'application Web, Visual Studio fournit maintenant des outils qui fonctionnent avec IIS Outil de déploiement Web (Web Deploy) pour automatiser de nombreux processus qui devaient être effectués manuellement dans les versions antérieures d'ASP.NET. Par exemple, les tâches suivantes peuvent maintenant être automatisées :

  • Création d'une application IIS sur l'ordinateur de destination et configuration de paramètres IIS.

  • Copie de fichiers vers l'ordinateur de destination.

  • Modification des paramètres Web.config qui doivent être différents dans l'environnement de destination.

  • Propagation des modifications apportées aux données ou aux structures de données dans les bases de données SQL Server utilisées par l'application Web.

Pour plus d'informations sur le déploiement d'une application Web, consultez Organigramme des informations relatives au déploiement ASP.NET.

ASP.NET 4 ajoute de nouvelles fonctionnalités à la fonctionnalité de multi-ciblage pour faciliter l'utilisation de projets qui ciblent des versions antérieures du .NET Framework.

Le multi-ciblage a été introduit dans ASP.NET 3.5 pour vous permettre d'utiliser la version la plus récente de Visual Studio sans devoir effectuer une mise à niveau des sites Web ou services Web existants vers la version la plus récente du .NET Framework. 

Dans Visual Studio 2008, lorsque vous utilisez un projet ciblé pour une version antérieure du .NET Framework, la plupart des fonctionnalités de l'environnement de développement s'adaptent à la version ciblée. Toutefois, IntelliSense affiche les fonctionnalités de langage disponibles dans la version actuelle, et les fenêtres de propriétés affichent les propriétés disponibles dans la version actuelle. Dans Visual Studio 2010, seules les fonctionnalités de langage et les propriétés disponibles dans la version ciblée du .NET Framework s'affichent.

Pour plus d'informations sur le multi-ciblage, consultez les rubriques suivantes :

Ajouts de la communauté

AJOUTER
Afficher: