En effet, si vous développez un projet ASP.NET Core qui utilise uniquement le CoreCLR, vous ne devez qu’utiliser les dépendances qui offrent une prise en charge du CoreCLR.

Depuis l’annonce de .NET Core, de nombreux éditeurs de librairies se sont activés pour offrir une prise en charge de cette version, c’est notamment le cas des outils de tests, dont MSTest.

Microsoft a publié il y a quelques semaines une préversion de la V2 de MsTest, qui introduit une architecture unifiée et apporte une prise en charge de .NET Core. Dans le cadre de ce billet de blog, nous verrons comment mettre en place des tests unitaires dans un projet ASP.NEt MVC Core avec MSTest V2.

Nous allons dans un premier temps créer une application ASP.NET Core en utilisant le modèle Web Application.

Ceci fait, vous allez ajouter un nouveau projet de type bibliothèque de classe à votre projet. Pour l’instant, il n’existe pas de modèle de projet pour la nouvelle version du framework de test de Microsoft. Cette prise en charge sera effective dans la version stable de l’outil, avec la sortie de Visual Studio 15.

Ajoutez les dépendances suivantes à votre projet en utilisant la console Nuget :

• MSTest.TestFramework
• MSTest.TestAdapter
• dotnet-test-mstest

Le package MSTest.TestFramework permet d’installer le framework MSTest V2. Pour l’installer, cliquez sur Tools dans la barre de menu de Visual Studio, puis Nuget Package Manager, ensuite sur Package Manager Console. Rassurez-vous que dans la zone Default Project, vous avez sélectionné votre projet de test :

Dans la console NuGet, tapez la commande suivante :

Install-Package MSTest.TestFramework -Pre

MSTest.TestAdapter est utilisé pour trouver et exécuter le framework de test sur lequel votre projet de test est basé. Pour l’installer, vous devez exécuter la commande suivante dans la console NuGet :

Install-Package MSTest.TestAdapter -Pre:

Enfin, vous allez exécuter la commande suivante pour installer le dernier package NuGet :

Install-Package dotnet-test-mstest -Pre

Vous allez probablement obtenir un message d’erreur d’incompatibilité lors de la restauration des packages par NuGet. Ouvrez le fichier Project.json et remplacez :

"frameworks": {
   "netstandard1.6": {
     "imports": "dnxcore50"
   }
}

Par

"frameworks": {
   "netcoreapp1.0": {
     "imports": [
       "dnxcore50",
       "portable-net45+win8"
     ],
 
     "dependencies": {
       "Microsoft.NETCore.App": {
         "version": "1.0.0",
         "type": "platform"
       }
     }
   }
 }

Vous remarquerez sans doute que nous avons marqué notre bibliothèque de classes comme une application (netcoreapp1.0). Cela est dû au fait que notre projet de test utilise le .NET CLI. Sa méthode Main sera fournie par le runner de mstest.

Vous devez par la suite ajouter au fichier Project.json la ligne suivante, pour spécifier que votre projet de test unitaire repose sur mstest :

« testRunner »: « mstest »,

Ajoutez une référence au projet ASP.NET Core. Votre fichier Project.json devrait ressembler à ceci :

{
 "version": "1.0.0-*",

 "testRunner": "mstest",

 "dependencies": {
   "dotnet-test-mstest": "1.1.1-preview",
   "MSTest.TestAdapter": "1.0.3-preview",
   "MSTest.TestFramework": "1.0.1-preview",
   "NETStandard.Library": "1.6.0",
   "SampleApp": "1.0.0-*"
 },

 "frameworks": {
   "netcoreapp1.0": {
     "imports": [
       "dnxcore50",
       "portable-net45+win8"
     ],

     "dependencies": {
       "Microsoft.NETCore.App": {
         "version": "1.0.0",
         "type": "platform"
       }
     }
   }
 }

}

Ajoutez un nouveau fichier HomeControllerTest.cs à votre projet de test. Ajoutez un appel à l’espace de nom Microsoft.VisualStudio.TestTools.UnitTesting :

using Microsoft.VisualStudio.TestTools.UnitTesting;

Jetons maintenant un coup d’œil au fichier HomeController.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;

namespace SampleApp.Controllers
{
   public class HomeController : Controller
   {
       public IActionResult Index()
       {
           return View();
       }

       public IActionResult About()
       {
           ViewData["Message"] = "Your application description page.";

           return View();
       }

       public IActionResult Contact()
       {
           ViewData["Message"] = "Your contact page.";

           return View();
       }

       public IActionResult Error()
       {
           return View("~/Views/Shared/Error.cshtml");
       }
   }
}

Nous allons écrire du code pour tester le ViewResult et une autre pour le ViewData.

Le code que nous allons écrire va permettre de vérifier que la méthode d’action Error() retourne le bon ViewResult. Le code de test est le suivant :

[TestMethod]
        public void Error_ReturnErrorView()
        {
            // Arrange
            var controller = new HomeController();
            var errorView = "~/Views/Shared/Error.cshtml";

            // Act
            var viewResult = controller.Error() as ViewResult;

            // Assert
            Assert.AreEqual(errorView, viewResult.ViewName);
        }

Pour le ViewData, nous allons tester que notre méthode d’action renvoie le bon ViewData. La méthode de test pour effectuer cela est la suivante :

[TestMethod]
       public void About_ReturnViewData()
       {
           // Arrange
           var controller = new HomeController();
           var viewData = "Your application description page.";

           // Act
           var viewResult = controller.About() as ViewResult;

           // Assert
           Assert.AreEqual(viewData, viewResult.ViewData["Message"]);
       }

Le code complet est le suivant :

[TestClass]
    public class HomeControllerTest
    {


        [TestMethod]
        public void Error_ReturnErrorView()
        {
            // Arrange
            var controller = new HomeController();
            var errorView = "~/Views/Shared/Error.cshtml";

            // Act
            var viewResult = controller.Error() as ViewResult;

            // Assert
            Assert.AreEqual(errorView, viewResult.ViewName);
        }


        [TestMethod]
        public void About_ReturnViewData()
        {
            // Arrange
            var controller = new HomeController();
            var viewData = "Your application description page.";

            // Act
            var viewResult = controller.About() as ViewResult;

            // Assert
            Assert.AreEqual(viewData, viewResult.ViewData["Message"]);
        }

    }

