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

Dans ce article, nous avons créer une première API et consommer celle-ci dans une page Web en utilisant jQuery. Dans ce billet de blog, je vais vous montrer comment vous pouvez interagir avec votre API dans une application native en utilisant HttpClient.

Dans une application Web, vous pouvez simplement interagir avec une API Web coté client en appelant les requêtes HTTP Get, Put, Post et Delete dans un Script JavaScript ou en utilisant jQuery. Mais, si vous voulez accéder à votre API à partir d’une application Desktop par exemple, comment procéder ?

C’est à ce niveau qu’intervient HTTPClient. HTTPClient est un client moderne HTTP pour les applications .NET. Il peut être utilisé pour consommer avec souplesse et simplicité les fonctionnalités exposées via HTTP. Vous pouvez utiliser HTTPClient pour mettre en œuvre des interactions avec une API Web en envoyant et en recevant des réponses à partir des verbes standards Get, Put, Post et Delete de HTTP grâce aux méthodes GetAsync, PutAsync, PostAsync, DeleteAsync.

L’exemple ci-dessous illustre comment vous pouvez consommer les données au format XML d’une API Web en utilisant la méthode GetAsync.

HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/xml"));
var response = client.GetAsync("http://localhost:59130/api/Customer").Result;

Si vous souhaitez que les données soient retournées au format XML, vous pouvez procéder comme suit :

HttpClient client = new HttpClient();
client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
var response = client.GetAsync("http://localhost:59130/api/Customer").Result;

La procédure client.DefaultRequestHeaders.Accept.Add() permet de définir le format qui sera utilisé pour sérialiser les données.

La procédure asynchrone GetAsync() de la classe HttpClient() prend en paramètre une URI ou une chaine de caractères qui représente l’URL de l’API Web. GetAsync effectue une requête HTTP GET en utilisant l’URL passée en paramètre, puis retourne directement une tache dont la propriété Result (Task.Result) contient la réponse HTTP (HttpResponseMessage).

NB : Il est recommandé lors de l’utilisation d’une méthode asynchrone d’utiliser également le mot clé await pour éviter que l’application ne soit bloquée jusqu’à ce que l’opération soit complète. On peut s’en passer pour une application console, mais pour une solution Desktop, faudra penser à utiliser await pour éviter le blocage de l’interface utilisateur. Pour plus de détails sur async et await, je vous invite à lire cet excellent article sur le sujet : les nouveautés de C# 5.0.

A titre d’exemple, vous allez créer une application console qui consomme l’API que vous avez créée ci-dessus. Cliquez sur le menu « FICHIER », sélectionnez « Ajouter » puis « Nouveau projet ». Sélectionnez le projet « Application Console » et donnez-lui le nom « TestFirstWebAPI ».

Après création du projet, vous allez ajouter une référence à HTTPClient. HTTPClient n’étant pas disponible par défaut dans le Framework .NET ou avec ASP.NET MVC 4, vous devez passer par le gestionnaire de packages NuGet pour ajouter cette dépendance à votre application.

Faites un clic droit sur votre projet dans l’explorateur de solution et sélectionnez la commande « Gérer les packages NuGet… ». Lorsque l’interface de NuGet va s’afficher, recherchez le package HTTPClient.

L’installation du package va entrainer l’installation des dépendances System.Net.Http et System.Json que vous allez utiliser dans votre application.

Ajoutez une classe dans votre projet ayant la même définition que la classe Customer dans le projet ASP.NET MVC. Pour rappel, cette classe doit avoir la définition suivante :

public class Customer
    {
        public int Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string EMail { get; set; }
    }

Ajoutez par la suite une référence à System.Net.Http.Formatting et System.Net.Http.Headers.

using System.Net.Http.Formatting;
using System.Net.Http.Headers;

Vous allez maintenant ajouter les lignes de code suivantes à la fonction Main de votre application.

HttpClient client = new HttpClient();


