PDC : ASP.Net Runtime Core et ASP.NET Futures

by Nicolas Calvi 18. novembre 2009 08:17

Deux sessions sur les nouveautés de ASP.NET 4.0

-          Peu de nouveauté sur l’ASP.Net 4.0 au niveau du core :

o   Quelques modifications sur les sessions : avec la possibilité de compresser la session, de les désactiver globalement dans le aspnet.config ou par code pour plus de précision et désactiver la fonctionnalité par page ou control.

o   Des modifications sur le cache pour pouvoir faire son custom provider de cache.

o   La nouveauté la plus intéressante est la fonctionnalité de warm up de IIS 7.5. Le principe est d’informer IIS de faire des appels à des URI au lancement des applications pool. La configuration peut être fait à la fois au niveau de IIS ou au niveau du web.config des applications.

L’effort à surtout été fourni sur l’optimisation des performances et l’ajout de quelques classes « Helper » comme le redimensionnement d’images ou l’ajout de la validation par mail dans le wizard de création de login.

Egalement présenté, la possibilité de regrouper plusieurs images au sein d’une seule et même image afin de réduire le nombre de requêtes.

En bref, pas de changement fondamentaux mais pas mal de petit plus pour nous simplifier la vie.

PDC : Dynamic Langages to Build Scriptable App

by Nicolas Calvi 18. novembre 2009 08:15

Cette session était très intéressante, elle montrait comment ajouter dans un programme .Net une fonction d’exécution de code dynamique comme JavaScript, Python ou encore Ruby. Le principe est simple, le speaker avait une application ou se trouvais un Canvas WPF. Dans celui-ci on pouvait y créer des cercles et des rectangles.

Dans cette même application, il y avait une TextBox pour pouvoir écrire du code dynamique et un bouton pour le l’exécuter à la volée. Dans son exemple, le speaker pouvait interagir en direct via le langage Ruby avec les cercles et rectangles de l’application. C’est réellement bluffant de voir que cette intégration se fait très facilement.

A la base on défini des Providers de langage dynamique appelé Runtime. Ensuite,  grâce à un système de scope, il est possible de définir les limites de l’interaction du langage dynamique avec son application, à savoir qu’elle objets et namespace sont accessibles dans l’exécution du langage dynamique. Ensuite il suffit d’injecter le code saisie dans le moteur dynamique et celui-ci est compilé et exécuté à la volé dans le scope.

Ce que l’on peut retenir de cette session :

·         Améliorer son application en un écosystème applicatif.

·         Les langages dynamiques peuvent se parler entre eux.

·         IronPython et IronRuby sont les langages dynamiques actuellement supportés.

·         Les nouvelles classes pour gérer l’exécution dynamique :

  •  
    • ScriptRuntime (Class)
      • ScriptScope (Class)
      • ScriptEngine (Class)
        • ScriptSource (Class)

·         Le but est d'enrichir les applications C# avec un langage dynamique qui peut interagir avec notre application dans un scope défini.

·         Permet un lien total entre son programme et le langage avec peu de code.

·         Le DynamicObject permet de pouvoir accéder aux propriétés d'un objet interne C# dans le moteur de script.

·         L'API Script est valable pour IronPython, IronRuby et autres DLR si le provider est là.

·         Lien : http://ironpython.codeplex.com/ 

 

Au final, si on couple cette technologie avec d’autres comme « M » ou « Quadran », il est possible de créer pour son application, un langage custom et permettre a ses utilisateurs de créer des petit programme comme les macros VBA, mais avec un contrôle total sur l’interaction du langage avec son domaine fonctionnel et applicatif.

PDC : Future directions for C# and Visual Basic

by Nicolas Calvi 18. novembre 2009 07:55

Pour ma part ma première session a été très intéressante, une présentation sur les concepts et directions que Microsoft va donner a ses langages phares que sont C# et Visual Basic. Outre le fait de montrer quelques évolutions syntaxique c’est surtout l’occasion pour le speaker de préciser qu’à l’avenir les langages seront plus tournés vers le déclaratif à l’instar de Linq que vers l’impératif (même si les deux seront toujours possible).

La première chose mise en avant est que les deux langages seront maintenant identique dans leurs possibilités, fini l’époque ou Visual Basic offrait telle fonctionnalité et C# une autre sans possibilité d’avoir les deux dans le même langage. Avec C# et  Visual Basic 4, ce que peut faire l’un, l’autre peut le faire aussi.

Dans les nouvelles fonctionnalités, une m’a particulièrement attiré, celle concernant le DynamicObject. Le concept est simple, pouvoir accéder a des accesseurs dynamique sur un objet, ce qui était avant impossible car ils étaient déterminés à la compilation. Si vous voulez voir a quoi sa ressemble coté code :  http://msdn.microsoft.com/en-us/library/system.dynamic.dynamicobject%28VS.100%29.aspx