A l’exécution, vous allez obtenir le résultat suivant dans l’explorateur de test :

C’est tout. Dans un prochain billet, nous verrons comment écrire des tests unitaires smockés avec mstest v2 et la preview de Moq, qui prend aussi en charge .NET Core.

Le Web évolue rapidement, et Microsoft est conscient de cela. L’éditeur a ainsi adopté un cycle de mise à jour pour ASP.NET plus rapide que celui de Visual Studio.

La société compte donc publier une mise à jour pour sa plateforme de développement Web ASP.NET en début d’année prochaine.

Les développeurs qui veulent commencer à « jouer » avec les nouvelles fonctionnalités de cette mise à jour peuvent déjà télécharger sa version Release Candidate (RC) qui vient d’être publiée par les équipes ASP.NET et Visual Web Developer de Microsoft.

« ASP.NET et Web Tools 2012.2 » RC étend le runtine ASP.NET existant et ajout de nouveaux outils Web à Visual Studio 2012 pour WebForms, MVC, WebAPI, etc. Il s’agit des fonctionnalités suivantes :

1. De nouveaux modèles de projets ASP.NET MVC. la création d’applications Facebook est désormais plus facile avec le modèle Facebook, qui permet en quelques étapes de créer une application qui interagir avec le réseau social. Le nouveau modèle « Single Page Application » permet aux développeurs de créer des applications Web interactives côté client à l’aide de jQuery, Knockout et ASP.NET Web API ;
2. Le support de la communication en temps réel avec ASP.NET SignalR. SignalR est une bibliothèque client/serveur qui permet aux clients basés sur un navigateur et aux composants serveur basés sur ASP.NET d’avoir une conversation à étapes multiples et bidirectionnelle;
3. Le support de l’IntelliSense pour Knockout et l’ajout de la prise en charge de JSON en tant que classe ;
4. L’introduction de nouvelles fonctionnalités pour ASP.NET Web API, y compris le support d’OData, l’ajout des fonctions de traçabilité, de monitoring et de génération d’une page d’aide pour une API Web;
5. Des améliorations de l’inspecteur de page, qui offre désormais de meilleures performances pour JavaScript et CSS, dont la capacité de voir les mises à jour en temps réel d’un fichier CSS ;
6. L’unification de l’expérience de publication pour une application Web et un projet de type site Web, ainsi que l’ajout des options de publication sélective ;
7. L’intégration de la nouvelle fonctionnalité ASP.NET Friendly URL. Cette fonction rend facile la génération des URL sans l’extension .aspx. Elle permet également au développeur d’ajouter plus facilement le support du mobile dans son application Web ;
8. La mise à jour des modèles de projets Web dans Visual Studio 2012.

Cette mise à jour est livrée comme des packages NuGet supplémentaires. Ce qui signifie qu’il ne peut avoir aucun problème de compatibilité avec les projets existants.

Télécharger « ASP.NET et Web Tools 2012.2″ RC

Une des nouveautés les plus intéressantes qu’apporte Entity Framework 4.3 est la migration pour les mises à jour de la base de données.

Cette fonctionnalité offre aux développeurs des outils permettant d’appliquer avec souplesse et facilité des mises à jour à la base de données à partir des modifications apportées à l’application.

Dans un précédent billet de blog, j’ai présenté cette fonctionnalité et comment l’on pouvait l’utiliser pour effectuer des mises à jour de la base de données.

Cet article présentait uniquement l’un des modes de mises à jour qu’offre Entity Framework : le mode basé sur le code.

Supposons que vous disposez déjà d’une application utilisant Entity Framework Code First. Procédez à la mise à jour de celle-ci pour utiliser la version 4.3 d’Entity Framework si ce n’est pas encore le cas.

Vous pouvez utiliser la commande :

PM> install-package EntityFramework

Activer la migration

La première étape est d’activer la migration pour votre DbContext, en utilisant la console du gestionnaire de packages (menu Outils/Gestionnaire de package/Package Manager Console de Visual Studio). Vous allez exécuter la commande « Enabled-Migrations ».

L’activation de la migration crée un nouveau dossier Migrations dans votre application contenant un fichier Configurations.cs permettant de définir le comportement de la migration pour le DbContext qui est utilisé.

namespace DatabaseMigration.Migrations
{
    using System;
    using System.Data.Entity;
    using System.Data.Entity.Migrations;
    using System.Linq;

    internal sealed class Configuration : DbMigrationsConfiguration<DatabaseMigration.DatabaseMigrationContext>
    {
        public Configuration()
        {
            AutomaticMigrationsEnabled = false;
        }

        protected override void Seed(DatabaseMigration.DatabaseMigrationContext context)
        {
            
        }
    }
}

Si vous avez défini plusieurs «DbContext » dans votre application, il suffira juste de modifier DbMigrationsConfiguration(T), en remplaçant T par le nom du DbContext que vous voulez utiliser.

Configurer la migration automatique

Par défaut, la propriété AutomaticMigrationsEnabled est définie à false. Pour utiliser la migration automatique, vous devez affecter la valeur « true » à cette propriété.

Il également possible de définir cette propriété à true lors de l’activation de la migration. Pour cela, vous devez ajouter le paramètre EnableAutomaticMigrations à la commande permettant d’activer la migration :

PM> Enable-Migrations -EnableAutomaticMigrations

Par défaut, la migration automatique n’autorise pas les mises à jour pouvant entrainer des pertes de données. Pour activer cette option, vous devez éditer le fichier Configuration.cs en y ajoutant la propriété « AutomaticMigrationDataLossAllowed » qui sera définie à true.

public Configuration()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;
        }

Editez ensuite votre DbContext et ajoutez-y la procédure onModelCreating :

protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            Database.SetInitializer(new MigrateDatabaseToLatestVersion<DatabaseMigrationContext, Configuration>());
        }

Et voilà, c’est tout ;). Toute modification de votre modèle objet (nouvelle entité, ajout d’une propriété, suppression d’une propriété, etc.) sera automatiquement appliquée à la base de données à l’exécution de votre application.

Inconvénients de la migration automatique