client.DefaultRequestHeaders.Accept.Add(
     new MediaTypeWithQualityHeaderValue("application/json"));

 var response = client.GetAsync("http://localhost:59130/api/customer").Result;  

 if (response.IsSuccessStatusCode)
 {
     
     var Customers = response.Content.ReadAsAsync<IEnumerable<Customer>>().Result;
     foreach (var c in Customers)
     {
         Console.WriteLine("{0}\t{1}\t{2}", c.FirstName, c.LastName, c.EMail);
        
     }
 }
 else
 {
     Console.WriteLine("{0} ({1})", (int)response.StatusCode, response.ReasonPhrase);
 }
     Console.ReadLine();

La procédure ReadAsAsync() lit et déserialise automatiquement le corps de la réponse HTTP qui contient la liste des clients.

En appuyant sur F5 pour lancer le débogage de votre application, vous allez obtenir le résultat suivant :

Rassurez vous que vous utilisez un numéro de port spécifique pour votre application (59130 pour mon cas). Vous pouvez vérifier cela dans les propriétés du projet, onglet Web :

Vous avez le choix entre utiliser un numéro de port spécifique ou utiliser le serveur Web IIS local si vous en avez. Dans ces cas, le numéro de port ne varie que si vous décidez de le modifier.

Un petit message pour annoncer la publication de mon nouvel article sur le regroupement et la minification du JavaScript et CSS, des techniques d’optimisation qu’apporte ASP.NET MVC 4, pouvant grandement influencer le temps de chargement des pages Web.

Le temps de chargement d’une page est un facteur important dans l’évaluation des performances d’un site Web. Il a un impact non négligeable sur l’expérience utilisateur et même sur le référencement naturel. Plus les pages de votre site se chargent rapidement, plus l’expérience de navigation est fluide et plus les utilisateurs sont contents.

Dans nos applications, nous avons recours à plusieurs bibliothèques dont jQuery, knockout, etc. et des feuilles de styles qui ont des conséquences non négligeables sur le temps de chargement des pages.

Dans cet article, nous verrons comment améliorer les performances d’une application Web ASP.NET MVC en utilisant le regroupement et la minification à la volée du CSS et JavaScript.

L’article complet peut-être consulté sur cette page.

Pour les commentaires, ça se passe ici.

Télécharger le ZIP de l’article.

Télécharger l’article au format PDF.

Télécharger l’article au format eBooks.

Bonne lecture

Pour optimiser le temps le chargement d’une page, on peut avoir recours à plusieurs techniques côté client et côté serveur dont la mise en cache, l’utilisation d’un CDN ou encore la compression et la minification du CSS et JavaScript.

Dans ce billet de blog, je vais montrer comment vous pouvez grandement améliorer le temps de chargement des pages de votre site Web en minifiant et en regroupant vos fichiers JavaScript et CSS grâce à la bibliothèque ASP. NET Optimization – Bundling.

Le regroupement et la minification sont des procédés de réduction de la taille des fichiers en les combinant, et en supprimant les espaces et autres caractères inutiles. Ces méthodes permettent de rendre l’exécution d’une page Web plus rapide avec le moins de demandes de chargement des fichiers.

Pour commencer, vous allez créer une nouvelle application ASP.NET WebPages avec WebMatrix en utilisant le modèle de projet Starter Site.

Comme l’illustre l’image ci-dessous, vous constatez que votre application contient par défaut un nombre déjà assez important de fichiers JavaScript et CSS.

Si vous exécutez votre application et que vous analysez les performances de votre page d’index avec un outil comme Yslow, vous obtenez le résultat suivant :

Ajout de la bibliothèque ASP.NET Optimization – Bundling

WebMatrix 2 apporte comme nouveauté phare l’intégration du gestionnaire de packages open source .NET NuGet. Dans la boite à outil de l’EDI, une nouvelle icone NuGet est disponible, permettant d’accéder à l’interface des gestions des packages de votre application. Cliquez sur ce bouton.

L’interface de gestion des packages de NuGet s’affiche. Pour plus de détail sur son utilisation, lire mon article sur l’intégration du gestionnaire d’extensions et de NuGet dans WebMatrix 2.