Ce qu’il faut donc retenir de cette session :

·         Plus aucune différence de fonctionnalité.

·         La version déclarative d'un code est plus lisible de la version impérative.

·         L'idée est que le déclaratif est plus facile à mettre en place et plus facile à maintenir, et pose moins de problème de compréhension.

·         Possibilité de créer ses propres fonctions de refactoring de code dans Visual Studio 2010.

 

La session proposait comme exemple la création d’un parser de fichier CSV, en combinant les nouveaux concepts déclaratif de C# 4, on arrivait à un modèle pour le fichier était chargé dans un objet donc les accesseurs était dynamique, et donc que leurs nom changeaient en fonction du fichier CSV chargé.

TransactionScope et Entity Framework

by Nicolas Calvi 6. novembre 2009 16:43

J'ai récemment contribué à un projet qui met en place Entity Framework et je suis arrivé sur une problématique intéressante. En effet, dans un de mes traitements je dois insérer et modifier des données (appelons cette donnée D) en passant par Entity Framework. Le problème est qu'après chaque création d'une entité D dans le Context, un peu plus loin dans mon processus, je fais une requête Linq To Entity pour tester l'existance de cette donnée D dans la base donnée. Malheureusement, si la fonction Context.SaveChanges() n'a pas invoquée, la donnée n'est pas poussée en base et donc ne peut être ramenée dans ma sélection avec Linq To Entity.


Il existe une méthode pour requêter le Context et donc prendre en compte l'entité D nouvellement créée. Cependant, cela revient à faire deux requêtes, une dans le Context des objets non mis à jour et l'autre dans la base de données. Pour plusieurs raisons (factorisation du code notamment) cette solution n'était pas satisfaisante. Or je ne pouvais pas non plus invoquer la fonction Context.SaveChanges() car mon traitement est long et j'ai une exigence d'intégrité des données qui me force à faire un Rollback au moindre problème, or faire des Context.SaveChanges() répétés fait une mise à jour non réversible et donc incompatible avec mon exigeance.


J'ai donc décidé de tester de mettre mon traitement dans un TransactionScope pour voir si l'invocation de Context.SaveChanges() pouvais être transactionnel et la réponse est oui. En effet, cette technique me permet de valider mes entités D en base tout en ayant la possibilité de faire un Rollback. Le fait qu'Entity Framework offre cette possibilité permet une plus grande flexibilité dans son utilisation.

public void FonctionDeTest()
{
  MyEntities context = new MyEntities();

  using ( TransactionScope scope = new TransactionScope() )
  {
    // Faire un traitement avec EF
    context.SaveChanges();

    // Faire d'autres traitement avec EF
    context.SaveChanges();

    // Validation de la transaction
    scope.Complete();
  }

  context.Dispose();
}

Installer le SDK Surface sur Windows 7 - 64 bit

by Nicolas Calvi 29. septembre 2009 20:13

Même si ce que je vais écrire plus bas n'est pas supporté par Microsoft, certains qui comme moi, développent sur Surface et voudraient installer le SDK sur leur machine de salon qui est en 64 bit pourraient être intéressés par ce tutorial. Je vais donc reprendre l'excellent post de Brian Peek sur l'installation du SDK Surface sur une Windows 7 - 64 bit.

Le post de Brian est clair mais en voici une transposition en français et surtout avec quelques petits ajouts suite a ma propre expérience de l'installation. Avant de commencer, il faut savoir que Surface et tous ses assemblies doivent s'exécuter en 32 bit mais sont compilés sous l'instruction Any CPU. De ce fait, l'exécution du SDK Surface sur un système 64 bit ne pose aucun soucis d'autant plus qu'elle n'est pas contre indiqué par le CLR, il faut donc forcer les assemblies à utiliser le CLR en 32 bit

1. Pré requis :