La migration automatique permet d’apporter assez rapidement et simplement des mises à jour à une base de données en utilisant Entity Framework Code First. Cette option présente cependant des inconvénients, et personnellement, je ne recommanderais pas son utilise en environnement de production ou sur un système critique.

L’utilisation du mode automatique en environnement de production peut s’avérer assez dangereuse, avec un risque de perte de données, car les modifications apportées à la base de données sont imprévisibles par le développeur, et celui-ci n’a aucune visibilité sur ces changements.

Néanmoins, vous pouvez limiter ces risques en environnement de production en désactivant l’autorisation des mises à jour pouvant entrainer des pertes de données.

Les versions Express sont des déclinaisons gratuites, allégées de Visual Studio intégrant des fonctionnalités et outils de bases. Les différentes éditions Express à venir avec Visual Studio 11 seront :

Visual Studio 11 Express pour Windows 8 ;
Visual Stduio 11 Express pour le Web ;
Visual Studio 11 Express pour Azure ;
Visual Studio 11 Express pour Windows Phone.

Chaque édition supportera l’ensemble des langages .NET et Web à savoir C#, Visual Basic, F#, C++ et JavaScript. Visual Studio 11 Express pour Windows 8 par exemple permettra la conception des applications Metro fondées sur WinRT.

Visual Studio 11 Express pour Windows Phone sera publiée avec la prochaine mise à jour Windows Phone 8, de même que pour Azure, afin de prendre en charge les nouvelles fonctionnalités et améliorations de ces plateformes.

Par ailleurs, LightSwitch, qui permet de développer rapidement des applications métiers sera désormais intégré par défaut dans Visual Studio 11.

Les exigences matérielles de Visual Studio 11 seront pareilles que celles de Visual Studio 10, à la différence que celui-ci fonctionnera uniquement sur Windows 7 ou Windows 8. Les applications managées cibleront par défaut le Framework .NET 4.5 et les applications natives VC11, ce qui suppose qu’elles ne fonctionneront que sur Windows Vista et versions supérieures.

Néanmoins, les développeurs qui veulent publier leurs applications managées sur Windows XP ou Windows Server 2003 pourront changer la cible pour le Framework .NET 4.0. Pour les applications natives, ils devront se retourner vers Visual Studio 2010.

Visual Studio est actuellement disponible en version Beta. La Release Candidate (RC) sera probablement publiée la première semaine de juin avec la Preview de Windows 8

Cependant, jusqu’ici, lors de nos tests, vous pouvez vous rendre compte que notre application ne dispose d’aucun mécanisme permettant à un l’utilisateur à partir de l’interface de choisir une langue ou de basculer d’une langue à une autre à tout moment.

Cet aspect de l’internationalisation d’une application Web ASP.NET MVC 3 Razor fera l’objet de ce billet de blog.

Nous allons utiliser l’application que nous avons créée précédemment.

Dans notre cas, nous allons définir la langue qui est utilisée dans L’URL. Pour cela, nous allons commencer par définir la stratégie de routage qui sera utilisée dans notre application, en spécifiant la langue. L’URL que nous allons utilisera sous la forme suivante :

http://localhost/fr-fr/home/index pour le français
et
http://localhost/en-us/home/index pour l’anglais.

La route par défaut dans ASP.NET MVC 3 est définie sous la forme : http://localhost/controller/action/id. À partir de là, nous allons définir de nouveaux paramètres de route qui permettront de générer l’URL avec la langue. Pour cela, nous allons définir la route sous la forme suivante : http://localhost/lang/controller/action/id.

Pour atteindre ce résultat, il suffit de modifier le fichier Global.ascx.cs, et enregistrer une nouvelle route. Le code pour faire cela est le suivant :

public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
            routes.IgnoreRoute("favicon.ico");

            routes.MapRoute(
               "LocalizedDefault", // Route name
               "{lang}/{controller}/{action}/{id}", // URL with parameters
               new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
           );

            routes.MapRoute(
                "Default", // Route name
                "{controller}/{action}/{id}", // URL with parameters
                new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
            );
        }

Maintenant, vous devez ajouter un nouveau contrôleur (BaseController) qui héritera de System.Web.Mvc.Controller. Sa fonction principale sera de changer la langue du Thread d’exécution courant selon la valeur de la langue dans l’URL ou dans un cookie existant, et de sauvegarder le choix linguistique de l’utilisateur dans un cookie si ce n’est pas déjà fait. Si aucune langue n’est spécifiée dans l’URL, la langue du Thread d’exécution sera modifiée en utilisant par défaut la langue du navigateur de l’utilisateur.

Le code pour faire cela est le suivant :

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Text;
using System.Threading;
using System.Globalization;

namespace MvcApplication1.Controllers
{
    public class BaseController : Controller
    {
        //
        // GET: /Base/

        protected override void ExecuteCore()
         {
             if (RouteData.Values["lang"] != null &&
              !string.IsNullOrWhiteSpace(RouteData.Values["lang"].ToString()))
             {
                 // modification de la culture dans les données de la route
                 var lang = RouteData.Values["lang"].ToString();
                 Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture(lang);
             }
             else
             {
                 // chargement de la culture depuis un cookie
                 var cookie = HttpContext.Request.Cookies["MvcApplication1.CurrentUICulture"];
                 var langHeader = string.Empty;
                 if (cookie != null)
                 {
                     // modification de la culture avec la valeur dans le cookie
                     langHeader = cookie.Value;
                     Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture(langHeader);
                 }
                 else
                 {
                     // utilisation de la langue par défaut du naviageteur si la culture n'est pas spécifiée
                     langHeader = HttpContext.Request.UserLanguages[0];
                     Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture(langHeader);
                 }
                 // modification de la culture dans les données de la route
                 RouteData.Values["lang"] = langHeader;
             }

             // sauvegarde de la culture dans un cookie
             HttpCookie _cookie = new HttpCookie("MvcApplication1.CurrentUICulture", Thread.CurrentThread.CurrentUICulture.Name);
             _cookie.Expires = DateTime.Now.AddYears(1);
             HttpContext.Response.SetCookie(_cookie);

             base.ExecuteCore();
         }

    }
}

Tous les contrôleurs de l’application doivent être modifiés pour hériter de ce contrôleur (Basecontrolleur).

public class HomeController : BaseController