Dans la zone de recherche, tapez le nom de la bibliothèque « Microsoft.Web.Optimization », sélectionnez le package ASP.NET Optimization – Bundling, et cliquez sur Installer.

La fenêtre contenant les termes de la licence va s’afficher. Cliquez sur j’accepte pour lancer l’installation du package dans votre application. A la fin de l’installation, si vous ouvrez le dossier Bin de votre application, vous verrez la présence d’un nouveau fichier Microsoft.Web.Optimization.dll.

Activation du Bundling

Grâce à NuGet, nous avons intégré sans difficulté la bibliothèque dont nous avons besoins dans notre application. Voyons maintenant comment nous pouvons activer le regroupement et la minification du CSS et JavaScript.

Pour cela, ouvrez le fichier _AppStart.cshtml et inserez la ligne de code suivant :

BundleTable.Bundles.EnableDefaultBundles();

N’oubliez pas d’ajouter une référence à Microsoft.Web.Optimization.

@using Microsoft.Web.Optimization

Tous les fichiers JavaScript contenus dans le répertoire Scripts (les sous dossiers ne sont pas pris en compte) de votre application seront regroupés, compressés et traités comme un seul fichier. Ces fichiers seront regroupés par défaut dans un dossier Scripts. Ils seront désormais référencés en utilisant la ligne de code suivante :

<script src="~/Scripts/js" type="text/javascript"></script>

De même, les fichiers CSS contenus dans le répertoire Content seront également compactés par défaut dans un dossier Content. Ils seront référencés en utilisant la ligne de code suivante :

<link href="/Content/css" rel="stylesheet" type="text/css" />

Après avoir appliqué ces modifications, exécutez à nouveau votre application. Vous allez obtenir le résultat suivant :

En comparant les deux images, vous vous rendez compte que le nombre de requêtes HTTP sur votre page est passé de 30 à 10. Les cinq fichiers JavaScript ont été regroupés en 1 fichier et les 16 feuilles de styles ont été combinés en 1 fichier.

De même, la taille des fichiers JavaScript est passée de 558,9 Ko à 375,1 Ko. C’est déjà pas mal. Mais, on aurait pu faire mieux, car plusieurs fichiers dans le dossier Scripts qui ont été regroupés n’ont pas été utilisés. C’est à ce niveau qu’intervient le Bundle personnalisé.

Bundle personnalisé

Avec cette option, vous avez la liberté dans le choix des fichiers qui seront dans un regroupement, ainsi que l’URL qu’aura le regroupement. À ce stade, le choix des dossiers de regroupement doit être fonction de la récurrence des fichiers JavaScript et CSS dans les pages de votre application.
Vous pouvez définir vos regroupements personnalisés en procédant comme suit dans le fichier_çAppStart.cshtml.

BundleTable.Bundles.EnableDefaultBundles();
 
    var jsBundle = new Bundle("~/Scripts", typeof(JsMinify));
    
    jsBundle.AddFile("~/Scripts/jquery-1.6.2.min.js");
    jsBundle.AddFile("~/Scripts/jquery-ui-1.8.11.js");
    jsBundle.AddFile("~/Scripts/modernizr-2.0.6-development-only.js");
   
 
    BundleTable.Bundles.Add(jsBundle);
 
    Bundle cssBundle = new Bundle("~/Styles", typeof(CssMinify));
    cssBundle.AddFile("~/content/site.css");
    cssBundle.AddFile("~/content/themes/base/jquery.ui.all.css");
 
    BundleTable.Bundles.Add(cssBundle); 

Vous allez désormais référencer ces regroupements dans votre page comme suit :

<link href="~/Styles" rel="stylesheet" type="text/css" />
<script src="~/Scripts" type="text/javascript"></script>  

En exécutant la page précédente de votre application, vous obtenez le résultat suivant :

Et voilà, la taille de vos fichiers JavaScript passe de 558,9K à 5,7K, soit un taux de compression de près de 98 %.
Vous pouvez également ajouter à votre regroupement tous les fichiers JavaScript d’un répertoire précis en procédant comme suit :