Pour pouvoir utiliser le SDK il faut avoir préalablement installé XNA Game Studio 2.0 (le Runtime suffit) qui est nécessaire pour la suite des festivités. Bien sûr, on pourra par la suite utiliser les templates Surface sous Visual Studio 2008 avec XNA Game Studio 3.0 (que je vous conseil d'installer avant le SDK Surface), mais ceux ci ne sont pas des pré requis.

Ensuite il vous faudra vous procurer le programme ORCA qui permet la manipulation des MSI, si vous ne savez pas ou le trouver cliquez ici.

Dernière vérification, sous qu'elle forme se présente votre MSI du SDK Surface ? Si il correspond a la capture suivante passez à l'étape 2, sinon suivez les instructions en bas de la capture :

Si vous n'avez pas le SDK sous cette forme c'est que vous possédez seulement le fichier SurfaceSDKWE.msi. Pour arriver a l'image ci-dessus, exécutez ceci en ligne de commande (remplacez bien sûr les chemins par les vôtres et vérifiez que tous les répertoires existent déjà) : 

msiexec /a "C:\Surface\SurfaceSDKWE.msi" /qb TARGETDIR="C:\Surface\Extract"

Cela va extraire les fichiers du MSI afin de faire une manipulation à l'étape 2.

2. Modification du MSI d'installation :

Si vous tentez d'installer le MSI maintenant, vous aurez le message comme quoi votre système ne répond pas aux pré requis d'installation, cela est dû au fait que vous êtes en 64 bit. Pour pouvoir contourner ça nous allons utiliser ORCA, l'outil téléchargé plus haut. Il va nous permettre de retirer cette condition. Faite click droit sur le MSI et cliquez sur Edit with Orca.

Allez dans la section LaunchCondition, sélectionnez les deux conditions suivante :

  • Installed OR (VersionNT=600 AND ServicePackLevel>=1)
  • Installed OR NOT VersionNT64

Puis faite click droit Drop Row et pour finir faite File > Save. Maintenant le SDK Surface pourra se lancer sur votre machine 64 bit.

Il reste une dernière étape avant d'installer le SDK. En effet dans les répertoires d'installation du SDK Surface, il y a un exécutable nommé [répertoire d'extraction MSI]\Surface SDK 1.0 SP1\Microsoft Surface\v1.0\setupcustomaction.exe. Cet exécutable est lancé pendant l'installation du SDK et doit impérativement se lancer en 32 bit mais lui aussi est en Any CPU. Il va donc falloir redéfinir les flags de l'assembly, pour cela nous allons utiliser l'utilitaire corflags qui est fournis avec Visual Studio.

Lancez le Visual Studio 2008 Command Prompt. Allez dans le répertoire ou se trouve le setupcustomaction.exe puis lancer la ligne de commande suivante :

corflags setupcustomaction.exe /32bit+ /force

Attention, cette opération va retirer la signature (nom fort) de l'assembly (il en sera de même pour tous les corflags que l'on fera par la suite). Une fois cette opération terminée, vous pouvez enfin installer le SDK Surface sur votre ordinateur !

3. Modifier les Assemblies Surface :

Maintenant que le SDK est installé (pour tout ce qui va suivre je prendrais comme hypotèse que le SDK est installé à cet emplacement : C:\Program Files (x86)\Microsoft SDKs\Surface\v1.0\ et C:\Program Files (x86)\Microsoft Surface\v1.0\ ) il faut modifier les exécutables du SDK pour que le CLR les exécute en 32 bit. Cette opération sera la même que pour le setupcustomaction.exe a savoir l'utilisation de corflags.

Lancez le Visual Studio 2008 Command Prompt et allez dans le répertoire C:\Program Files (x86)\Microsoft SDKs\Surface\v1.0\Tools\Simulator\, depuis ce répertoire lancez la ligne de commande suivante : 

corflags SurfaceSimulator.exe /32bit+ /force

Cela va modifier le simulateur Surface afin qu'il fonctionne correctement (a savoir en 32 bit), mais il va falloir le faire avec tous les autres exécutables du SDK, pour cela j'ai fait un batch qui est téléchargeable ici, il va faire un corflags sur tous les exécutables du répertoire C:\Program Files (x86)\Microsoft Surface\v1.0\.

4. Modifier les Samples :

Si vous voulez utiliser les samples par défaut de la table Surface dans le simulateur, vous devez déjà extraire ceux-ci. Pour cela, allez dans le répertoire C:\Program Files (x86)\Microsoft SDKs\Surface\v1.0\Samples\ et décompressez le fichier Surface Code Samples.zip dans ce même répertoire (il va créer un répertoire SDKSamples). Une fois décompressé, allez SDKSamples et éditez le fichier InstallSamples.bat avec un éditeur texte. Dans ce fichier, remplacez tous les SOFTWARE\Microsoft par SOFTWARE\Wow6432Node\Microsoft, enregistrez et lancez le batch en question.

Par la suite il faudra aussi exécuter un corflags sur les exécutables générés pour les samples, pour cela Lancez le Visual Studio 2008 Command Prompt et exécutez les deux batchs que j'ai fait pour vous, qui sont téléchargeables ici pour le premier et là pour le second.

 

Voilà vous avez fini, vous pouvez maintenant profiter du SDK Surface sur votre machine avec Windows Seven 64 bit.