Après avoir enregistré la route localisée, nous devons procéder à l’écriture d’une fonction permettant de générer l’URL localisée en fonction du choix de la langue de l’utilisateur.
Pour cela, nous allons ajouter un HTML Helper dans notre projet. Les Helpers HTML sont des méthodes d’extensions pour les classes HtmlHelper. Ces méthodes sont accessibles dans une vue à partir de la méthode HTML.

Le code pour notre Helper HTML est le suivant :

public static class SwitchLanguageHelper
    {
        public class Language
        {
            public string Url { get; set; }
            public string ActionName { get; set; }
            public string ControllerName { get; set; }
            public RouteValueDictionary RouteValues { get; set; }
            public bool IsSelected { get; set; }

            public MvcHtmlString HtmlSafeUrl
            {
                get
                {
                    return MvcHtmlString.Create(Url);
                }
            }
        }

        public static Language LanguageUrl(this HtmlHelper helper, string cultureName,
            string languageRouteName = "lang", bool strictSelected = false)
        {
            
            cultureName = cultureName.ToLower();
            // récuperation des valeurs de ka route depuis le view context
            var routeValues = new RouteValueDictionary(helper.ViewContext.RouteData.Values);
            
            //copie de la chaine de requête dans les valeurs de route pour générer le nouveau lien
            var queryString = helper.ViewContext.HttpContext.Request.QueryString;
            foreach (string key in queryString)
            {
                if (queryString[key] != null && !string.IsNullOrWhiteSpace(key))
                {
                    if (routeValues.ContainsKey(key))
                    {
                        routeValues[key] = queryString[key];
                    }
                    else
                    {
                        routeValues.Add(key, queryString[key]);
                    }
                }
            }
            var actionName = routeValues["action"].ToString();
            var controllerName = routeValues["controller"].ToString();
            //modification de la langue dans les valeurs de route
            routeValues[languageRouteName] = cultureName;
            //génération de l'url avec la langue
            var urlHelper = new UrlHelper(helper.ViewContext.RequestContext, helper.RouteCollection);
            var url = urlHelper.RouteUrl("LocalizedDefault", routeValues);
            // vérification si la culture courante correspond à celle passée en paramètre
            var current_lang_name = Thread.CurrentThread.CurrentUICulture.Name.ToLower();
            var isSelected = strictSelected ?
                current_lang_name == cultureName :
                current_lang_name.StartsWith(cultureName);
            return new Language()
            {
                Url = url,
                ActionName = actionName,
                ControllerName = controllerName,
                RouteValues = routeValues,
                IsSelected = isSelected
            };
        }

        
        public static MvcHtmlString LanguageSelectorLink(this HtmlHelper helper,
           string cultureName, string selectedText, string unselectedText,
           IDictionary htmlAttributes, string languageRouteName = "lang", bool strictSelected = false)
        {
            var language = helper.LanguageUrl(cultureName, languageRouteName, strictSelected);
            var link = helper.RouteLink(language.IsSelected ? selectedText : unselectedText,
                "LocalizedDefault", language.RouteValues);
            return link;
        }

       
    }

Enfin, dans le dossier View/Shared, nous allons ajouter une vue partielle (_SelectLanguage.cshtml) pour la sélection de la langue par l’utilisateur.
Le code pour cette page est le suivant :

@using MvcApplication1.MyHelper

@Html.LanguageSelectorLink("en-US", "[English]", "English", null)
@Html.LanguageSelectorLink("fr-FR", "[Français]", "Français", null)

La vue partielle doit être appelée dans le Layout de votre projet :

<div id="logindisplay">
                @Html.Partial("_LogOnPartial")
                @Html.Partial("_SelectLanguage
</div>

Nous pouvons maintenant exécuter l’application pour voir le résultat produit comme l’illustrent les captures suivantes :

Et voilà, nous venons de finir avec la dernière étape d’internationalisation de notre application. J’espère que ce tutoriel vous sera d’une grande utilité pour créer des applications ASP.NET MVC 3 multilingues ;).

En me basant donc du meilleur que j’ai pu tirer de quelques articles par-ci par-là et mon expérience, j’ai mis au point une solution qui répondait à mes besoins pour une application ASP.NET MVC Razor. Cette méthode n’est pas standard, et peut-être pas la meilleure, mais elle répond pleinement aux exigences de mon projet et aux objectifs que je voulais atteindre.

Ce qu’il faut savoir sur l’internationalisation dans l’écosystème .NET

Avant de se lancer dans la création d’un site multilingue en ASP.NET, il y a un certain nombre de concepts que vous devriez au préalable savoir. Lorsqu’on parle d’internationalisation d’une application sur la plateforme .NET, cela implique la mise en œuvre de deux mécanismes principaux à savoir : la mondialisation et la localisation.

La mondialisation est le processus de conception et de développement d’un produit logiciel adapté à plusieurs cultures. Une application mondialisée prend en charge des interfaces utilisateurs localisées et des données régionales pour tous les utilisateurs. Par exemple, le format de la date en zone francophone est jj/mm/aaaa. Dans les pays anglophones, nous avons plutôt le format mm/jj/aaaa. La mondialisation va consister à afficher le bon format dans une page en fonction de la langue du navigateur d’un utilisateur ou des options choisies par celui-ci.

La localisation est le processus d’adaptation de votre application à une culture et aux paramètres régionaux donnés. Vous devez pendant cette étape, personnaliser votre application pour les cultures auxquelles vous la destinez. Cette étape doit consister essentiellement en une traduction de l’interface utilisateur vers les langues cibles.

Différentes possibilités d’internationalisation d’une application ASP.NET

Il existe sur la plateforme .NET plusieurs procédés pour rendre son site multilingue. L’internationalisation d’une application peut donc être faite en utilisant soi :

– Les fichiers de ressources ;

– Des vues différentes pour chaque culture (traduction dans le code) ;

– Des fichiers texte ;

– Utiliser à la place des fichiers de ressources une base de données ;

– Ou combiner la première et la seconde méthode.

Chacune de ces techniques à ses avantages et ses inconvénients, et l’orientation vers l’une d’entre elles dépend aussi entre autres des spécifications de votre projet et des contraintes techniques auxquelles vous êtes confrontés. Personnellement je préfère les fichiers de ressources que j’utilise couramment lorsque je suis confronté à cette problématique.