Et voilà, vous pouvez désormais améliorer assez simplement le temps de chargement des pages de votre application JavaScript grâce à la bibliothèque ASP. NET Optimization – Bundling.

Ce billet est le second d’une série sur les techniques d’optimisation du temps de chargement d’une application ASP.NET MVC. Le premier article sur la compression et la minification du CSS et JavaScript peut être consulté sur cette page.

Les requêtes des utilisateurs sur une page d’un site Web qu’il soit statistique ou dynamique engendre couramment le chargement de plusieurs éléments et de nombreuses opérations (chargement des images, CSS, JavaScript, données depuis une en base de données, etc.). Imaginez un intervalle de temps pendant lequel près de 100 requêtes sont effectuées sur votre site, et que durant cette période, le même contenu est retourné par votre application. Tout le long ce moment, votre application reprend 100 fois les mêmes opérations pour retourner un contenu identique.

La mis en cache est un procédé permettant d’améliorer considérablement le temps de chargement d’une page Web et économiser la bande passante, en évitant d’exécuter plusieurs fois certaines opérations (chargement des données, lecture d’une information dans la base de données, etc.) en stockant le contenu de cette page quelque part.

Activer la mise en cache

Le Framework ASP.NE MVC depuis la version 1 dispose d’un mécanisme pour la mise en a cache d’une application, qui repose essentiellement sur la même technique utilisée par ASP.NET. Il a été amélioré à partir de la version 3 pour coller avec les spécificités de la plateforme.

L’activation de la mise en cache se fait via l’attribut [OutputCache] qui peut être ajoutée soit individuellement à une action contrôleur, ou alors à une classe entière d’un contrôleur

Le code ci-dessous permet de mettre en cache pendant 30 secondes la sortie de l’action Index.

[OutputCache(Duration = 30)] //mise en cache pour 30 secondes
public ActionResult Index()
{
    ViewBag.Message = "Cette page a été mise e cache à " + DateTime.Now;

    return View();
}

Pour mettre en cache une classe entière d’un contrôleur, il suffit de décorer la classe avec l’attribut OutputCache comme l’illustre le code ci-dessous :

[OutputCache(Duration = 30)] //mise en cache pour 30 secondes
    public class HomeController : Controller
    {
       
        public ActionResult Index()
        {
            ViewBag.Message = "Cette page a été mise e cache à " + DateTime.Now;

            return View();
        }

        public ActionResult About()
        {
            ViewBag.Message = "Your app description page.";

            return View();
        }
}

Si vous exécutez ce code, vous vous rendrez compte que la date et l’heure affichées ne vont pas varier chaque fois que vous allez actualiser la page, jusqu’à ce que les 30 secondes soient écoulées.

NB: Il faut noter que le temps de sauvegarde des données de la page n’est pas garanti. En cas de manque de ressources mémoires, le cache va commencer à vider automatiquement son contenu.

Personnaliser la mise en cache

En dehors de la propriété Duration qui permet de définir le temps de mise en cache, d’autres propriétés dont il est important de connaitre sont disponibles pour vous permettre de personnaliser la mise en cache des données de votre page selon votre convenance et les spécificités de la page.

Location

La propriété location permet de définir l’emplacement pour enregistrer l’objet mis en cache. Il est possible d’enregistre l’objet mis en cache sur le serveur, le client, les deux ou toutes les autres options de l’enum OutputCacheLocation. Les différentes valeurs qu’elle peut prendre sont :

– Any
– Client
– Downstream
– Server
– None
– ServerAndClient

Par défaut, la valeur Any est utilisée lorsque cette propriété n’est pas spécifiée. L’orientation vers la mise en cache côté client, côté serveur ou les deux doit se faire suivant vos besoins. Si vous souhaitez afficher par exemple des informations personnalisées à l’utilisation comme son heure de connexion, son login, ses statistiques, etc. vous devez utiliser dans ce cas la mise en cache côté client.

