Partager via

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

  • Article

par Microsoft

Ce document décrit la version 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 groupés dans le programme d’installation principal 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 à partir du site web ASP.NET.

Configuration logicielle requise

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 version de Visual Studio 2013, nous avons pris un pas vers l’unification de l’expérience d’utilisation de technologies ASP.NET, afin que vous puissiez facilement mélanger et faire correspondre celles souhaitées. Par exemple, vous pouvez démarrer un projet à l’aide de MVC et ajouter facilement des pages Web Forms au projet ultérieurement ou générer une structure d’API web dans un projet Web Forms. Une ASP.NET est tout sur la rendre plus facile pour vous en tant que développeur de faire les choses que vous aimez dans ASP.NET. Quelle que soit la technologie que vous choisissez, vous pouvez avoir confiance en vous appuyant sur l’infrastructure sous-jacente approuvée 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 des 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 au fournisseur social)
  • Comptes organisationnels (Active Directory dans une application Internet)
  • Authentification Windows (Active Directory dans une application intranet)

Options d’authentification

Pour plus d’informations sur les nouvelles options d’authentification, consultez ASP.NET Identity plus loin dans ce document.

ASP.NET génération de modèles automatique

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

Dans les versions précédentes de Visual Studio, la structure était limitée à ASP.NET projets MVC. Avec Visual Studio 2013, vous pouvez désormais utiliser la structure 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 prochaine mise à jour.

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 par 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 ajoutés automatiquement à votre projet.

Pour ajouter une structure 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 générer une structure MVC ; Minimal et Complet. Si vous sélectionnez Minimal, seuls les packages Et références NuGet pour ASP.NET MVC sont ajoutés à votre projet. Si vous sélectionnez l’option Full, les dépendances minimales sont ajoutées, ainsi que les fichiers de contenu requis pour un projet MVC.

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

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

Lien du 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 en cliquant sur un bouton dans la barre d’outils. Vous pouvez connecter plusieurs navigateurs à votre site de développement, y compris les é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 de lien de navigateur.

Capture d’écran du menu Visual Studio, avec l’icône Actualiser mise en surbrillance et le tableau de bord du lien du navigateur mis en surbrillance 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 franchissent les limites entre Visual Studio et tout 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, le contrôle à distance des émulateurs mobiles 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 dispose de la saisie semi-automatique, de l’interface utilisateur jQuery et de l’attribut AngularJS IntelliSense, du regroupement IntelliSense, de l’ID et du nom de classe IntelliSense, ainsi que d’autres améliorations, notamment de meilleures performances, de la mise en forme et des SmartTags.

La capture d’écran suivante montre comment utiliser 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 mixins dans tous les documents LESS de la @import chaîne.

Prise en charge d’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 l’Explorateur de serveurs pour interagir directement avec vos applications web distantes. Vous pouvez vous connecter à votre compte Azure, créer des applications web, configurer des applications, afficher des journaux en temps réel, etc. Bientôt disponible après la publication du SDK 2.2, vous serez en mesure d’exécuter en mode débogage à distance dans Azure. La plupart des nouvelles fonctionnalités d’Azure App Service Web Apps fonctionnent également 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 la fonctionnalité de restauration de package nuGet pour télécharger 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. Maintenant, 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 en toute transparence à la nouvelle expérience One ASP.NET. Vous pouvez ajouter la prise en charge de MVC et d’API web à votre projet Web Forms, et vous pouvez configurer l’authentification à l’aide de l’Assistant Création de projet One ASP.NET.

ASP.NET Identity

Les modèles de projet Web Forms prennent en charge le nouveau framework d’identité ASP.NET. En outre, les modèles prennent désormais en charge la création d’un projet intranet Web Forms.

Démarrage

Les modèles Web Forms utilisent Bootstrap pour fournir une apparence élégante et réactive que vous pouvez facilement personnaliser.

ASP.NET MVC 5