Les fichiers ressources sont des fichiers textes optimisés. Au chargement, ils sont entièrement triés afin de limiter les accès que ce soit au niveau de la mémoire ou des différents disques.
C’est pourquoi, dans le cadre de ce tutoriel, nous nous limiterons uniquement à l’utilisation des fichiers de ressources.

Prérequis

– Visual Web Developer 2010 ;

– ASP.NET MVC 3 ;

– Connaissance de base en C# et sur le moteur de vue Razor.

Création de l’application

Nous allons commencer dès la base même, par la création d’une nouvelle application qui sera utilisée tout au long de l’article.
Pour ce faire, vous allez démarrer votre EDI Visual Studio. Cliquez sur le menu Fichier, ensuite sur la commande Nouveau projet. Dans la fenêtre qui va s’afficher, sélectionnez le Template de projet ASP.NET MVC 3 Web Application, renseignez le nom de l’application et l’emplacement ou celle-ci va être stockée et cliquez sur OK.

Sélectionnez ensuite dans la fenêtre qui va s’afficher le modèle de projet Internet Application, en vous assurant que le moteur de vue qui sera utilisé est Razor.

Cliquez ensuite sur OK pour que Visual Studio procède à la création de votre application.

Si vous exécutez l’application à ce stade, vous vous rendrez compte que le texte affiché par défaut dans vos pages est en anglais.

Puisque vous souhaitez que l’internaute qu’il soit anglophone ou francophone puissent se sentir à l’aise dans la navigation sur votre site, vous allez ajouter à celui-ci en plus du support de l’anglais, la prise en charge du français.

Pour atteindre ce résultat, les premières étapes suivantes sont nécessaires :

– Création des fichiers de ressources ;

– Modification des vues ;

– Définition de la culture.

Création des fichiers de ressources

Pour gérer efficacement l’internationalisation dans notre application, nous avons opté pour l’utilisation des fichiers de ressources pour stocker les valeurs qui doivent être localisées.

Ce qu’il faut savoir sur les fichiers de ressources

Une ressource est une donnée non exécutable qui est déployée logiquement avec une application. Les ressources peuvent contenir des données sous plusieurs formes, telles que des chaînes, des images ou des objets rendus persistants. Le stockage de vos données dans un fichier de ressources vous permet de changer les données sans avoir à recompiler l’intégralité de votre application.

Le format de fichier de ressources .resx se compose d’entrées XML, qui spécifient des objets et des chaînes dans des balises XML. Le .NET Framework fournit une prise en charge complète pour la création et la localisation des ressources. Ceux-ci doivent être créés d’une façon particulière pour fonctionner correctement.

Les fichiers de ressources de la langue par défaut de votre application doivent être nommés comme suit : nom_du_fichiers.resx.

Les fichiers pour les autres langues doivent suivre le format suivant : nom_du_fichier.culture.resx.

Ce qu’il faut savoir sur la culture

La culture ici doit définir le code la langue. Un code de langue est une convention symbolique permettant d’identifier une langue ou une variété dialectale ou régionale, ou un ensemble de langues par un identifiant défini dans un code, sans avoir à nommer la langue désignée elle-même.

La culture peut être neutre. Dans ce cas, elle sera codée sur deux caractères.

Exemple : en pour l’Anglais et fr pour le français.

Ou être stricte. Dans ce cas, elle sera codée sur quatre caractères ayant le format suivant « xx-XX », deux caractères minuscules pour la langue, et les deux suivantes en majuscules pour la variante régionale.

Exemple : fr-FR pour le français de France, en-US pour l’anglais des États-Unis et en-GB pour l’anglais de la Grande-Bretagne.

NB : Le fichier de ressource par défaut est utilisé si aucune culture n’est définie dans l’application ou si aucune ressource n’existe pour la culture qui a été définie.

Architecture.

Pour rester dans la logique de regroupement qu’impose ASP.NET MVC, il est préférable que l’arborescence de vos fichiers de ressources soit semblable à la capture ci-dessous :

Vous allez donc créer un dossier Ressources, en faisant un clic droit dans l’explorateur de projet et en cliquant sur Ajouter, puis en sélectionnant l’option Nouveau dossier.

Dans ce dossier vous allez procéder de même pour créer les dossiers Models, Views, etc.

Par la suite, vous devez créer les différents fichiers de ressources.
Je vous recommande de commencer par celui de la page Layout.chtml. Pour cela, vous allez créer les fichiers Layout.resx pour la langue par défaut et Layout.fr.resx pour le français.

Pour créer ces fichiers, faites un clic droit sur le sous-dossier Shared, sélectionnez l’option Ajouter, puis cliquez sur Ajouter un nouvel élément.
Dans la boite de dialogue qui va s’afficher, sélectionnez le type de fichier Ressources File, et renseignez le nom _Layout.resx dans la zone réserver à cet effet, puis cliquez sur Ajouter.

Faites de même pour créer le fichier Layout.fr.resx et les autres fichiers de ressources.

Maintenant, vous devez déplacer les textes qui sont dans votre fichier _Layout.cshtml dans le fichier de ressources, en renseignant le nom (comme celui d’une variable), la valeur (qui est le texte contenu dans le page) et une description s’il y a lieu.

Prenez la peine de vérifier que la zone « Acces Modifier » est définie à Public. Sinon, les valeurs que vous avez définies ne seront pas accessibles dans les vues.

Renseignez également la traduction de ces textes pour le fichier _Layout.fr.resx.

Attention, le nom doit être le même que celui que vous avez défini dans le fichier de ressources par défaut pour cette page.

NB : Contrairement à ASP.NET WebForms où il est conseillé de créer les fichiers de ressources dans les dossiers App_GlobalResources et App_LocalResources, avec ASP.NET MVC, l’utilisation de ces dossiers sera une source de problèmes pour vous. Je vous conseille donc d’utiliser un dossier différent (comme ce que nous avons fait plus haut), ou créer les ressources dans une librairie séparée.

Pour plus de détail sur le sujet, je vous invite à lire cet excellent billet de blog de K. Scott Allen : Resource Files and ASP.NET MVC Projects.

Modification de la vue