Le code ci-dessous permet de mettre en cache la méthode d’action Index uniquement chez le client.

[OutputCache(Duration = 10, Location = OutputCacheLocation.Client)]
 public ActionResult Index()
 {
     ViewBag.Message = "Cette page a été mise en cache à " + DateTime.Now;

     return View();
 }

VaryByParam

Supposons un instant que vous voulez afficher les détails sur un produit à partir de son identifiant. Cela suppose qu’à chaque fois que l’identifiant du produit va changer, les détails affichés doivent également changer. Comment modifier la mise en cache pour que le contenu change automatiquement lorsque l’ID change. C’est à ce stade qu’intervient la propriété VaryByParam. Cette propriété permet de créer différentes versions d’un même contenu, dès que l’un des paramètres du formulaire ou de l’URL change.

Le code ci-dessous illustre comment vous pouvez l’utiliser.

[OutputCache(Duration = 3600, VaryByParam="id")]
        public ViewResult Details(short id)
        {
            Articles article = db.Articles.Find(id);
            return View(article);
        }

En procédant ainsi, plusieurs versions du contenu de la méthode d’action sont mises en cache jusqu’à expiration de la période de mise en cache.

Créer un profil de cache dans le Web.Config

Le fichier de configuration de votre application peut être utilisé pour créer un profil un cache. L’utilisation de cette technique présente plusieurs avantages :

– vous pouvez créer un profil de cache et appliquer celui-ci à plusieurs actions ou contrôleurs.

– vous pouvez modifier le comportement de votre profil de cache dans le Web.config sans avoir besoin de recompiler votre application.

Par exemple, la section de configuration Web « caching » définit un profil de cache nommé MyCacheProfil. Cette section « caching » doit apparaître dans la section « system.web » du fichier Web.Config.

<system.web>
    <caching>
      <outputCacheSettings>
        <outputCacheProfiles>
          <add name="MyCacheProfile"  duration="60" />
        </outputCacheProfiles>
      </outputCacheSettings>
    </caching>
  </system.web>

Le contrôleur suivant illustre comment appliquer le profil MyCacheProfile sur une action contrôleur à l’aide de l’attribut [OutputCache].

[OutputCache(CacheProfile="MyCacheProfile")]
        public ActionResult Index()
        {
            ViewBag.Message = "Cette page a été mise en cache à " + DateTime.Now;

            return View();
        }

Le cache de sortie fournir un moyen simple pour améliorer radicalement les performances de vos applications ASP.Net MVC. Au travers de cet article, vous avez découvert comment vous pouvez utiliser cette technique. Restez connecté à mon blog pour la suite des astuces sur l’optimisation du temps de chargement d’une page Web.

Comme il n’est pas exclu que je tombe encore sur le même type de problème à l’avenir, je vais partager sur mon blog – qui est avant tout mon rappel mémoire favori – les causes de cette erreur et comment contourner cela.

Ce que j’essayais de faire dans mon application.

Pour une facture, je voulais récupérer la liste des produits, et pour chaque produit, avoir la fiche produit correspondante, y effectuer des modifications, ensuite appliquer la mise à jour à la base de données.

Le code source de cette partie est le suivant :

var lp = from l in db.Liste_produit.Include(l => l.Article)
         where l.Id_facture == facture.Id_facture
         select l;
foreach(Liste_produit liste_produit in lp)
     {
       article = liste_produit.Article;
       //bla bla bla
       //bla bla bla
       db.Entry(article).State = EntityState.Modified;
       db.SaveChanges();
                        
     }

À l’exécution de ce code, au moment de l’enregistrement des modifications dans la base de données (db.SaveChanges()), l’exception ci-dessous est levée.

Les causes :

Après avoir observé le problème de près et effectué quelques recherches, je me suis rendu compte que le souci était au niveau du foreach.

Il semblerait que pour la lecture de chaque élément dans « lp », la bouche ait recours à une transaction pour le Context en cours. Hor, lorsque j’appelle la procédure SaveChanges(), une nouvelle transaction veut être créée pour le même Context. Ce qui n’est pas autorisé par Entity Famework.

