ASP.NET et Web Tools pour Visual Studio 2013 - Notes de publication

  • Article

par Microsoft

Ce document décrit la publication de ASP.NET et Web Tools pour Visual Studio 2013.

Contenu

Nouvelles fonctionnalités dans ASP.NET et Web Tools pour Visual Studio 2013

Notes d'installation

ASP.NET et Web Tools pour Visual Studio 2013 sont fournis dans le programme d’installation main et peuvent être téléchargés ici.

Documentation

Des didacticiels et d’autres informations sur ASP.NET et Web Tools pour Visual Studio 2013 sont disponibles sur le site web ASP.NET.

Configuration logicielle

ASP.NET et Web Tools nécessite Visual Studio 2013.

Nouvelles fonctionnalités dans ASP.NET et Web Tools pour Visual Studio 2013

Les sections suivantes décrivent les fonctionnalités qui ont été introduites dans la version.

Un ASP.NET

Avec la publication de Visual Studio 2013, nous avons fait un pas vers l’unification de l’expérience d’utilisation des technologies ASP.NET, afin que vous puissiez facilement combiner et correspondre à celles que vous souhaitez. Par exemple, vous pouvez démarrer un projet à l’aide de MVC et ajouter facilement Web Forms pages au projet ultérieurement, ou créer des API web dans un projet Web Forms. L’un ASP.NET consiste à faciliter votre travail en tant que développeur pour faire les choses que vous aimez dans ASP.NET. Quelle que soit la technologie que vous choisissez, vous pouvez avoir l’assurance que vous vous appuyez sur le framework sous-jacent approuvé de One ASP.NET.

Nouvelle expérience de projet web

Nous avons amélioré l’expérience de création de projets web dans Visual Studio 2013. Dans la boîte de dialogue Nouveau projet web ASP.NET, vous pouvez sélectionner le type de projet souhaité, configurer n’importe quelle combinaison de technologies (Web Forms, MVC, API web), configurer les options d’authentification et ajouter un projet de test unitaire.

Nouveau projet ASP.NET

La nouvelle boîte de dialogue vous permet de modifier les options d’authentification par défaut pour la plupart des modèles. Par exemple, lorsque vous créez un projet ASP.NET Web Forms, vous pouvez sélectionner l’une des options suivantes :

  • Aucune authentification
  • Comptes d’utilisateur individuels (ASP.NET appartenance ou connexion de fournisseur social)
  • Comptes d’organisation (Active Directory dans une application Internet)
  • Authentification Windows (Active Directory dans une application intranet)

Options d’authentification

Pour plus d’informations sur le nouveau processus de création de projets web, consultez Création de projets web ASP.NET dans Visual Studio 2013. Pour plus d’informations sur les nouvelles options d’authentification, consultez ASP.NET Identity plus loin dans ce document.

ASP.NET la génération automatique

ASP.NET Scaffolding est une infrastructure de génération de code pour ASP.NET applications web. Cela facilite l’ajout d’un code réutilisable à votre projet qui interagit avec un modèle de données.

Dans les versions précédentes de Visual Studio, la génération de modèles automatique était limitée à ASP.NET projets MVC. Avec Visual Studio 2013, vous pouvez désormais utiliser la structure automatique pour n’importe quel projet ASP.NET, y compris Web Forms. Visual Studio 2013 ne prend actuellement pas en charge la génération de pages pour un projet Web Forms, mais vous pouvez toujours utiliser la génération de modèles automatique avec Web Forms en ajoutant des dépendances MVC au projet. La prise en charge de la génération de pages pour Web Forms sera ajoutée dans une mise à jour ultérieure.

Lorsque vous utilisez la génération de modèles automatique, nous nous assurons que toutes les dépendances requises sont installées dans le projet. Par exemple, si vous commencez avec un projet ASP.NET Web Forms, puis utilisez la génération de modèles automatique pour ajouter un contrôleur d’API web, les packages Et références NuGet requis sont automatiquement ajoutés à votre projet.

Pour ajouter la génération automatique MVC à un projet Web Forms, ajoutez un nouvel élément généré automatiquement et sélectionnez Dépendances MVC 5 dans la fenêtre de boîte de dialogue. Il existe deux options pour la génération automatique de modèles MVC : Minimal et Complet. Si vous sélectionnez Minimal, seuls les packages NuGet et les références pour ASP.NET MVC sont ajoutés à votre projet. Si vous sélectionnez l’option Complet, les dépendances minimales sont ajoutées, ainsi que les fichiers de contenu requis pour un projet MVC.

La prise en charge de la génération automatique automatique de contrôleurs asynchrones utilise les nouvelles fonctionnalités asynchrones d’Entity Framework 6.

Pour plus d’informations et de didacticiels, consultez vue d’ensemble de ASP.NET génération de modèles automatique.

Lien de navigateur : canal SignalR entre le navigateur et Visual Studio

La nouvelle fonctionnalité Lien de navigateur vous permet de connecter plusieurs navigateurs à Visual Studio et de les actualiser tous en cliquant sur un bouton dans la barre d’outils. Vous pouvez connecter plusieurs navigateurs à votre site de développement, y compris des émulateurs mobiles, puis cliquer sur Actualiser pour actualiser tous les navigateurs en même temps. Browser Link expose également une API pour permettre aux développeurs d’écrire des extensions Browser Link.

Capture d’écran du menu Visual Studio, avec l’icône Actualiser mise en surbrillance et le tableau de bord lien du navigateur mis en évidence dans le menu déroulant.

En permettant aux développeurs de tirer parti de l’API Browser Link, il devient possible de créer des scénarios très avancés qui dépassent les limites entre Visual Studio et n’importe quel navigateur connecté. Web Essentials tire parti de l’API pour créer une expérience intégrée entre Visual Studio et les outils de développement du navigateur, les émulateurs mobiles de contrôle à distance et bien plus encore.

Améliorations apportées à Visual Studio Web Editor

Visual Studio 2013 inclut un nouvel éditeur HTML pour les fichiers Razor et les fichiers HTML dans les applications web. Le nouvel éditeur HTML fournit un schéma unifié unique basé sur HTML5. Il a la saisie semi-automatique des accolades, l’interface utilisateur jQuery et l’attribut AngularJS IntelliSense, le regroupement d’attributs IntelliSense, l’ID et le nom de classe IntelliSense, ainsi que d’autres améliorations, notamment de meilleures performances, la mise en forme et les SmartTags.

La capture d’écran suivante illustre l’utilisation de l’attribut Bootstrap IntelliSense dans l’éditeur HTML.

IntelliSense dans l’éditeur HTML