Maintenant que vous avez transféré le texte de la vue vers les fichiers de ressources, vous devez maintenant faire pointer les zones d’affichage de ces textes vers les ressources correspondantes.

Pour cela, ouvrez le fichier Layout.chstml et remplacez le texte suivant :

<div id="title">
   <h1>My MVC Application</h1>
</div>

Par

<div id="title">
   <h1> @MvcApplication1.Resources.Views.Shared._Layout.Title</h1>
</div>

En observant ces lignes de code, vous pouvez constater que la valeur est accessible comme une propriété de classe. En effet, toutes les ressources sont compilées vers une DLL (MvcApplication1.Resources.Views.Shared). Le nom du fichier (_Layout) est utilisé comme nom de la classe et le nom donné au texte est considéré comme celui de la propriété de la classe.

Premier aperçu

À ce stade, si tout est correct, vous pouvez déjà obtenir un premier aperçu de votre application localisée en définissant juste la culture qui est utilisée par celle-ci.

Pour cela, vous pouvez simplement définir la culture dans le fichier Globla.aspx en utilisant la méthode Application_BeginRequest qui est exécutée lors du lancement de l’application. Le code permettant de faire cela est le suivant :

protected void Application_BeginRequest(object sender, EventArgs e)
{
          
    Thread.CurrentThread.CurrentUICulture = CultureInfo.CreateSpecificCulture("fr");
} 

En modifiant le paramètre qui est passé à la fonction, CreateSpecificCulture() entre l’anglais(en) et le français(fr), on obtient le résultat suivant :

Nous avons défini une seule valeur localisée pour la vue Layout. Vous pouvez faire de même pour les autres vues.

Voilà, nous venons de finir avec les premières étapes d’internationalisation de notre application, qui nous ont permis de créer les fichiers de ressources et localiser nos vues. Dans la partie suivante, nous verrons comment procéder pour les fichiers du modèle avec les messages d’erreur de validation et comment mettre en ouvre un mécanisme de basculer entre les cultures sur l’interface utilisateur.

Lire la partie suivante : Internationalisation d’une application ASP.NET MVC 3 Razor part 2 : messages d’erreur de validation et DisplayAttribute

Cependant, avec ASP.NET MVC, il est possible de définir les messages des erreurs de validation dans le modèle, au sein des attributs fournis par l’espace de noms DataAnnotations utilisé pour la validation des données utilisateur. Il est également possible de définir les textes par défaut qui seront affichés dans les vues pour les intitulés des champs des formulaires.

Si vous avez donc défini ces infirmations dans votre modèle, vous allez vous rendre compte que ce que nous avons fait jusqu’ici ne permet pas de localiser ces champs texte.

Nous verrons donc dans ce billet comment internationaliser les messages des erreurs de validation et les intitulés des champs des formulaires définis dans le modèle.

Pour cet exemple, nous allons créer dans l’application que nous avons utilisée précédemment (dans la partie 1) un formulaire permettant l’enregistrement des produits. La classe qui sera utilisée est la suivante :

public class ProductModel
    {
        public string Name { get; set; }
        public string Description { get; set; }
        public decimal Price { get; set; }
    }

Pour créer le modèle correspondant, ajoutez au dossier Model un fichier de classe ProductModel.cs qui contiendra le code ci-dessus.

À ce stade, aucune logique de validation des données n’est implémentée. À l’aide de DataAnnotations nous allons mettre en œuvre la validation des données pour cette classe.

Le nouveau code de la classe ProductModel produit est le suivant :

public class ProductModel
    {
        [Required(ErrorMessage = "Le libellé du produit est obligatoire")]
        [Display(Name = "Nom")]
        public string Name { get; set; }
        [Required(ErrorMessage = "La description du produit est obligatoire")]
        [Display(Name = "Description")]
        public string Description { get; set; }
        [Required(ErrorMessage = "La prix est obligatoire")]
        [Display(Name = "Prix")]
        [Range(0.01, 400.00, ErrorMessage = "Le prix doit être compris entre 0.01 et 400.00")]
        public decimal Price { get; set; }
    }

Nous allons commencer par internationaliser les messages des erreurs de validation.

Pour cela, dans le sous-dossier Model du dossier Resources, vous allez créer deux nouveaux fichiers de ressources ProductModel, dans lesquels vous allez définir les messages d’erreurs de validation pour cette classe comme l’illustre la capture ci-dessous :

Pour localiser ces valeurs, nous allons utiliser les propriétés ErrorMessageResourceType et ErrorMessageResourceName.

La propriété ErrorMessageResourceType permet de spécifier le type de message d’erreur qui est associé à un contrôle de validation.
La propriété ErrorMessageResourceName, quant à elle, sera utilisée pour définir le nom de la ressource pour recherche le message d’erreur.

Le nouveau code de la classe ProductModel permettant donc de faire cela est le suivant :

public class ProductModel
    {
        [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "NameRequired")]
        [Display(Name = "Nom")]
        public string Name { get; set; }
         [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "DescriptionRequired")]
        [Display(Name = "Description")]
        public string Description { get; set; }
         [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "PriceRequired")]
        [Display(Name = "Prix")]
        [Range(0.01, 400.00, ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "PriceRange")]
        public decimal Price { get; set; }
    }

À ce stade, si nous exécutons notre application, nous obtenons le résultat suivant :

Pour l’anglais

Pour le français

Nous avons finalisé avec les messages des erreurs de validation. Passons maintenant à la localisation des attributs Display.

Avec la version précédente d’ASP.NET MVC, la définition des noms des propriétés qui seront affichées dans l’interface utilisateur se faisait en décorant la propriété avec la classe DisplayNameAttribute. Cependant, elle ne possède qu’un seul constructeur et ne supporte pas de ce fait la localisation.

Pour internationaliser donc ces valeurs, il fallait du code personnalisé après beaucoup d’effort de programmation. Ce problème est résolu avec ASP.NET MVC 3. La localisation des noms des propriétés peut se faire assez aisément dans le modèle en utilisant la classe DisplayAttribute.

Cette classe possède plusieurs propriétés, y compris les propriétés ResourceType, permettant de définir le type de ressource pour les propriétés localisées et Name pour définir le nom de la ressource.

Le nouveau code de la classe ProductModel sera donc le suivant :