Un ASP.NET

Les modèles de projet Web MVC s’intègrent en toute transparence à 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 dans La prise en main de ASP.NET MVC 5.

Pour plus d’informations sur la mise à niveau de projets MVC 4 vers MVC 5, consultez Comment mettre à niveau un projet ASP.NET d’API MVC 4 et MVC 4 vers ASP.NET MVC 5 et l’API web 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 didacticiel montrant l’authentification Facebook et Google et la nouvelle API d’appartenance à l’application Créer une application ASP.NET MVC 5 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.

Démarrage

Le modèle de projet MVC a été mis à jour pour utiliser Bootstrap pour fournir un aspect élégant et réactif et vous sentirez que vous pouvez facilement personnaliser.

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. L’authentification filtre les informations d’identification dans la requête et fournit un principal correspondant. Les filtres d’authentification peuvent également ajouter des défis d’authentification en réponse aux demandes non autorisées.

Remplacements de filtre

Vous pouvez désormais remplacer les filtres qui s’appliquent à une méthode ou un contrôleur d’action 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, mais d’exclure certains filtres globaux de l’application à des actions ou contrôleurs spécifiques.

Routage par attributs

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

API Web ASP.NET 2

Routage par attributs

API Web ASP.NET prend désormais en charge le routage des attributs, grâce à une contribution de Tim McCall, l’auteur de http://attributerouting.net. Avec le routage des attributs, vous pouvez spécifier vos itinéraires d’API web en annoteant 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 des attributs vous donne plus de contrôle sur les URI de 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 d’itinéraire :

// 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 des attributs, consultez Routage des attributs dans l’API web 2.

OAuth 2.0

Les modèles de projet d’API web et d’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 un large éventail de clients, notamment les navigateurs et les appareils mobiles.

La prise en charge d’OAuth 2.0 est basée sur le nouveau middleware de sécurité fourni par les composants Microsoft OWIN pour l’authentification du porteur et l’implémentation du rôle serveur d’autorisation. Vous pouvez également autoriser les clients à l’aide d’un serveur d’autorisation organisationnelle, 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 et le traitement par lot de requêtes des jeux de modifications.

Les options $select et $expand vous permettent de modifier la forme des données retournées par un point de terminaison OData. Pour plus d’informations, consultez Présentation de $select et $expand prise en charge 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é et de lien multimédia, ajouter des annotations d’instance et personnaliser la façon dont les liens sont générés.

Prise en charge sans type

Vous pouvez maintenant générer 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 de devoir en créer un nouveau. Par exemple, si vous utilisez Entity Framework, vous pouvez utiliser l’EDM que EF génère pour vous.

Traitement par lots de requêtes

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

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

Pour activer le traitement par lots de requêtes, ajoutez simplement un itinéraire avec un gestionnaire de traitement par lots à 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 requêtes ou les exécutions séquentielles 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 vos applications Windows Store et Windows Phone 8. Vous pouvez également créer des formateurs portables qui peuvent être partagés entre le client et le serveur.

Amélioration de la testabilité

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 requête 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 le test unitaire de votre implémentation d’API web. Pour des raisons pratiques, un certain nombre d’implémentations IHttpActionResult sont fournies hors de la boîte de dialogue, y compris les résultats pour retourner des codes d’état spécifiques, du contenu mis en forme ou des réponses négociées sur le contenu.

HttpRequestContext

Le nouveau HttpRequestContext effectue le suivi d’un état lié à la requête, mais n’est pas immédiatement disponible à partir de la requête. Par exemple, vous pouvez utiliser HttpRequestContext pour obtenir des données de routage, le principal associé à la requête, 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 acheminé avec la requête au lieu de compter sur Thread.CurrentPrincipal, le principal est désormais disponible tout au long de la durée de vie de la requête pendant qu’elle 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 de détendre 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, notamment la gestion automatique des demandes préliminaires. 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. L’authentification filtre les informations d’identification dans la requête et fournit un principal correspondant. Les filtres d’authentification peuvent également ajouter des défis d’authentification en réponse aux demandes non autorisées.