Visual Studio 2013 est également fourni avec les éditeurs CoffeeScript et LESS intégrés. L’éditeur LESS est fourni avec toutes les fonctionnalités intéressantes de l’éditeur CSS et dispose d’IntelliSense spécifique pour les variables et les combinaisons dans tous les documents LESS de la @import chaîne.

prise en charge Azure App Service Web Apps dans Visual Studio

Dans Visual Studio 2013 avec le Kit de développement logiciel (SDK) Azure pour .NET 2.2, vous pouvez utiliser server Explorer pour interagir directement avec vos applications web distantes. Vous pouvez vous connecter à votre compte Azure, créer de nouvelles applications web, configurer des applications, afficher des journaux en temps réel, etc. Peu de temps après la publication du SDK 2.2, vous serez en mesure de s’exécuter en mode débogage à distance dans Azure. La plupart des nouvelles fonctionnalités de Azure App Service Web Apps également fonctionner dans Visual Studio 2012 lorsque vous installez la version actuelle du Kit de développement logiciel (SDK) Azure pour .NET.

Pour plus d’informations, consultez les ressources suivantes :

Améliorations apportées à la publication web

Visual Studio 2013 inclut des fonctionnalités de publication web nouvelles et améliorées. En voici quelques-uns :

Pour plus d’informations sur ASP.NET déploiement web, consultez le site ASP.NET.

NuGet 2.7

NuGet 2.7 inclut un ensemble complet de nouvelles fonctionnalités qui sont décrites en détail dans les notes de publication de NuGet 2.7.

Cette version de NuGet supprime également la nécessité de fournir un consentement explicite pour que la fonctionnalité de restauration de package de NuGet télécharge des packages. Le consentement (et la case à cocher associée dans la boîte de dialogue préférences de NuGet) est désormais accordé en installant NuGet. À présent, la restauration de package fonctionne simplement par défaut.

ASP.NET Web Forms

Un ASP.NET

Les modèles de projet Web Forms s’intègrent parfaitement à la nouvelle expérience One ASP.NET. Vous pouvez ajouter la prise en charge de MVC et de l’API web à votre projet Web Forms, et vous pouvez configurer l’authentification à l’aide de l’Assistant Création de projet One ASP.NET. Pour plus d’informations, consultez Création de projets web ASP.NET dans Visual Studio 2013.

ASP.NET Identity

Les modèles de projet Web Forms prennent en charge la nouvelle infrastructure ASP.NET Identity. En outre, les modèles prennent désormais en charge la création d’un projet intranet Web Forms. Pour plus d’informations, consultez Méthodes d’authentification dans Création de projets web ASP.NET dans Visual Studio 2013.

Bootstrap

Les modèles Web Forms utilisent Bootstrap pour fournir une apparence élégante et réactive que vous pouvez facilement personnaliser. Pour plus d’informations, consultez Bootstrap dans les modèles de projet web Visual Studio 2013.

ASP.NET MVC 5

Un ASP.NET

Les modèles de projet Web MVC s’intègrent parfaitement à la nouvelle expérience One ASP.NET. Vous pouvez personnaliser votre projet MVC et configurer l’authentification à l’aide de l’Assistant Création de projet One ASP.NET. Vous trouverez un didacticiel d’introduction à ASP.NET MVC 5 sur Prise en main avec ASP.NET MVC 5.

Pour plus d’informations sur la mise à niveau de projets MVC 4 vers MVC 5, consultez How to Upgrade an ASP.NET MVC 4 and Web API Project to ASP.NET MVC 5 and Web API 2.

ASP.NET Identity

Les modèles de projet MVC ont été mis à jour pour utiliser ASP.NET Identity pour l’authentification et la gestion des identités. Vous trouverez un tutoriel montrant l’authentification Facebook et Google et la nouvelle API d’appartenance dans Créer une application MVC 5 ASP.NET avec Facebook et Google OAuth2 et OpenID Sign-on et Créer une application MVC ASP.NET avec authentification et SQL DB et déployer sur Azure App Service.

Bootstrap

Le modèle de projet MVC a été mis à jour pour utiliser Bootstrap afin de fournir une apparence élégante et réactive que vous pouvez facilement personnaliser. Pour plus d’informations, consultez Bootstrap dans les modèles de projet web Visual Studio 2013.

Filtres d’authentification

Les filtres d’authentification sont un nouveau type de filtre dans ASP.NET MVC qui s’exécutent avant les filtres d’autorisation dans le pipeline ASP.NET MVC et vous permettent de spécifier la logique d’authentification par action, par contrôleur ou globalement pour tous les contrôleurs. Les filtres d’authentification traitent les informations d’identification dans la demande et fournissent un principal correspondant. Les filtres d’authentification peuvent également ajouter des défis d’authentification en réponse à des demandes non autorisées.

Remplacements de filtre

Vous pouvez désormais remplacer les filtres qui s’appliquent à une méthode d’action ou à un contrôleur donné en spécifiant un filtre de remplacement. Les filtres de remplacement spécifient un ensemble de types de filtres qui ne doivent pas être exécutés pour une étendue donnée (action ou contrôleur). Cela vous permet de configurer des filtres qui s’appliquent globalement, puis d’exclure certains filtres globaux de l’application à des actions ou des contrôleurs spécifiques.

Routage par attributs

ASP.NET MVC prend désormais en charge le routage d’attributs, grâce à une contribution de Tim McCall, l’auteur de http://attributerouting.net. Avec le routage d’attributs, vous pouvez spécifier vos itinéraires en annotant vos actions et contrôleurs.

API Web ASP.NET 2

Routage par attributs

API Web ASP.NET prend désormais en charge le routage d’attributs, grâce à une contribution de Tim McCall, l’auteur de http://attributerouting.net. Avec le routage d’attributs, vous pouvez spécifier vos itinéraires d’API web en annotant vos actions et contrôleurs comme suit :

[RoutePrefix("orders")] 
public class OrdersController : ApiController 
{ 
    [Route("{id}")] 
    public Order Get(int id) { } 
    [Route("{id}/approve")] 
    public Order Approve(int id) { } 
}

Le routage d’attributs vous donne plus de contrôle sur les URI dans votre API web. Par exemple, vous pouvez facilement définir une hiérarchie de ressources à l’aide d’un seul contrôleur d’API :

public class MoviesController : ApiController 
{ 
    [Route("movies")] 
    public IEnumerable<Movie> Get() { } 
    [Route("actors/{actorId}/movies")] 
    public IEnumerable<Movie> GetByActor(int actorId) { } 
    [Route("directors/{directorId}/movies")] 
    public IEnumerable<Movie> GetByDirector(int directorId) { } 
}

Le routage d’attributs fournit également une syntaxe pratique pour spécifier des paramètres facultatifs, des valeurs par défaut et des contraintes de routage :