public class ProductModel
    {
        [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "NameRequired")]
        [Display(Name = "DisplayName", ResourceType = typeof(MvcApplication1.Resources.Models.ProductModel))]
         public string Name { get; set; }
         [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "DescriptionRequired")]
         [Display(Name = "DisplayDescription", ResourceType = typeof(MvcApplication1.Resources.Models.ProductModel))]
        public string Description { get; set; }
         [Required(ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "PriceRequired")]
         [Display(Name = "DisplayPrice", ResourceType = typeof(MvcApplication1.Resources.Models.ProductModel))]
        [Range(0.01, 400.00, ErrorMessageResourceType = typeof(MvcApplication1.Resources.Models.ProductModel),
             ErrorMessageResourceName = "PriceRange")]
        public decimal Price { get; set; }
    }

Les fichiers de ressources utilisés seront modifiés comme suit :

À ce stade, si nous exécutons notre application, nous obtenons le résultat suivant :

Pour l’anglais

Pour le français

Et voilà, nous venons de finir avec la localisation des textes du modèle. Vous pouvez vous rendre compte combien il est facile grâce aux nouveautés introduites par ASP.NET MVC 3 d’internationaliser les messages d’erreur de validation et les intitulés des champs des formulaires dans la vue.

La prochaine étape sera la mise au point sur l’interface utilisateur d’un mécanisme permettant à l’internaute de modifier la culture pour faire passer l’application d’une langue à une autre.

À première vue, il semblerait qu’il y ait une référence circulaire dans ma hiérarchie d’objets qui n’est pas prise en charge par le sérialiseur JSON.

En essayant de procéder au débogage de la procédure, je me suis rendu compte que le problème n’était pas au niveau de mon code, mais plutôt au niveau de la classe qui s’occupe de la sérialisation.

Quelle est donc la cause de cette erreur :

Pour les tables ayant des relations, l’utilitaire de mappage objet relationnel, génère des propriétés de référence dans chaque entité.

Prenons par exemple le schéma suivant de ma base de données :

Pour la table Liste_produit, L’objet généré aura une propriété Facture. Cependant, pour la table Facture, l’objet généré aura également une propriété Liste_produit. Conséquence : l’objet facture est lié à l’objet Liste_produit et vice-versa.

Ce scénario permet bien évidemment de bénéficier de beaucoup plus d’options lors du traitement de ces entités, mais crée cependant une ambiguïté pour le sérialiseur JSON lors de l’opération de sérialisation. D’où la génération de cette erreur.

Comment résoudre cela ?

Pour résoudre ce type de problème, nous pouvons utiliser deux solutions.

La première solution qui est plutôt simple est de marquer la relation comme une propriété interne.

Perso, je préfère ne pas utiliser cette méthode, car elle m’oblige à modifier mon EDM (Entity Data Model).

La seconde solution, qui est celle pour laquelle j’ai opté, consiste en l’utilisation d’un autre ViewModel en lieu et place de celui généré automatiquement par l’utilitaire de mappage objet/relationnel (ORM).

Cette approche est plus élégante dans la mesure ou elle permettra de sélectionner uniquement les données dont nous avons besoin et sérialiser uniquement celles qui nous intéressent. La conséquence directe est la réduction de la taille des données qui seront retournées dans notre vue et une amélioration de performance de notre application.

Pour utiliser cette méthode, nous devons :

– Dans un premier temps, créer une nouvelle classe qui contiendra uniquement les propriétés dont nous avons besoin.

public partial class ProduitL
    {

        public short Id_produit 
        {
            get; 
            set; 
        }
        public string Libelle_produit 
        { 
            get; 
            set; 
        }
        public string Conditionnement 
        { 
            get; 
            set; 
        }
        public int Quantite 
        { 
            get; 
            set; 
        }
        public decimal Prix 
        { 
            get; 
            set; 
        }
    }

Nous allons ensuite modifier la méthode d’action de notre contrôleur comme suit :

public JsonResult Facture(short id)
        {

            var results = from lp in db.Liste_produit
                    where lp.Id_facture == id
                    select new ProduitL
                    {
                        Id_produit = lp.Id_produit,
                        Libelle_produit = lp.produit.Libelle_ produit,
                        Conditionnement = lp. produit.Conditionnement,
                        Quantite = lp.Quantite,
                        Prix = lp.Prix  
                        
                    };
            return Json(results);
        }

ET voilà, à l’exécution de notre application, nous n’aurons plus cette erreur qui peut s’avérer désorientant pour certains.

Pire, si la bibliothèque utilisée nécessite la disponibilité d’autres bibliothèques externes, le développeur est obligé de répéter ces étapes pour chaque dépendance du composant.

Ces tâches peuvent donc s’avérer assez complexes et demandent parfois des efforts considérables en temps et énergie, sans compter le suivi des mises à jour qui sont parfois fréquentes pour certains composants. La gestion des dépendances pour une application peut donc rapidement devenir un casse-tête pour le développeur.

Nuget est un gestionnaire de package .NET open source qui automatise toutes ces tâches fastidieuses pour un package externe ainsi que ses dépendances dans une application. Nous verrons, au travers de ce tutoriel, cet outil fort intéressant et comment l’utiliser pour télécharger, installer, mettre à jour des packages dans Visual Studio 2010. Nous verrons, également comment générer et publier ses propres packages Nuget.

L’article est regroupé au sein des parties suivantes :

I. Introduction

II. Description de NuGet

III. Installation de NuGet

III-A. Installation à parti du site du projet

III-B. Installation à partir de Visual Studio

IV. Utilisation de NuGet

IV-A. Utilisation à partir de la console Package Manager

IV-B. Utilisation de l’interface graphique

V. Création et Publication de son propre package NuGet

V-A. Utilisation de Nuget.exe

V-B. Création et publication d’un package avec NuGet Package Explorer

VI. Conclusion

L’article complet est disponible sur cette page.

Télécharger la version PDF (Miroir).

Télécharger la version hors-ligne (Miroir).

Bonne lecture

Avec ces nouveautés, nous avons sans apporter aucune modification à nos modèles et contrôleurs, créé des vues personnalisées pour les navigateurs Desktop et les navigateurs mobiles.

Dans ce billet, nous verrons comment procéder autrement en utilisant le package Nuget JQuery.Mobile.MVC.