Remplacements de filtre

Vous pouvez maintenant remplacer les filtres qui s’appliquent à une méthode ou un contrôleur d’action 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’exclure certaines actions ou 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. Également inclus est un HostAuthenticationFilter qui fournit une intégration avec le système d’authentification OWIN.

Avec l’intégration d’OWIN, vous pouvez héberger automatiquement l’API web dans votre propre processus en même temps que d’autres intergiciels OWIN, tels que SignalR. Pour plus d’informations, consultez Utiliser OWIN pour auto-hôte 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 repose entièrement sur OWIN (Open Web Interface for .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 requis 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 MapSignalRen . MapSignalRappelé sans paramètres mappe tous les hubs (comme MapHubs 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 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 la classe Owin Startup. 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 de hubs et de 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 de hubs et de 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 ont été contrôlées par un seul indicateur EnableCrossDomain. Cet indicateur a contrôlé les requêtes JSONP et CORS. Pour une plus grande flexibilité, 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 le nouveau middleware OWIN a été mis à la 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 navigateurs plus anciens), il doit être activé explicitement en définissant EnableJSONP l’objet truesur HubConfiguration , comme indiqué ci-dessous. JSONP est désactivé par défaut, car il est moins sécurisé que CORS.

Pour ajouter le nouvel intergiciel CORS dans SignalR 2.0, ajoutez la Microsoft.Owin.Cors bibliothèque à votre projet et appelez-le UseCors avant votre intergiciel 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 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 MapSignalRcode utilise Map et RunSignalR non pas , de sorte que l’intergiciel 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 spécifié dans MapSignalR.) Map peut également être utilisé pour tout autre intergiciel 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 Android via MonoTouch et MonoDroid

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

### Client .NET portable

Pour mieux faciliter le développement multiplateforme, les clients Silverlight, WinRT et Windows Phone ont été remplacés par un client .NET portable unique 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 auto-hôte