// Optional parameter
[Route("people/{name?}")]
// Default value
[Route("people/{name=Dan}")]
// Constraint: Alphabetic characters only. 
[Route("people/{name:alpha}")]

Pour plus d’informations sur le routage d’attributs, consultez Routage des attributs dans l’API web 2.

OAuth 2.0

Les modèles de projet API web et application monopage prennent désormais en charge l’autorisation à l’aide d’OAuth 2.0. OAuth 2.0 est une infrastructure permettant d’autoriser l’accès client aux ressources protégées. Il fonctionne pour une variété de clients, y compris les navigateurs et les appareils mobiles.

La prise en charge d’OAuth 2.0 est basée sur le nouvel intergiciel de sécurité fourni par microsoft OWIN Components pour l’authentification du porteur et l’implémentation du rôle serveur d’autorisation. Les clients peuvent également être autorisés à l’aide d’un serveur d’autorisation d’organisation, tel qu’Azure Active Directory ou ADFS dans Windows Server 2012 R2.

Améliorations apportées à OData

Prise en charge des $select, $expand, $batch et $value

API Web ASP.NET OData offre désormais une prise en charge complète des $select, des $expand et des $value. Vous pouvez également utiliser $batch pour le traitement par lot des demandes et le traitement des jeux de modifications.

Les options $select et $expand vous permettent de modifier la forme des données retournées à partir d’un point de terminaison OData. Pour plus d’informations, consultez Présentation de la prise en charge $select et $expand dans L’API web OData.

Extensibilité améliorée

Les formateurs OData sont désormais extensibles. Vous pouvez ajouter des métadonnées d’entrée Atom, prendre en charge les entrées de flux nommés et de liens multimédias, ajouter des annotations instance et personnaliser la façon dont les liens sont générés.

Prise en charge sans type

Vous pouvez maintenant créer des services OData sans avoir à définir des types CLR pour vos types d’entités. Au lieu de cela, vos contrôleurs OData peuvent prendre ou retourner des instances d’IEdmObject, qui sont les formateurs OData sérialisent/désérialisent.

Réutiliser un modèle existant

Si vous disposez déjà d’un modèle de données d’entité (EDM), vous pouvez maintenant le réutiliser directement, au lieu d’en créer un nouveau. Par exemple, si vous utilisez Entity Framework, vous pouvez utiliser l’EDM qu’EF génère pour vous.

Traitement par lots des demandes

Le traitement par lots de requêtes combine plusieurs opérations en une seule requête HTTP POST, pour réduire le trafic réseau et fournir une interface utilisateur plus fluide et moins bavard. API Web ASP.NET prend désormais en charge plusieurs stratégies pour le traitement par lots des requêtes :

  • Utilisez le point de terminaison $batch d’un service OData.
  • Empaqueter plusieurs requêtes dans une seule requête MIME en plusieurs parties.
  • Utilisez un format de traitement par lots personnalisé.

Pour activer le traitement par lots des demandes, ajoutez simplement un itinéraire avec un gestionnaire de traitement par lot à votre configuration d’API web :

public static class WebApiConfig 
{ 
    public static void Register(HttpConfiguration config) 
    { 
        config.Routes.MapHttpBatchRoute( 
            routeName: "WebApiBatch", 
            routeTemplate: "api/batch", 
            batchHandler: new DefaultHttpBatchHandler(GlobalConfiguration.DefaultServer)); 
    } 
}

Vous pouvez également contrôler si les demandes ou s’exécutent séquentiellement ou dans n’importe quel ordre.

Client API Web ASP.NET portable

Vous pouvez maintenant utiliser le client API Web ASP.NET pour créer des bibliothèques de classes portables qui fonctionnent dans votre Windows Store et Windows Phone 8 applications. Vous pouvez également créer des formateurs portables qui peuvent être partagés entre le client et le serveur.

Testabilité améliorée

L’API web 2 facilite considérablement le test unitaire de vos contrôleurs d’API. Instanciez simplement votre contrôleur d’API avec votre message de demande et votre configuration, puis appelez la méthode d’action que vous souhaitez tester. Il est également facile de simuler la classe UrlHelper pour les méthodes d’action qui effectuent la génération de liens.

IHttpActionResult

Vous pouvez maintenant implémenter IHttpActionResult pour encapsuler le résultat de vos méthodes d’action d’API web. Un IHttpActionResult retourné à partir d’une méthode d’action d’API web est exécuté par le runtime API Web ASP.NET pour produire le message de réponse résultant. Un IHttpActionResult peut être retourné à partir de n’importe quelle action d’API web pour simplifier les tests unitaires de votre implémentation d’API web. Pour des raisons pratiques, un certain nombre d’implémentations IHttpActionResult sont fournies prêtes à l’emploi, y compris les résultats permettant de retourner des codes de status spécifiques, du contenu mis en forme ou des réponses négociées par le contenu.

HttpRequestContext

Le nouveau HttpRequestContext effectue le suivi de tout état lié à la requête, mais qui n’est pas immédiatement disponible à partir de la requête. Par exemple, vous pouvez utiliser HttpRequestContext pour obtenir les données de routage, le principal associé à la demande, le certificat client, l’UrlHelper et la racine du chemin d’accès virtuel. Vous pouvez facilement créer un HttpRequestContext à des fins de test unitaire.

Étant donné que le principal de la requête est transmis avec la requête au lieu de s’appuyer sur Thread.CurrentPrincipal, le principal est désormais disponible tout au long de la durée de vie de la requête alors qu’il se trouve dans le pipeline d’API web.

CORS

Grâce à une autre grande contribution de Brock Allen, ASP.NET prend désormais entièrement en charge le partage des demandes d’origine croisée (CORS).

La sécurité des navigateurs empêche une page web d’adresser des demandes AJAX à un autre domaine. CORS est une norme W3C qui permet à un serveur d’assouplir la stratégie de même origine. Grâce au mécanisme CORS, un serveur peut autoriser explicitement certaines demandes multi-origines tout en en refusant d’autres.

L’API web 2 prend désormais en charge CORS, y compris la gestion automatique des demandes de contrôle préliminaire. Pour plus d’informations, consultez la section Activation des demandes multi-origines dans l’API web ASP.NET.

Filtres d’authentification

Les filtres d’authentification sont un nouveau type de filtre dans API Web ASP.NET qui s’exécutent avant les filtres d’autorisation dans le pipeline API Web ASP.NET et vous permettent de spécifier la logique d’authentification par action, par contrôleur ou globalement pour tous les contrôleurs. Les filtres d’authentification traitent les informations d’identification dans la demande et fournissent un principal correspondant. Les filtres d’authentification peuvent également ajouter des défis d’authentification en réponse à des demandes non autorisées.