Le package jQuery.Mobile.MVC installe la librairie JQuery Mobile qui va permettre la création des interfaces Web optimisées pour les smartphones et autres terminaux tactiles, ainsi que plusieurs autres fichiers pour faciliter la tâche au développeur.

Ouvrons notre application ASP.NET MVC 4 avec votre éditeur Visual Studio 2010 SP 1 ou Visual Web Developper Express 2010 SP 1.

Nous allons dans un premier temps intégrer la bibliothèque JavaScript à notre projet en utilisant le gestionnaire de packages Nuget.

Pour cela, nous allons faire un clic droit sur notre projet dans l’explorateur de solution. Dans le menu contextuel qui s’affiche, sélectionnons « Manage Nuget Packages ».

La fenêtre de gestion des packages Nuget s’affiche. Nous devons rechercher le package jQuery.Mobile.MVC en tapant son nom dans la zone de recherche.

Nous allons ensuite cliquer sur Install pour que Nuget télécharger et installe automatiquement dans notre projet le package ainsi que toutes ses dépendances.

Nous allons nous rendre compte que plusieurs fichiers ont été ajoutés au projet, dont un nouveau fichier _Layout.Mobile.cshtml, _ViewSwitcher.cshtml ou encore ViewSwitcherController.cs.

Procédons maintenant à l’exécution de notre page pour voir ce qui sera affiché à l’écran en utilisant notre navigateur Firefox, et en définissant comme agent utilisateur iPhone (voir mon précédent billet de blog pour définir l’agent utilisateur sous Firefox).

View Switcher.

Revenons maintenant voir ce qui se trouve sous le capot.

Sur la page affichée dans notre navigateur, nous remarquons qu’une bande noire s’est ajoutée en début de celle-ci avec un lien permettant de basculer sur la vue desktop de la page.

D’où provient cette bande ?

Ouvrons avec notre éditeur la page affichée à l’écran (Index.cshtml).

@{
    ViewBag.Title = "Home Page";
}

<h2>@ViewBag.Message</h2>
<p>
    To learn more about ASP.NET MVC visit <a href="http://asp.net/mvc" title="ASP.NET MVC Website">http://asp.net/mvc</a>.
</p>

<ul data-role="listview" data-inset="true">
    <li data-role="list-divider">Navigation</li>
    <li>@Html.ActionLink("About", "About", "Home")</li>
    <li>@Html.ActionLink("Contact", "Contact", "Home")</li>
</ul>

À première vue, on se rend compte qu’aucune modification n’a été effectuée dans ce fichier.

Puisque ce fichier est intégré dans le Layout avant d’être affiché, jetons maintenant un coup d’œil sur notre fichier _Layout.Mobile.cshtml. Nous allons apercevoir la ligne de code suivante :

@Html.Partial("_ViewSwitcher")

Qui fait référence à la vue partielle _ViewSwitcher.cshtml. C’est cette vue qui ajoute un lien sur toutes les pages mobiles permettant de basculer du mode d’affichage mobile pour Desktop et vice-versa. Par défaut, elle n’est pas incluse dans les vues Desktop. Pour remédier à cela, vous pouvez juste copier @Html.Partial(« _ViewSwitcher ») dans le fichier _Layout.Mobile.cshtml et le coller dans le fichier _Layout.cshtml.

Dans le code de la vue partielle ViewSwitcher, la méthode GetOverriddenBrowser() est utilisée pour retourner un objet HttpBrowserCapabilitiesBase, qui va donner des informations sur les capacités du navigateur qui a fait la demande. La propriété IsMobileDevice retourne une valeur booléenne permettant de savoir si c’est un navigateur mobile qui effectue la demande.

@if (Request.Browser.IsMobileDevice && Request.HttpMethod == "GET")
{
    <div class="view-switcher ui-bar-a">
        @if (ViewContext.HttpContext.GetOverriddenBrowser().IsMobileDevice)
        {
            @: Displaying mobile view
            @Html.ActionLink("Desktop view", "SwitchView", "ViewSwitcher", new { mobile = false, returnUrl = Request.Url.PathAndQuery }, new { rel = "external" })
        } 
        else 
        {
            @: Displaying desktop view
            @Html.ActionLink("Mobile view", "SwitchView", "ViewSwitcher", new { mobile = true, returnUrl = Request.Url.PathAndQuery }, new { rel = "external" })
        }
    </div>
}

Browser Overriding

Penchons-nous maintenant sur le contrôleur qui est associé à cette vue.

using System.Web.Mvc;
using System.Web.WebPages;

namespace MvcApplication3.Controllers
{
    public class ViewSwitcherController : Controller
    {
        public RedirectResult SwitchView(bool mobile, string returnUrl) {
            if (Request.Browser.IsMobileDevice == mobile)
                HttpContext.ClearOverriddenBrowser();
            else
                HttpContext.SetOverriddenBrowser(mobile ? BrowserOverride.Mobile : BrowserOverride.Desktop);

            return Redirect(returnUrl);
        }
    }
}

Le View Switcher utilise une nouvelle fonctionnalité « Browser Overriding », permettant de traiter les demandes d’une application comme si elles provenaient d’un autre navigateur (Agent utilisateur).

Le Browser Overriding est une caractéristique de base d’ASP.NET MVC 4, et peut de ce fait être utilisé même si vous n’avez pas installé le package jQuery.Mobile.MVC. Avec cette fonctionnalité, en fonction du lien sur lequel l’utilisateur à cliquer (Desktop view ou Mobile view), le contrôleur de la vue Switcher va simuler un agent utilisateur (BrowserOverride.Mobile ou BrowserOverride.Desktop) qui sera utilisé pour charger les vues correspondantes au choix de l’utilisateur malgré que l’agent utilisateur transmit par son navigateur ne soit pas le même.

Le code ci-dessous va donc permettre de substituer l’agent utilisateur du navigateur. Par défaut, les données sur l’agent utilisateur simulé sont stockées en utilisant un cookie.

Conclusion

Nous venons d’apercevoir une fois de plus la puissance fonctionnelle d’ASP.NET MVC 4 pour le développement d’application mobile et Web. Dans le prochain billet de blog, notre attention sera portée sur le Template Web du Framework.