Solutions

De prime abord, j’ai opté pour la sauvegarde de mes données dans une IList. Ainsi, lors de la lecture de celles-ci, je n’aurais plus besoin d’avoir recours à une transaction.
Le code que j’ai utilisé est le suivant :

var lp = from l in db.Liste_produit.Include(l => l.Article)
         where l.Id_facture == fa.Id_facture
         select l;
IList<Liste_produit> ListeP = lp.ToList();
foreach(Liste_produit liste_produit in ListeP)
   {
      article = liste_produit.Article;
      //bla bla bla
      //bla bla bla
      db.Entry(article).State = EntityState.Modified;
      db.SaveChanges();
                        
  }

Cette solution marche. Mais, côté performance, elle n’est pas du tout satisfaisante. Si la quantité de données est importante, imaginez un peu la consommation de la mémoire en chargeant toutes ces données dans une liste.

En tout cas, elle ne m’arrange pas. J’ai donc opté pour une solution beaucoup plus simple et performante. J’ai simplement appelé la procédure SaveChanges() en dehors de la boucle et le problème a été résolu avec de meilleures performances.

var lp = from l in db.Liste_produit.Include(l => l.Article)
         where l.Id_facture == facture.Id_facture
         select l;
foreach(Liste_produit liste_produit in lp)
   {
      article = liste_produit.Article;
      //bla bla bla
      //bla bla bla
      db.Entry(article).State = EntityState.Modified;
   }
db.SaveChanges();

En procédant ainsi, j’apporte des modifications à l’entité dans le foreach, et c’est à la suite de cette instruction (lorsque la transaction a été bouclée) que j’appelle la procédure SaveChanges().

Voila le problème est résolu, et la prochaine fois que je serais face à ce problème (ce qui est fort probable), et que je ne me souviendrais plus de comment j’avais procédé (ce qui est également fort probable), je saurais ou chercher e premier ;).

Pendant le développement ou le cycle de vie d’une application, le développeur est très souvent confronté à des situations pouvant entrainer des modifications de son modèle objet ainsi que de sa base de données. Avec Entity Framework, cette tâche peut s’avérer assez complexe, voire frustrante pour certains.

Si vous voulez par exemple apporter une modification (ajout d’une colonne) à une table de votre base de données, si vous vous limitez à définir uniquement la nouvelle colonne dans votre modèle, lors de l’exécution de l’application vous allez obtenir un message d’erreur puisque le modèle ne correspond plus aux objets de la BD.

Il était cependant possible d’ajouter quelques lignes de code dans le fichier Global.asax, permettant lors de la modification du modèle, de détruire et recréer automatiquement la base de données lors de la prochaine exécution de l’application, avec comme conséquence directe la perte des données. Ce qui est inacceptable pour une base de données déjà en production.

Heureusement, Entity Framework 4.3 élimine ces contraintes avec la nouvelle fonctionnalité Code First Migrations, qui permet d’appliquer avec souplesse les modifications du modèle sur la base de données, en réduisant les risques de pertes de données.

L’article complet est disponible ici.

Pour les commentaires, ça se passe ici

Bonne lecture

En dehors d’un foutu message “Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information”, rien ne permet d’identifier clairement la source de cette erreur.

Après plusieurs recherches, il semblerait que l’erreur soit générée par Entity Framework. En effet, lorsque vous utilisez Entity Framework, celui-ci est configuré par défaut pour charger tous les types des assemblys référencées, afin d’identifier les différents types des entités pour votre modèle objet. Si l’un des types ne peut être chargé, alors Entity Framework va générer cette erreur.

Il existe plusieurs solutions pour fixer ce problème :

– vous pouvez marquer la copie locale de toutes les assemblys référencées dans votre application à True ;

– dans une autre mesure, il suffit de supprimer toutes les DLL dans le dossier bin et procéder à une nouvelle génération de votre application.