Remplacements de filtres

Vous pouvez maintenant remplacer les filtres qui s’appliquent à une méthode d’action ou à un contrôleur donné, en spécifiant un filtre de remplacement. Les filtres de remplacement spécifient un ensemble de types de filtres qui ne doivent pas s’exécuter pour une étendue donnée (action ou contrôleur). Cela vous permet d’ajouter des filtres globaux, mais d’en exclure certains d’actions ou de contrôleurs spécifiques.

Intégration OWIN

API Web ASP.NET prend désormais entièrement en charge OWIN et peut être exécuté sur n’importe quel hôte compatible OWIN. Un HostAuthenticationFilter qui fournit l’intégration au système d’authentification OWIN est également inclus.

Avec l’intégration OWIN, vous pouvez héberger automatiquement l’API web dans votre propre processus avec d’autres intergiciels OWIN, tels que SignalR. Pour plus d’informations, consultez Utiliser OWIN pour Self-Host API Web ASP.NET.

ASP.NET SignalR 2.0

Les sections suivantes décrivent les fonctionnalités de SignalR 2.0.

Pour obtenir un exemple de mise à niveau d’un projet 1.x existant vers SignalR 2.0, consultez Mise à niveau d’un projet SignalR 1.x.

Basé sur OWIN

SignalR 2.0 est entièrement basé sur OWIN (l’interface web ouverte pour .NET). Cette modification rend le processus d’installation de SignalR beaucoup plus cohérent entre les applications SignalR hébergées sur le web et auto-hébergées, mais a également exigé un certain nombre de modifications d’API.

MapHubs et MapConnection sont désormais MapSignalR

Pour la compatibilité avec les normes OWIN, ces méthodes ont été renommées en MapSignalR. MapSignalR appelé sans paramètres mappe tous les hubs (comme MapHubs le fait dans la version 1.x) ; pour mapper des objets PersistentConnection individuels, spécifiez le type de connexion comme paramètre de type et l’extension d’URL de la connexion comme premier argument.

La MapSignalR méthode est appelée dans une classe de démarrage Owin. Visual Studio 2013 contient un nouveau modèle pour une classe de démarrage Owin ; pour utiliser ce modèle, procédez comme suit :

  1. Cliquez avec le bouton droit sur le projet
  2. Sélectionnez Ajouter, Nouvel élément...
  3. Sélectionnez Classe de démarrage Owin. Nommez la nouvelle classe Startup.cs.

Dans une application web, la classe de démarrage Owin contenant la MapSignalR méthode est ensuite ajoutée au processus de démarrage d’Owin à l’aide d’une entrée dans le nœud paramètres de l’application du fichier Web.Config, comme indiqué ci-dessous.

Dans une application auto-hébergée, la classe Startup est passée en tant que paramètre de type de la WebApp.Start méthode.

Mappage des hubs et des connexions dans SignalR 1.x (à partir du fichier d’application global dans une application web) :

protected void Application_Start(object sender, EventArgs e) 
{
    // Map all hubs to "/signalr"
    RouteTable.Routes.MapHubs();
    // Map the Echo PersistentConnection to "/echo"
    RouteTable.Routes.MapConnection<myconnection>("echo", "/echo");
}

Mappage des hubs et des connexions dans SignalR 2.0 (à partir d’un fichier de classe Owin Startup) :

using Microsoft.AspNet.SignalR;
using Microsoft.Owin;
using Owin;

[assembly: OwinStartup(typeof(MyWebApplication.Startup))]

namespace MyWebApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Map all hubs to "/signalr"
            app.MapSignalR();
            // Map the Echo PersistentConnection to "/echo"
            app.MapSignalR<echoconnection>("/echo");
        }
    }
}

Dans une application auto-hébergée, la classe Startup est passée en tant que paramètre de type pour la WebApp.Start méthode, comme indiqué ci-dessous.

string url = "http://localhost:8080";
using (WebApp.Start<startup>(url))
{
    Console.WriteLine("Server running on {0}", url);
    Console.ReadLine();
}

Prise en charge inter-domaines

Dans SignalR 1.x, les requêtes inter-domaines étaient contrôlées par un seul indicateur EnableCrossDomain. Cet indicateur contrôlait les requêtes JSONP et CORS. Pour plus de flexibilité, toute la prise en charge de CORS a été supprimée du composant serveur de SignalR (les clients JavaScript utilisent toujours CORS normalement s’il est détecté que le navigateur le prend en charge) et un nouvel intergiciel OWIN a été mis à disposition pour prendre en charge ces scénarios.

Dans SignalR 2.0, si JSONP est requis sur le client (pour prendre en charge les requêtes inter-domaines dans les anciens navigateurs), il doit être activé explicitement en définissant EnableJSONP sur l’objet trueHubConfiguration la valeur , comme indiqué ci-dessous. JSONP est désactivé par défaut, car il est moins sécurisé que CORS.

Pour ajouter le nouveau middleware CORS dans SignalR 2.0, ajoutez la Microsoft.Owin.Cors bibliothèque à votre projet et appelez UseCors avant votre middleware SignalR, comme indiqué dans la section ci-dessous.

Ajout de Microsoft.Owin.Cors à votre projet : pour installer cette bibliothèque, exécutez la commande suivante dans la console du Gestionnaire de package :

Install-Package Microsoft.Owin.Cors

Cette commande ajoute la version 2.0.0 du package à votre projet.

Appel de UseCors

Les extraits de code suivants montrent comment implémenter des connexions inter-domaines dans SignalR 1.x et 2.0.

Implémentation de requêtes inter-domaines dans SignalR 1.x (à partir du fichier d’application global)

protected void Application_Start(object sender, EventArgs e) 
{
    var hubConfiguration = new HubConfiguration();
    hubConfiguration.EnableCrossDomain = true;
    RouteTable.Routes.MapHubs(hubConfiguration);
}