Il existe désormais un package NuGet pour faciliter la prise en main de SignalR auto-hôte (applications SignalR hébergées dans un processus ou une autre application, plutôt que d’être hébergées dans 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 auto-hôte.

Prise en charge du serveur à compatibilité descendante

Dans les versions précédentes de SignalR, les versions du package SignalR utilisées dans le client et le serveur doivent être identiques. Pour 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 ce que l’id utilisateur est 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 hubs, vous serez en mesure d’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/échouer l’appel de méthode hub.

Le paramètre d’exceptions du hub détaillé n’a aucune incidence sur HubException en cours d’envoi au client ou non ; il est toujours envoyé.

Code côté serveur illustrant l’envoi d’un 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 instance 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 instance HubException envoyée à partir du serveur

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

Test unitaire plus facile 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 des 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 pour les 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 lors de la 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 géré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 organisationnels via Azure Active Directory ou services de fédération Active Directory (AD FS) (ADFS).

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

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

Intégration OWIN

ASP.NET l’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. 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 les nouveaux composants serveur et hôte, les nouvelles bibliothèques d’assistance et les intergiciels d’authentification, ainsi que les nouveaux intergiciels d’authentification.

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

Remarque : les applications OWIN ne peuvent pas s’exécuter en mode classique IIS ; elles doivent être exécutées 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 auto-hôtes. 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 aux développeurs qui souhaitent héberger automatiquement 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 aux intergiciels de fournir des indicateurs au serveur SystemWeb , indiquant que l’intergiciel doit être appelé pendant une phase de pipeline ASP.NET spécifique. Cette fonctionnalité est particulièrement utile pour l’intergiciel d’authentification, qui doit s’exécuter tôt dans le pipeline ASP.NET.

Bibliothèques d’assistance et intergiciels

Bien que vous puissiez écrire des composants OWIN à l’aide uniquement des 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 OWIN Microsoft utilisent désormais ce package.

Remarque

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

Remarque

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

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

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 a été précédemment nommé Microsoft.Owin.Security.Forms.
  • Microsoft.Owin.Security.Facebook active l’authentification à l’aide du service 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 package, qui contient un Microsoft.Owin.Cors intergiciel pour le traitement des requêtes HTTP d’origine croisée.

Remarque

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 dans Entity Framework 6, consultez l’historique des versions d’Entity Framework.

ASP.NET Razor 3

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

  • Prise en charge de la modification de tabulation. Auparavant, la commande Format du 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 onglets.
  • 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é.

    Remarque

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

=======

suspension de l’application ASP.NET

ASP.NET App Suspend est une fonctionnalité qui change de jeu dans le .NET Framework 4.5.1 qui modifie 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’hébergement web .NET réactif de l’application.

Problèmes connus et changements cassants

Cette section décrit les problèmes connus et les changements cassants dans la 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 un prochain 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 un prochain nuget.exe 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 pour $select et $expand.

    Nos exemples précédents pour ODataQueryOptions<T> toujours casté la valeur de retour de ApplyTo .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 que la valeur de retour ne ApplyTo sera IQueryable<T> pas toujours disponible.

    // 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 à partir d’une version antérieure, 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 modifier ce code vers ce code.

    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 pendant une demande de traitement 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 une 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 « / ».

    Revendication de type http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier ou https://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider non présente sur l’argument 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 la corriger :

    AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name;

    Cette opération sera corrigée pour la prochaine version.

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

    [A]System.Web.WebPages.Razor.Configuration.HostSection ne peut pas être converti en [B]System.Web.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' at location '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 » sur « 5.0.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.Web.WebPages.Razor » sur « 3.0.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 Comment mettre à niveau un projet ASP.NET d’API MVC 4 et MVC 4 vers ASP.NET MVC 5 et l’API web 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 requise (« 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 se trouve généralement avec du code généré automatiquement pour un modèle avec une propriété entière sur les vues Créer et Modifier.

    Pour contourner ce problème, modifiez l’assistance de l’éditeur à partir de :

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

    Par :

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

  4. ASP.NET MVC 5 ne prend plus en charge la confiance 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 élimine 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, en tant qu’effet secondaire, vous ne pouvez pas utiliser les assemblys 4.0 et 5.0 dans la même application. Vous devez les mettre à jour sur la version 5.0.

Le modèle SPA avec autorisation Facebook peut entraîner une instabilité dans Internet Explorer pendant que le site web est hébergé dans une 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 entraîner un blocage d’Internet Explorer.

Solution :

  1. Héberger le site web dans une zone Internet ; ou

  2. Testez le scénario dans un navigateur autre que IE.

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

La génération de modèles automatique Web Forms a été supprimée de VS2013 et sera disponible dans une prochaine mise à jour vers 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 une structure 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 généré automatiquement et sélectionnez Dépendances MVC 5. Sélectionnez Minimal ou Full selon que vous avez besoin de tous les fichiers de contenu, tels que des scripts. Ensuite, ajoutez un élément généré automatiquement pour MVC, qui créera des vues et un contrôleur dans votre projet.

Génération automatique de modèles MVC et API web - Erreur HTTP 404, introuvable

Si une erreur se produit lors de l’ajout d’un élément généré automatiquement à un projet, il est possible que votre projet soit laissé dans un état incohérent. Certaines des modifications apportées à la génération de modèles automatique seront restaurées, mais d’autres modifications, telles que les packages NuGet installés, ne seront pas restaurées. Si les modifications de configuration de routage sont restaurées, les utilisateurs reçoivent une erreur HTTP 404 lors de la navigation vers des éléments générés automatiquement.

Solution de contournement :

  • Pour corriger cette erreur pour MVC, ajoutez un nouvel élément généré automatiquement 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