– il est également possible que les bibliothèques System.Data.Entity et System.Web.Entity soient corrompues. Pour mon cas par exemple, lors du déploiement de mon application, après investigation, je me suis rendu compte que les fichiers System.Data.Entity.dll et System.Web.Entity.dll avaient respectivement pour tailles 1640 Ko et 63 ko, pourtant dans le framework .NET, ces fichiers avaient pour tailles 4360 Ko et 135 Ko. En les remplaçant simplement avant le déploiement de l’application, cela a résolu ce bug.

Mais, le véritable problème ici, c’est d’identifier réellement l’assemblys qui pose problème. Pour cela, vous pouvez simplement utiliser le code suivant :

try
{
    //Le code qui pose problème.
}
catch (ReflectionTypeLoadException ex)
{
    StringBuilder sb = new StringBuilder();
    foreach (Exception exSub in ex.LoaderExceptions)
    {
        sb.AppendLine(exSub.Message);
        if (exSub is FileNotFoundException)
        {
            FileNotFoundException exFileNotFound = exSub as FileNotFoundException;
            if(!string.IsNullOrEmpty(exFileNotFound.FusionLog))
            {
                sb.AppendLine("Fusion Log:");
                sb.AppendLine(exFileNotFound.FusionLog);
            }
        }
        sb.AppendLine();
    }
    string errorMessage = sb.ToString();
   }

N’oubliez pas d’ajouter une référence à System.IO et System.Reflection;

Et voilà. Dorénavant, lorsque vous allez exécuter votre application et qu’il y’aura un problème avec le chargement d’un composant, vous aurez un message clair et les détails sur l’assembly qui pose problème.

À noter que ce bug n’existe plus lorsque l’on utilise Entity Framework avec le framework .NET 4.5, il ne scanne plus toutes les assemblys de l’application lors de son exécution.

Pour rappel, WebMatrix est un environnement de développement Web léger « tout-en-un », robuste et surtout gratuit, développé par Microsoft.

Cette mouture qui marque une étape importante dans le cycle de développement de l’EDI s’aligne avec la vision de Microsoft : fédérer l’ensemble de la pile Web et des outils dont les développeurs ont besoin pour créer des applications Web au sein d’un outil.

WebMatrix 2 RC s’arrime au développement mobile en proposant des outils permettant de mettre sur pied facilement des applications Web Mobiles. Les modèles pour ASP.NET, Node.js et PHP ont été mis à jour pour être plus mieux adaptés pour un affichage sur les terminaux mobiles. Le rendu des vus spécifiques en fonction des dispositifs (Tablette, iPhone, Windows Phone, etc..) est désormais possible.

L’EDI dispose par défaut des émulateurs allégés pour Windows Phone, iPad et iPhone, permettant d’avoir un aperçu rapide du fonctionnement de son site Web sur ces dispositifs. Des travaux sont en cours pour intégrer encore plus d’émulateurs.

Le support de JQuery Mobile est également au rendez-vous (auto-complexion, etc.). Plusieurs modèles de projets mobiles reposent sur la bibliothèque JavaScript.

La complexion de code pour HTML5, CSS3, JQuery est au menu. L’EDI repose sur la version 2 de WebPages qui dispose d’un nombre assez intéressant d’améliorations par rapport à la version 1. Le support de Node.js est également au centre de la RC de WebMatrix 2, qui propose de nouveaux modèles de projets, l’IntelliSense pour Node.js et la coloration de code pour Jade/EJS.

WebMatrix 2 RC offre un support encore plus étroit de Windows Azure, la plateforme Cloud de Microsoft.

WebMatrix 2 RC dispose d’un nombre assez impressionnant de nouvelles fonctionnalités par rapport à la bêta. Je viens à peine de commencer à jouer avec ces nouveautés, et je peux dire que je suis déjà assez impressionné et captivé par cet EDI que j’ai adopté depuis la sortie de la première version.
Je reviendrais sur certains de mes billets de blog sur les nouveautés qui auront le plus attiré mon attention au fur et à mesure que je découvrir cette RC de WebMatrix 2.

– Télécharger WebMatrix 2 RC