Implémentation de requêtes inter-domaines dans SignalR 2.0 (à partir d’un fichier de code C#)

Le code suivant montre comment activer CORS ou JSONP dans un projet SignalR 2.0. Cet exemple de code utilise Map et RunSignalR au lieu de MapSignalR, de sorte que le middleware CORS s’exécute uniquement pour les requêtes SignalR qui nécessitent la prise en charge CORS (plutôt que pour tout le trafic au niveau du chemin spécifié dans MapSignalR.) Map peut également être utilisé pour tout autre middleware qui doit s’exécuter pour un préfixe d’URL spécifique, plutôt que pour l’ensemble de l’application.

using Microsoft.AspNet.SignalR;
using Microsoft.Owin.Cors;
using Owin;

[assembly: OwinStartup(typeof(MyWebApplication.Startup))]

namespace MyWebApplication
{
    public class Startup
    {
        public void Configuration(IAppBuilder app)
        {
            // Branch the pipeline here for requests that start with "/signalr"
            app.Map("/signalr", map =>
            {
                // Setup the CORS middleware to run before SignalR.
                // By default this will allow all origins. You can 
                // configure the set of origins and/or http verbs by
                // providing a cors options with a different policy.
                map.UseCors(CorsOptions.AllowAll);
                var hubConfiguration = new HubConfiguration 
                {
                    // You can enable JSONP by uncommenting line below.
                    // JSONP requests are insecure but some older browsers (and some
                    // versions of IE) require JSONP to work cross domain
                    // EnableJSONP = true
                };
                // Run the SignalR pipeline. We're not using MapSignalR
                // since this branch already runs under the "/signalr"
                // path.
                map.RunSignalR(hubConfiguration);
            });
        }
    }
}

Prise en charge d’iOS et d’Android via MonoTouch et MonoDroid

La prise en charge a été ajoutée pour les clients iOS et Android à l’aide des composants MonoTouch et MonoDroid de la bibliothèque Xamarin. Pour plus d’informations sur leur utilisation, consultez Utilisation de composants Xamarin. Ces composants seront disponibles dans le magasin Xamarin lorsque la version de SignalR RTW sera disponible.

### Client .NET portable

Pour faciliter le développement multiplateforme, les clients Silverlight, WinRT et Windows Phone ont été remplacés par un seul client .NET portable qui prend en charge les plateformes suivantes :

  • NET 4.5
  • Silverlight 5
  • WinRT (.NET pour les applications du Windows Store)
  • Windows Phone 8

Nouveau package Self-Host

Il existe désormais un package NuGet pour faciliter la prise en main de SignalR Self-Host (applications SignalR hébergées dans un processus ou une autre application, plutôt que d’être hébergées sur un serveur web). Pour mettre à niveau un projet auto-hôte créé avec SignalR 1.x, supprimez le package Microsoft.AspNet.SignalR.Owin et ajoutez le package Microsoft.AspNet.SignalR.SelfHost. Pour plus d’informations sur la prise en main du package auto-hôte, consultez Tutoriel : SignalR Self-Host.

Prise en charge des serveurs rétrocompatibles

Dans les versions précédentes de SignalR, les versions du package SignalR utilisé dans le client et le serveur devaient être identiques. Afin de prendre en charge les applications clientes épaisses qui seraient difficiles à mettre à jour, SignalR 2.0 prend désormais en charge l’utilisation d’une version de serveur plus récente avec un client plus ancien. Remarque : SignalR 2.0 ne prend pas en charge les serveurs créés avec des versions antérieures avec des clients plus récents.

Suppression de la prise en charge du serveur pour .NET 4.0

SignalR 2.0 a supprimé la prise en charge de l’interopérabilité du serveur avec .NET 4.0. .NET 4.5 doit être utilisé avec les serveurs SignalR 2.0. Il existe toujours un client .NET 4.0 pour SignalR 2.0.

Envoi d’un message à une liste de clients et de groupes

Dans SignalR 2.0, il est possible d’envoyer un message à l’aide d’une liste d’ID de client et de groupe. Les extraits de code suivants montrent comment procéder.

Envoi d’un message à une liste de clients et de groupes à l’aide de PersistentConnection

using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatConnection : PersistentConnection
{
    static List<string> ConnectionIds = new List<string>();
    static List<string> groups = new List<string>{"chatGroup", "chatGroup2"};
    protected override System.Threading.Tasks.Task OnReceived(IRequest request, string connectionId, string data)
    {
        Connection.Send(ConnectionIds, data);
        Groups.Send(groups, data);
        return base.OnReceived(request, connectionId, data);
    }
    protected override System.Threading.Tasks.Task OnConnected(IRequest request, string connectionId)
    {
        ConnectionIds.Add(connectionId);
        Groups.Add(connectionId, "chatGroup");
        return base.OnConnected(request, connectionId);
    }
    protected override System.Threading.Tasks.Task OnDisconnected(IRequest request, string connectionId)
    {
        ConnectionIds.Remove(connectionId);
        return base.OnDisconnected(request, connectionId);
    }
}

Envoi d’un message à une liste de clients et de groupes à l’aide de Hubs

using Microsoft.AspNet.SignalR;
using System.Collections.Generic;
public class ChatHub : Hub
{
    static List<string> ConnectionIds = new List<string>();
    static List<string> groups = new List<string> { "chatGroup", "chatGroup2" };
    public void Send(string name, string message)
    {
        // Call the broadcastMessage method to update clients.
        Clients.Clients(ConnectionIds).broadcastMessage(name, message);
        Clients.Groups(groups).broadcastMessage(name, message);
    }
    public override System.Threading.Tasks.Task OnConnected()
    {
        ConnectionIds.Add(Context.ConnectionId);
        Groups.Add(Context.ConnectionId, "chatGroup");
        return base.OnConnected();
    }
    public override System.Threading.Tasks.Task OnDisconnected()
    {
        ConnectionIds.Remove(Context.ConnectionId);
        return base.OnDisconnected();
    }
}

Envoi d’un message à un utilisateur spécifique

Cette fonctionnalité permet aux utilisateurs de spécifier l’id d’utilisateur basé sur un IRequest via une nouvelle interface IUserIdProvider :

Interface IUserIdProvider

public interface IUserIdProvider
{
    string GetUserId(IRequest request);
}

Par défaut, une implémentation utilise le IPrincipal.Identity.Name de l’utilisateur comme nom d’utilisateur.

Dans les hubs, vous pouvez envoyer des messages à ces utilisateurs via une nouvelle API :

Utilisation de l’API Clients.User

public class MyHub : Hub
{
    public void Send(string userId, string message)
    {
        Clients.User(userId).send(message);
    }
}

Meilleure prise en charge de la gestion des erreurs

Les utilisateurs peuvent désormais lever HubException à partir de n’importe quel appel hub. Le constructeur de hubException peut prendre un message de chaîne et des données d’erreur supplémentaires d’objet. SignalR sérialise automatiquement l’exception et l’envoie au client où elle sera utilisée pour rejeter/faire échouer l’appel de la méthode hub.

Le paramètre Afficher les exceptions détaillées du hub n’a aucune incidence sur le renvoi ou non de HubException au client ; il est toujours envoyé.

Code côté serveur illustrant l’envoi d’une HubException au client

public class MyHub : Hub
{
    public void Send(string message)
    {
        if(message.Contains("<script>"))
        {
            throw new HubException("This message will flow to the client", new { user = Context.User.Identity.Name, message = message });
        }

        Clients.All.send(message);
    }
}

Code client JavaScript illustrant la réponse à une exception HubException envoyée à partir du serveur

myHub.server.send("<script>")
            .fail(function (e) {
                if (e.source === 'HubException') {
                    console.log(e.message + ' : ' + e.data.user);
                }
            });

Code client .NET illustrant la réponse à une exception HubException envoyée à partir du serveur

try
{
    await myHub.Invoke("Send", "<script>");
}
catch(HubException ex)
{
    Conosle.WriteLine(ex.Message);
}

Tests unitaires plus faciles des hubs

SignalR 2.0 inclut une interface appelée IHubCallerConnectionContext sur hubs qui facilite la création d’appels côté client fictifs. Les extraits de code suivants illustrent l’utilisation de cette interface avec des harnais de test populaires xUnit.net et moq.

Test unitaire signalR avec xUnit.net

[Fact]
public void HubsAreMockableViaDynamic()
{
    bool sendCalled = false;
    var hub = new MyHub();
    var mockClients = new Mock<IHubCallerConnectionContext>();
    hub.Clients = mockClients.Object;
    dynamic all = new ExpandoObject();
    all.send = new Action<string>(message =>
    {
        sendCalled = true;
    });
    mockClients.Setup(m => m.All).Returns((ExpandoObject)all);
    hub.Send("foo");
    Assert.True(sendCalled);
}

Test unitaire signalR avec moq

[Fact]
public interface IClientContract
{
    void send(string message);
}
public void HubsAreMockableViaType()
{
    var hub = new MyHub();
    var mockClients = new Mock<IHubCallerConnectionContext>();
    var all = new Mock<IClientContract>();
    hub.Clients = mockClients.Object;
    all.Setup(m => m.send(It.IsAny<string>())).Verifiable();
    mockClients.Setup(m => m.All).Returns(all.Object);
    hub.Send("foo");
    all.VerifyAll();

Gestion des erreurs JavaScript

Dans SignalR 2.0, tous les rappels de gestion des erreurs JavaScript retournent des objets d’erreur JavaScript au lieu de chaînes brutes. Cela permet à SignalR de transmettre des informations plus riches à vos gestionnaires d’erreurs. Vous pouvez obtenir l’exception interne à partir de la source propriété de l’erreur.

Code client JavaScript qui gère l’exception Start.Fail

connection.start().fail(function(e) {
    console.log('The error is: ' + e.message);
});

ASP.NET Identity

Nouveau système d’appartenance ASP.NET

ASP.NET Identity est le nouveau système d’appartenance pour les applications ASP.NET. ASP.NET Identity facilite l’intégration de données de profil spécifiques à l’utilisateur avec les données d’application. ASP.NET Identity vous permet également de choisir le modèle de persistance des profils utilisateur dans votre application. Vous pouvez stocker les données dans une base de données SQL Server ou un autre magasin de données, y compris dans des magasins de données NoSQL tels que des tables Azure Storage. Pour plus d’informations, consultez Comptes d’utilisateur individuels dans Création de projets web ASP.NET dans Visual Studio 2013.

Authentification basée sur les revendications

ASP.NET prend désormais en charge l’authentification basée sur les revendications, où l’identité de l’utilisateur est représentée sous la forme d’un ensemble de revendications provenant d’un émetteur approuvé. Les utilisateurs peuvent être authentifiés à l’aide d’un nom d’utilisateur et d’un mot de passe conservés dans une base de données d’application, ou à l’aide de fournisseurs d’identité sociale (par exemple : comptes Microsoft, Facebook, Google, Twitter) ou à l’aide de comptes d’organisation via Azure Active Directory ou Services ADFS (ADFS).

Intégration à Azure Active Directory et Windows Server Active Directory

Vous pouvez maintenant créer ASP.NET projets qui utilisent Azure Active Directory ou Windows Server Active Directory (AD) pour l’authentification. Pour plus d’informations, consultez Comptes d’organisation dans Création de projets web ASP.NET dans Visual Studio 2013.

Intégration OWIN

ASP.NET’authentification est désormais basée sur un intergiciel OWIN qui peut être utilisé sur n’importe quel hôte OWIN. Pour plus d’informations sur OWIN, consultez la section Microsoft OWIN Components suivante.

Composants Microsoft OWIN

Open Web Interface for .NET (OWIN) définit une abstraction entre les serveurs web .NET et les applications web. OWIN dissocie l’application web du serveur, ce qui rend les applications web indépendantes de l’hôte. Par exemple, vous pouvez héberger une application web basée sur OWIN dans IIS ou l’héberger automatiquement dans un processus personnalisé.

Les modifications introduites dans les composants Microsoft OWIN (également appelés projet Katana) incluent de nouveaux composants serveur et hôte, de nouvelles bibliothèques d’assistance et intergiciels intermédiaires, ainsi que de nouveaux intergiciels d’authentification.

Pour plus d’informations sur OWIN et Katana, consultez Nouveautés d’OWIN et Katana.

Remarque : Les applications OWIN ne peuvent pas s’exécuter en mode classique IIS ; ils doivent être exécutés en mode intégré.

Remarque : les applications OWIN doivent être exécutées en toute confiance.

Nouveaux serveurs et hôtes

Avec cette version, de nouveaux composants ont été ajoutés pour activer les scénarios d’auto-hôte. Ces composants incluent les packages NuGet suivants :

  • Microsoft.Owin.Host.HttpListener. Fournit un serveur OWIN qui utilise HttpListener pour écouter les requêtes HTTP et les diriger vers le pipeline OWIN.
  • Microsoft.Owin.Hosting Fournit une bibliothèque pour les développeurs qui souhaitent auto-héberger un pipeline OWIN dans un processus personnalisé, tel qu’une application console ou un service Windows.
  • OwinHost. Fournit un exécutable autonome qui encapsule Microsoft.Owin.Hosting et vous permet d’héberger automatiquement un pipeline OWIN sans avoir à écrire une application hôte personnalisée.

En outre, le Microsoft.Owin.Host.SystemWeb package permet désormais à l’intergiciel de fournir des indicateurs au serveur SystemWeb , ce qui indique que l’intergiciel doit être appelé pendant une phase de pipeline de ASP.NET spécifique. Cette fonctionnalité est particulièrement utile pour l’intergiciel d’authentification, qui doit s’exécuter au début du pipeline ASP.NET.

Bibliothèques d’assistance et intergiciels

Bien que vous puissiez écrire des composants OWIN en utilisant uniquement les définitions de fonction et de type de la spécification OWIN, le nouveau Microsoft.Owin package fournit un ensemble d’abstractions plus convivial. Ce package combine plusieurs packages antérieurs (par exemple, Owin.Extensions, Owin.Types) en un seul modèle objet bien structuré qui peut ensuite être facilement utilisé par d’autres composants OWIN. En fait, la majorité des composants Microsoft OWIN utilisent désormais ce package.

Notes

Les applications OWIN ne peuvent pas s’exécuter en mode classique IIS ; ils doivent être exécutés en mode intégré.

Notes

Les applications OWIN doivent être exécutées en toute confiance.

Cette version inclut également le package Microsoft.Owin.Diagnostics, qui inclut des intergiciels pour valider une application OWIN en cours d’exécution, ainsi que des intergiciels de page d’erreur pour aider à examiner les échecs.

Composants d’authentification

Les composants d’authentification suivants sont disponibles.

  • Microsoft.Owin.Security.ActiveDirectory. Active l’authentification à l’aide de services d’annuaire locaux ou cloud.
  • Microsoft.Owin.Security.Cookies Active l’authentification à l’aide de cookies. Ce package était précédemment nommé Microsoft.Owin.Security.Forms.
  • Microsoft.Owin.Security.Facebook active l’authentification à l’aide du service basé sur OAuth de Facebook.
  • Microsoft.Owin.Security.Google Active l’authentification à l’aide du service OpenID de Google.
  • Microsoft.Owin.Security.Jwt Active l’authentification à l’aide de jetons JWT.
  • Microsoft.Owin.Security.MicrosoftAccount Active l’authentification à l’aide de comptes Microsoft.
  • Microsoft.Owin.Security.OAuth. Fournit un serveur d’autorisation OAuth ainsi que des intergiciels pour l’authentification des jetons du porteur.
  • Microsoft.Owin.Security.Twitter Active l’authentification à l’aide du service OAuth de Twitter.

Cette version inclut également le Microsoft.Owin.Cors package, qui contient un intergiciel pour le traitement des requêtes HTTP inter-origines.

Notes

La prise en charge de la signature JWT a été supprimée dans la version finale de Visual Studio 2013.

Entity Framework 6

Pour obtenir la liste des nouvelles fonctionnalités et d’autres modifications apportées à Entity Framework 6, consultez Historique des versions d’Entity Framework.

ASP.NET Razor 3

ASP.NET Razor 3 inclut les nouvelles fonctionnalités suivantes :

  • Prise en charge de la modification de tabulation. Auparavant, la commande Mettre en forme le document , la mise en retrait automatique et la mise en forme automatique dans Visual Studio ne fonctionnaient pas correctement lors de l’utilisation de l’option Conserver les onglets . Cette modification corrige la mise en forme de Visual Studio pour le code Razor pour la mise en forme des tabulations.
  • Prise en charge des règles de réécriture d’URL lors de la génération de liens.
  • Suppression de l’attribut transparent de sécurité.

    Notes

    Il s’agit d’un changement cassant qui rend Razor 3 incompatible avec MVC4 et les versions antérieures, tandis que Razor 2 est incompatible avec MVC5 ou les assemblys compilés sur MVC5.

=======

ASP.NET App Suspend

ASP.NET App Suspend est une fonctionnalité qui change la donne dans .NET Framework 4.5.1 qui change radicalement l’expérience utilisateur et le modèle économique pour héberger un grand nombre de sites ASP.NET sur un seul ordinateur. Pour plus d’informations, consultez ASP.NET App Suspend : hébergement web .NET partagé réactif.

Problèmes connus et changements cassants

Cette section décrit les problèmes connus et les changements cassants dans le ASP.NET et Web Tools pour Visual Studio 2013.

NuGet

  • La nouvelle restauration de package ne fonctionne pas sur Mono lors de l’utilisation du fichier SLN . Elle sera corrigée dans une prochaine nuget.exe téléchargement et la mise à jour du package NuGet.CommandLine .
  • La nouvelle restauration de package ne fonctionne pas avec les projets Wix . Elle sera corrigée dans une prochaine nuget.exe le téléchargement et la mise à jour du package NuGet.CommandLine .

API Web ASP.NET

  1. ODataQueryOptions<T>.ApplyTo(IQueryable) ne retourne IQueryable<T> pas toujours, car nous avons ajouté la prise en charge de $select et $expand.

    Nos exemples précédents pour ODataQueryOptions<T> toujours casté la valeur de retour de ApplyTo en IQueryable<T>. Cela a fonctionné précédemment, car les options de requête que nous avons prises en charge précédemment ($filter, $orderby, $skip, $top) ne modifient pas la forme de la requête. Maintenant que nous prenons en charge $select et $expand la valeur de retour à partir de ApplyTo ne sera IQueryable<T> pas toujours.

    // Sample ODataQueryOptions<T> usage from earlier
public IQueryable<Customer> Get(ODataQueryOptions<Customer> query)
{
    IQueryable<customer> result="query.ApplyTo(_customers)" as iqueryable<customer>; return result;
}

    Si vous utilisez l’exemple de code de précédemment, il continuera de fonctionner si le client n’envoie $select pas et $expand. Toutefois, si vous souhaitez prendre en charge $select et $expand que vous devez remplacer ce code par ceci.

    public IHttpActionResult Get(ODataQueryOptions<Customer> query)
{
    IQueryable result = query.ApplyTo(_customers);
    return Ok(result, result.GetType());
}
 
private IHttpActionResult Ok(object content, Type type)
{
    Type resultType = typeof(OkNegotiatedContentResult<>).MakeGenericType(type);
    return Activator.CreateInstance(resultType, content, this) as IHttpActionResult;
}

  2. Request.Url ou RequestContext.Url est null lors d’une demande par lots

    Dans un scénario de traitement par lots, UrlHelper est null lorsqu’il est accessible à partir de Request.Url ou RequestContext.Url.

    La solution de contournement pour ce problème consiste à créer un instance d’UrlHelper, comme dans l’exemple suivant :

    Création d’une instance d’UrlHelper

    if (RequestContext.Url == null)
{
    RequestContext.Url = new UrlHelper(Request);
}

ASP.NET MVC

  1. Lorsque vous utilisez MVC5 et OrgAuth, si vous avez des vues qui effectuent la validation AntiForgerToken, vous pouvez rencontrer l’erreur suivante lorsque vous publiez des données dans la vue :

    Erreur :

    Erreur de serveur dans l’application « / ».

    Une revendication de type http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier ou https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider n’était pas présente sur le ClaimsIdentity fourni. Pour activer la prise en charge des jetons anti-falsification avec l’authentification basée sur les revendications, vérifiez que le fournisseur de revendications configuré fournit ces deux revendications sur les instances ClaimsIdentity qu’il génère. Si le fournisseur de revendications configuré utilise plutôt un autre type de revendication comme identificateur unique, il peut être configuré en définissant la propriété statique AntiForgeryConfig.UniqueClaimTypeIdentifier.

    Solution de contournement :

    Ajoutez la ligne suivante dans Global.asax pour le corriger :

    AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name;

    Ce problème sera résolu pour la prochaine version.

  2. Après avoir mis à niveau une application MVC4 vers MVC5, générez la solution et lancez-la. Vous devez voir l’erreur suivante :

    [A] System.Web.WebPages.Razor.Configuration.HostSection ne peut pas être converti en [B]System.WebPages.Razor.Configuration.HostSection. Le type A provient de 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' dans le contexte 'Default' à l’emplacement 'C:\windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll'. Le type B provient de 'System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' dans le contexte 'Default' à l’emplacement 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root\6d05bbd0\e8b5908e\assembly\dl3\c9cbca63\f8910382_6273ce01\System.Web.WebPages.Razor.dll'.

    Pour corriger l’erreur ci-dessus, ouvrez tous les fichiers Web.config (y compris ceux du dossier Views) dans votre projet et procédez comme suit :

    1. Mettez à jour toutes les occurrences de la version « 4.0.0.0 » de « System.Web.Mvc » vers « 5.0.0.0 ».

    2. Mettez à jour toutes les occurrences de la version « 2.0.0.0 » de « System.Web.Helpers », « System.Web.WebPages » et « System.WebPages.Razor » vers « 3.0.0.0 »

      Par exemple, après avoir apporté les modifications ci-dessus, les liaisons d’assembly doivent ressembler à ceci :

      <dependentAssembly>
  <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.WebPages.Razor" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
  </dependentAssembly>
  <dependentAssembly>
  <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
  <bindingRedirect oldVersion="1.0.0.0-4.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>

      Pour plus d’informations sur la mise à niveau de projets MVC 4 vers MVC 5, consultez How to Upgrade an ASP.NET MVC 4 and Web API Project to ASP.NET MVC 5 et Web API 2.

  3. Lorsque vous utilisez la validation côté client avec jQuery Unobtrusive Validation, le message de validation est parfois incorrect pour un élément d’entrée HTML avec type='number'. L’erreur de validation d’une valeur obligatoire (« Le champ Âge est requis ») s’affiche lorsqu’un nombre non valide est entré au lieu du message correct indiquant qu’un nombre valide est requis.

    Ce problème est généralement rencontré avec le code généré pour un modèle avec une propriété entière dans les vues Créer et Modifier.

    Pour contourner ce problème, remplacez l’aide de l’éditeur par :

    @Html.EditorFor(person => person.Age)

    Par :

    @Html.TextBoxFor(person => person.Age)

  4. ASP.NET MVC 5 ne prend plus en charge l’approbation partielle. Les projets liés aux fichiers binaires MVC ou WebAPI doivent supprimer l’attribut SecurityTransparent et l’attribut AllowPartiallyTrustedCallers . La suppression de ces attributs éliminera les erreurs du compilateur telles que les suivantes.

    Attempt by security transparent method ‘MyComponent' to access security critical type 'System.Web.Mvc.MvcHtmlString' failed. Assembly 'PagedList.Mvc, Version=4.3.0.0, Culture=neutral, PublicKeyToken=abbb863e9397c5e1' is marked with the AllowPartiallyTrustedCallersAttribute, and uses the level 2 security transparency model. Level 2 transparency causes all methods in AllowPartiallyTrustedCallers assemblies to become security transparent by default, which may be the cause of this exception.

    Notez que, comme effet secondaire, vous ne pouvez pas utiliser les assemblys 4.0 et 5.0 dans la même application. Vous devez tous les mettre à jour vers la version 5.0.

Le modèle SPA avec l’autorisation Facebook peut entraîner une instabilité dans Internet Explorer alors que le site web est hébergé dans la zone intranet

Le modèle SPA fournit une connexion externe avec Facebook. Lorsque le projet créé avec le modèle s’exécute localement, la connexion peut provoquer le blocage d’Internet Explorer.

Solution :

  1. Héberger le site web dans la zone Internet ; Ou

  2. Testez le scénario dans un navigateur autre qu’Internet Explorer.

Génération de modèles automatique Web Forms

Web Forms structure a été supprimée de VS2013 et sera disponible dans une prochaine mise à jour de Visual Studio. Toutefois, vous pouvez toujours utiliser la structure au sein d’un projet Web Forms en ajoutant des dépendances MVC et en générant des modèles de génération de modèles pour MVC. Votre projet contiendra une combinaison de Web Forms et de MVC.

Pour ajouter MVC à votre projet Web Forms, ajoutez un nouvel élément de structure et sélectionnez Dépendances MVC 5. Sélectionnez Minimal ou Complet selon que vous avez besoin de tous les fichiers de contenu, tels que des scripts. Ensuite, ajoutez un élément de structure pour MVC, qui créera des vues et un contrôleur dans votre projet.

MVC et création de modèles d’API web - HTTP 404, erreur introuvable

Si une erreur est rencontrée lors de l’ajout d’un élément de structure à un projet, il est possible que votre projet soit laissé dans un état incohérent. Certaines des modifications apportées à la structure seront restaurées, mais d’autres modifications, telles que les packages NuGet installés, ne seront pas restaurées. Si les modifications de la configuration du routage sont restaurées, les utilisateurs recevront une erreur HTTP 404 lors de la navigation vers des éléments de structure.

Solution de contournement :

  • Pour corriger cette erreur pour MVC, ajoutez un nouvel élément de structure et sélectionnez Dépendances MVC 5 (minimales ou complètes). Ce processus ajoute toutes les modifications requises à votre projet.

  • Pour corriger cette erreur pour l’API web :

    1. Ajoutez la classe WebApiConfig à votre projet.

      public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.MapHttpAttributeRoutes();
        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );
    }
}

      Public Module WebApiConfig
    Public Sub Register(ByVal config As HttpConfiguration)
        config.MapHttpAttributeRoutes()
        config.Routes.MapHttpRoute(
          name:="DefaultApi",
          routeTemplate:="api/{controller}/{id}",
          defaults:=New With {.id = RouteParameter.Optional}
        )
    End Sub
End Module

    2. Configurez WebApiConfig.Register dans la méthode Application_Start dans Global.asax comme suit :

      public class WebApiApplication : System.Web.HttpApplication
{
    protected void Application_Start()
    {
        GlobalConfiguration.Configure(WebApiConfig.Register);    
    }
}

      Public Class WebApiApplication
     Inherits System.Web.HttpApplication
 
     Sub Application_Start()     
       GlobalConfiguration.Configure(AddressOf WebApiConfig.Register)       
     End Sub
End Class