Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

OpenWebConfiguration lance une exception sur le mappage de “/” (Asp.net)

[new:11/10/2010]Pour les besoins d’un site devant tourner en mode mutualisé sans option Sql Server et dont le recyclage trop fréquent faisait perdre les authentifications j’ai du développer un provider de session fonctionnant sur une base Access. Tout allait bien jusqu’à ce que je tombe sur l’incompréhensible exception de WebConfigurationManager.OpenWebConfiguration n’arrivant pas à mapper le chemin “/monsite” pour lire le fichier Web.Config.Plus...

Caspol le casse-pieds, .Net Configuration manager absent : comment exécuter un code sur un partage réseau avec VS (site ASP.NET par exemple) ?

[new:12/10/2010]Exécuter et déboguer du code sur un réseau (un partage, un “share”) pose des tas de problèmes de sécurité. On peut bricoler les paramètres de Visual Studio mais pour un site Asp.net c’est le serveur de débogue lui-même qui ne veut pas fonctionner. Comment faire ?Plus...

IIS Express : le meilleur des deux mondes

[new:13/07/2010]IIS est un serveur complet et puissant, Visual Studio permet de travailler en debug avec un serveur de ce type au lieu d’utiliser le serveur de développement ASP.NET intégré. Mais l’une comme l’autre de ces solutions présentent des inconvénients. IIS Express va bientôt gommer ces derniers… Plus...

Article ! Le Binding Xaml, sa syntaxe, éviter ses pièges… (WPF/Silverlight)

imagePromis dans mon dernier billet, le voici enfin ! Ce nouvel article dédié au binding Xaml pèse 77 pages (le record était tenu jusqu’à lors par mon article M-V-VM avec Silverlight avec 70 pages) et se présente sous la forme d’un PDF et de 9 projets exemples.

Le binding cet inconnu … J’en parlais dans mon billet Le retour du spaghetti vengeur, le binding avec sa syntaxe pleine d’accolades et de chaînes de caractères non contrôlées à la compilation est un piège à bugs et la porte ouverte au code spaghetti.

Plutôt que de me lamenter et vous laisser vous embourber dans la sauce de ces spaghetti là, j’ai pris ma plume, et voici le résultat : 77 pages sur le binding Xaml, son fonctionnement, ses différentes syntaxes le tout illustré par des exemples clairs. L’article aborde aussi le débogue du binding assez délicat puisque Xaml échappe au débogueur de Visual Studio, et que le binding n’est que partiellement couvert par Intellisense.

Des conseils, du vécu, beaucoup d’exemples, voilà ce que vous trouverez dans cet article à télécharger en suivant le lien suivant :

Le Binding Xaml – Maîtriser sa syntaxe et éviter ses pièges (WPF/Silverlight)

(Attention, avant de cliquer sur le bouton “télécharger” attendez que la fiche détail de l’article soit bien affichée, sinon le site pensera que vous tentez un accès à une ressource non publique et vous demandera un login… Je reçois tous les jours des demandes d’ouverture de compte provenant de lecteurs trop impatients qui cliquent trop vite sur le bouton ! La prochaine version du site en Silverlight est en préparation et corrigera ce petit problème, mais d’ici là : slow down cowboy !).

Pour vous aider à vous faire une idée du contenu de l’article voici son sommaire :

Sommaire

  • Références    5
  • Code Source    6
  • Préambule    7
  • Le Binding Xaml : Ange ou Démon ?    7
    • Le Binding    8
    • Définition    8
    • Utilisations    9
    • Schéma du principe    9
    • Déclaration    10
      • Par code    10
      • En Xaml    11
  • Les modes de binding    13
    • Le mode OneTime    13
    • Le mode OneWay    13
    • Le mode TwoWay    14
      • Gestion du timing    14
    • Le mode Default    16
    • Le mode OneWayToSource    16
  • Hiérarchie de valeur    18
    • Règles de précédences    19
  • La notion de  DataContext    20
  • Les convertisseurs de valeur    21
    • Définition    21
    • Scénario    21
    • Implémentation    22
    • Utilisation    23
      • Instanciation    23
      • Invocation    23
      • Bonnes pratiques    24
      • Pour résumer    26
  • Les dangers du Binding    27
    • Des chaînes non contrôlées    27
    • Un langage dans le langage    28
  • On fait quoi ?    28
  • Déboguer le Binding    28
    • Vigilance    28
    • Une code Xaml court    29
    • Refactoring sous contrôle    29
    • Utiliser des outils intelligents    29
    • Utiliser Expression Blend    29
    • Vérifier les erreurs de binding dans la fenêtre de sortie    30
    • Créer un fichier des erreurs de Binding    30
    • La feinte du convertisseur inutile    32
    • Quelques outils supplémentaires    33
      • Spy++    33
      • ManagedSpy    33
      • Snoop    34
      • Mole    34
      • Reflector    34
      • Vos neurones    34
  • Les syntaxes du Binding    34
    • Le binding simple    34
      • Binding direct    35
      • Binding sur une propriété    35
      • Binding sur une sous-propriété du contexte    36
      • L’Element Binding    37
      • Convertisseurs de valeur    37
        • Paramètres de conversion    38
      • StringFormat    40
        • Injection de culture    41
        • Le ContentStringFormat    42
        • Gérer les nuls    43
    • Le Binding Multiple    44
      • La classe Personne    44
      • Le code du multi convertisseur    45
      • Le code Xaml    46
    • Le Binding XML    47
      • Binding sur une source Web    47
      • Binding sur une source XML en ressource    48
      • Binding sur une requête Linq To XML    49
    • Le Binding Relatif    52
      • Binding to Self    52
      • Le TemplatedParent Binding    53
      • Le Binding sur recherche d’ancêtre    54
      • Le Binding PreviousData    56
        • La source de données    58
        • La visibilité des flèches : la magie de PreviousData et du Binding Multiple    58
        • Le contenu des textes    61
      • Le Template binding    61
        • Utilité    61
      • Le Collection Binding    67
      • Le Priority Binding    69
  • Les propriétés de tous les bindings    74
  • Conclusion    76

Avril est froid et pluvieux mais les soirées rallongent, c’est le printemps même si cela n’y ressemble pas encore beaucoup, grâce à moi vous savez maintenant comment occuper vos soirées et vos weekend au lieu de faire l’idiot dans les embouteillages des vacances : Lisez cet article !

Et Stay Tuned !

VS2010 et .NET 4 RC en téléchargement public !

Bonne nouvelle, après avoir été réservée aux abonnés MSDN, la RC de VS2010 et du Framework .NET 4 viennent d’être rendues publiques !

A vos clavier, faites chauffer les disques durs et les machines virtuelles (toujours préférable pour une beta sans casser vos machines de production), c’est ici que ça ce passe :

http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx

Bonne découverte de cette mouture de VS encore plus incroyable que la précédente !

Et stay tuned !

NB: ATTENTION : La RC de VS2010 ne permet PAS le développement sous Silverlight 4 ! Si vous souhaitez continuer ce type de développement en attendant la version finale de VS 2010 vous devez conserver la version 2010 beta 2 !

Silverlight 4 : Do it yourself ! (adresses utiles)

Visiblement mon précédent billet annonçant Silverlight 4 et sa convergence avec WPF de plus en plus marquée a créé quelques remous chez certains lecteurs… Peut-être n’étaient-ils pas prêts à lire certaines évidences et vérités incontournables ? Peut-être ont-ils eu peur du changement qui s’opère sous leurs yeux mais qu’ils refusent de voir ? Peut-être ont-ils tout simplement mal compris mon billet ? Allez savoir !

En tout cas le meilleur moyen de se rendre compte de tout ça est de le vérifier par vous-mêmes !

Une citation

S’il n’en fallait qu’une ce serait celle-là…

Je ne suis pas le seul à penser ni à écrire que la convergence Silverlight / WPF va très certainement mener à la fusion totale des deux technos en une seule et que le nom qui restera sera Silverlight et non WPF. Une recherche sur Bing le montre assez vite notamment avec cette source que j’aurai pu citer directement si je l’avais connue avant d’écrire mon billet, une phrase à graver dans le marbre donc : “In the future, it is very likely that both Silverlight and WPF will be a single technology with a single codebase. After all, Silverlight was originally known as WPF/E (E as in Everywhere), and in an amazing 180 degree reversal of our usual approach, we took an ugly codename and created a great product name (Silverlight) from it.

Traduction : “À l'avenir, il est très probable que Silverlight et WPF deviennent une technologie unique avec une base de code unique. Après tout, Silverlight était initialement connu comme WPF/E (E comme dans Everywhere - Partout) et dans un incroyable renversement de 180 degrés de notre approche habituelle, nous avons pris un nom de code épouvantable et créé un nom pour un grand produit (Silverlight) à partir de celui-ci.

Extrait du billet “The Future of Client App Dev : WPF and Silverlight Convergence”.

Bon, après cette mise au point, passons à l’essentiel, à savoir comment jouer avec SL4 et vous rendre compte par vos propres moyens des avancées incroyables de cette nouvelle version :

Installer Silverlight 4

Un petit conseil personnel : Utiliser une machine virtuelle Virtual PC XP ou Vista (sous Windows 7 ça marche encore mieux). Tout ce qui est beta devrait toujours être installé sur des machines virtuelles pour ne pas polluer votre environnement de production. C’est en tout ce que je fais systématiquement. Pour SL4 j’ai une MV XP Pro avec 1 Go de Ram alloué et cela fonctionne parfaitement.

VS 2010

Tout d’abord il vous faut Visual Studio 2010 bêta 2 ou même Visual Web Developer Express 2010 beta 2. A noter que cette installation peut se faire sans aucun problème en parallèle de Visual Studio 2008 (il y a juste à faire attention si vous possédez déjà le SDK de Silverlight 3 sur votre machine).

Silverlight 4 beta Tools pour VS 2010

C’est le runtime de développement de Silverlight 4 avec support pour les projets SL4 sous VS2010 ainsi que le SDK SL4. Pour développer sous SL4 c’est le minimum vital.
Silverlight 4 Beta Tools for Visual Studio 2010

Les runtimes de test

Avec le téléchargement précédent vous n’avez besoin de rien de plus, mais si vous voulez installer le runtime Silverlight sur des machines de test non équipées de l’environnement de développement il faudra le télécharger, pour Windows ou pour Mac.
Windows Runtime ou Mac Runtime

Blend pour SL4

Même si VS2010 permet désormais de designer les applications Silverlight 4, Expression Blend reste (et restera) un outil incontournable (notamment pour les animations et le templating). Je vous conseille ainsi fortement de télécharger la version spéciale pour SL4.
Microsoft Expression Blend for .NET 4 Preview

Silverlight Toolkit

Lui aussi est devenu incontournable. Avec tous les contrôles supplémentaires qu’il offre ainsi que la gestion des thèmes visuels, il serait dommage de s’en passer.
Silverlight Toolkit

WCF RIA Services

La nature même de Silverlight oblige à travailler en n-tiers pour les données. Et plutôt que de tout faire à la main avec des services Web, autant utiliser les RIA Services (qui se fondent sur l’Entity Framework).
WCF RIA Services

La doc

Vous pouvez prendre connaissance de la doc en ligne de Silverlight 4 beta, toujours utile. Vous avez aussi la possibilité de télécharger le CHM en local : Offline CHM help Silverlight 4 Beta Documentation file download.

Apprendre, Comprendre et voir

Une fois tout le nécessaire installé vous trouverez certainement intéressant de faire un tour du côté des ressources suivantes qui vont aideront à faire le point sur les nouveautés de SL4.

Vidéos et exemples de code

Une série de vidéos couvrant les principales nouvelles features de SL4 (avec exemples en C# et en VB.NET).
Videos and Sample Code

Guides et labos

Pour explorer plus en profondeur, utilisez les Guides and labs.

Quoi de neuf ?

Un papier de John Papa : "What’s New" Whitepaper, et une video : "What's New in Silverlight 4 Beta" video

Les blogs

Les Silverlight Blogs sont une aide précieuse, n’hésitez pas à les visiter. Les blogs de certaines personne en particulier valent aussi le détour : Tim Heuer, Jesse Liberty, John Papa, Adam Kinney comptent parmi ceux qu’il ne faut pas louper en général.

Conclusion

A vous de jouer !

Convergence ou pas, Silverlight s’impose comme la technologie incontournable des prochaines années. Vous pouvez arrêter tout le reste. Si vous n’avez de temps que pour une techno, alors plongez vous dans Silverlight !

Silverlight 4 : Mamma mia !!!

La bêta de SL 4 arrive… Et les nouveautés sont encore une fois époustouflantes faisant de cette prochaine version une release majeure comme les 3 précédentes et non une simple mise à jour.

Certains seront déçus d’apprendre que la vraie 3D à la WPF ne semble pas encore intégrée (mais d’ici la finale peut-être ?), en revanche sur tous les autres points les améliorations sont extraordinaires et gomment, une fois encore et comme je le dis depuis longtemps, toutes les différences essentielles entre une application WPF de bureau et une application Silverlight Web.

Silverlight 4 c’est le petit poucet qui mange l’ogre, c’est le chaperon rouge qui se farcit un gigot de loup aux herbes. L’intérêt de WPF ne tient plus qu’à quelques fils que savamment et avec un doigté exceptionnel l’équipe de Silverlight coupe un à un …

Depuis un moment je vous dis mon sentiment que le futur de Xaml s’appelle Silverlight et chaque nouvelle release nous rapproche de cette fusion entre desktop et web, au point que, j’en suis convaincu, il arrivera un jour prochain où une seule technologie sera maintenue. Et elle ne s’appellera pas WPF, mais Silverlight. Donc, si vous ne vous y êtes pas encore mis, il est plus que largement le temps. Ceux qui ont suivi mon conseil en 2005 de virer de bord pour C# au lieu de Delphi ne l’ont pas regretté, même si beaucoup étaient très sceptiques à l’époque… Si je vous dis aujourd’hui faites du Silverlight, faites comme vous le sentez mais je me trompe que rarement sur ces choses là !

Les nouveautés orientées applications

  • Support d’impression permettant les hardcopies (copie d’écran) et la sortie de documents autant que la visualisation virtuelle des impressions (preview), indépendamment du contenu de l’écran.
  • Un nouvel ensemble de composants pour les fiches de saisie avec 60 contrôles personnalisables
    • dont des contrôles tels qu’un éditeur Rich Text avec support des hyperlinks, des images, des Textbox masqués pour les validations complexes…
    • DataGrid améliorée avec tri et resize des colonnes et le copy/paste des lignes
  • Intégration de WCF RIA pour créer des applications n-tiers avec support transactionnel, paging, etc.
  • Extension des possibilités de localisation avec support bi-directionnel et accès à 30 nouvelles langues comme l’hébreu, l’arabe, le thaï, etc.
  • Le CLR permet maintenant que le même code compilé puisse tourner aussi bien en mode Web qu’en mode Desktop !
  • Databinding amélioré avec grouping / editing et formatage de chaines à l’intérieur du binding
  • Support complet de M.E.F. pour créer des applications composites de grande taille (chargement dynamique, découverte automatique des plugins, etc).
  • Support complet de la surface de design dans Visual Studio 2010 et meilleure intégration avec Blend.

Les nouveautés orientées outils dans VS 2010

  • Surface de design totalement éditable
  • Une property grid riche avec de nouveaux éditeurs de valeurs
  • Drag’Drop support pour le Databinding, nouvelles fenêtres pour les datasources,…
  • Simplification des accès aux styles définis dans Blend
  • Intellisense pour Xaml, C# et VB

Les nouveautés améliorant l’UX

  • Support des Webcam et des micros pour le partage de vidéos et de l’audio par exemple pour créer des applications de type Chat ou Assistance client (ou bien d’autres choses !)
  • Enregistrement local de vidéos et de sons. Capture video Raw sans interaction avec un serveur (pour créer des applis de vidéos conférence par exemple).
  • Insérer des données externes avec Copy, Paste ou Drag’drop
  • Les listes gèrent la molette souris
  • Support des interactions conventionnelles du bureau avec par exemple les menus locaux par clic-droit
  • Support de Google Chrome
  • Optimisation des performances : les applications SL4 démarrent plus vite et s’exécutent 200% plus vite que leur équivalent SL3 !
  • Support du Multi-touch et des “gestures” (mouvements pré-établis ayant une signification dans le logiciel comme par exemple dessiner un rond sur l’écran avec le doigt pour déclencher un traitement)
  • Support du Multicast
  • Protection du contenu H.264 au travers des DRM Silverlight (utilisant PlayReady)
  • Protection des sorties pour l’audio et la video permettant au propriétaire du contenu ou au distributeur de s’assurer que les médias sont diffusés au travers d’une connexion vidéo sécurisée

Les nouveautés out-of-browser

Pour les applications dans la sandbox

  • Possibilité de placer du HTML dans les applications pour une plus grande intégration avec du contenu web comme les mails, l’aide, les états…
  • Support des notification “toast”, c’est à dire des fenêtres indiquant le statut de l’application même si l’utilisateur utilise une autre application
  • DRM offline
  • Contrôle de la position de la fenêtre, sa taille, son style

Pour les applications “trusted”

  • lecture / écriture depuis l’application SL des emplacements Mes Documents, Ma Musique, Mes Images, Mes Vidéos (ou leurs équivalents pour les machines non Windows). Permet le stockage et la lecture locale en dehors de l’Isolated Storage pour une meilleure intégration avec les données de l’utilisateur (production et stockage d’états par exemple)
  • Appel d’autres programmes Desktop comme Office par exemple. Il devient possible entre autre d’ouvrir Outlook pour envoyer un mail, de générer un état qui s’ouvre dans Word ou des tableaux de données qui s’affichent dans Excel, etc.
  • Automation COM autorisant l’accès aux périphériques et aux autres possibilités du système hôte. Par exemple : accès à un lecteur de carte d’accès ou de badges en USB.
  • Une nouvelle interface utilisateur pour les demandes de privilèges lorsque l’application fonctionne out-of-browser.
  • Objets de Group Policy permettant aux entreprise de fixer des droits globaux aux applications Silverlight tournant out-of-browser pour un déploiement simplifié et sécurisé.
  • Accès au clavier en mode FullScreen (plein écran)
  • Amélioration de l’accès à des données cross-domain sans avoir besoin de la présence d’un fichier de sécurité

Conclusion

Toutes ces nouveautés ouvrent des horizons radieux aux applications Silverlight et minimisent encore plus la distance entre applications de bureau et applications web.

On appréciera l’accès au clavier dans le mode plein écran qui permettra de faire des applis plus belles, plus immersives pour l’utilisateur. On notera avec intérêt l’accès au hardware ouvrant par exemple la possibilité pour les logiciels médicaux d’accéder à un lecteur de carte Vital tout en créant des applis Full Web (je sais que plusieurs de mes clients éditeurs seront vivement intéressés !). On piaffe d’impatience devant les nouvelles possibilités de preview et d’impression qui manquaient cruellement.

On appréciera bien entendu en même temps que les efforts “cosmétiques” tous les efforts techniques de cette version (MEF, RIA data services…) faisant de Silverlight un outil “pro” pour créer des applications “pros”. Microsoft a résolument décidé de laisser le côté amateur des outils permettant tout juste de créer des bandeaux de pub à la concurrence…

Bref, chaque nouvelles possibilités de Silverlight 4 créée un champ infini de nouvelles cibles potentielles : applications de gestion (facturation, suivi commercial), de support (Chat, Assistance technique), médical, multimédia (vidéos, sons)…

Nous assistons à chaque release de SL à la maturation d’une technologie majeure qui va s’imposer au fil du temps comme “la” technologie pour créer des applications riches, légères ou non, Web ou Desktop.

Quelle époque formidable ! :-)

Stay Tuned !

C# 4.0 : les nouveautés du langage

Visual Studio 2010 beta 2 est maintenant accessible au public et il devient donc possible de vous parler des nouveautés sans risque de violer le NDA qui courrait jusqu’à lors pour les MVP et autres early testers de ce produit.

Les évolutions du langage commencent à se tasser et la mouture 4.0 est assez loin des annonces fracassantes qu’on a pu connaître avec l’arrivée des génériques ou des classes statiques et autres nullables de C# 2.0, ni même avec LINQ ou les expressions Lambda de C# 3.0.

Pour la version 4 du langage on compte pour l’instant peu d’ajouts (le produit ne sortira qu’en 2010 et que d’autres features pourraient éventuellement apparaître). On peut regrouper les 3 principales nouveautés ainsi :

  • Les type dynamiques (dynamic lookup)
  • Les paramètres nommés et les paramètres optionnels
  • Covariance et contravariance

Paramètres optionnels

Il est en réalité bien étrange qu’il ait fallu attendre 4 versions majeures de C# pour voir cette syntaxe de Delphi refaire surface tellement son utilité est évidente.
De quoi s’agit-il ?  Vous avez tous écrits du code C# du genre :

   1:  MaMethode(typeA param1, typeB param2, typeC param3) …; 
   2:  MaMethode(typeA param1, typeB param2) { MaMethode(param1, param2, null) } 
   3:  MaMethode(typeA param1) { MaMethode(param1, null) } 
   4:  MaMethode() { MaMethode(null) }

Et encore cela n’est qu’un exemple bien court. Des librairies entières ont été écrites en C# sur ce modèle afin de permettre l’appel à une même méthode avec un nombre de paramètres variable. Le Framework lui-même est écrit comme cela.
Bien sûr il existe “params” qui autorise dans une certaine mesure une écriture plus concise, mais dans une certaine mesure seulement. Dans l’exemple ci-dessus le remplacement des valeurs manquantes par des nulls est une simplification. Dans la réalité les paramètres ne sont pas tous des objets ou des nullables. Dans ces cas là il faut spécifier des valeurs bien précises aux différents paramètres omis. Chaque valeur par défaut se nichant dans le corps de chacune des versions de la méthode, pour retrouver l’ensemble de ceux-ci il faut donc lire toutes les variantes et reconstituer de tête la liste. Pas très pratique.

Avec C# 4.0 cette pratique verbeuse et inefficace prend fin. Ouf !
Il est donc possible d’écrire une seule version de la méthode comme cela :

   1:  MaMethode(bool param1=false, int param2=25, MonEnum param3 = MonEnum.ValeurA)  …

Grâce à cette concision l’appel à “MaMethode(true)” sera équivalente à “MaMethode(true, 25, MonEnum.ValeurA)”. Le premier paramètre est fixé par l’appelant (c’est un exemple), mais les deux autres étant oubliés ils se voient attribuer automatiquement leur valeur par défaut.

Pas de surcharges inutiles de la méthode, toutes les valeurs par défaut sont accessibles dans une seule déclaration. Il reste encore quelques bonnes idées dans Delphi que Anders pourraient reprendre comme les indexeurs nommés ou les if sans nécessité de parenthèses systématiques. On a le droit de rêver :-)

Comme pour se faire pardonner d’avoir attendu 4 versions pour ressortir les paramètres par défaut de leur carton, C# 4.0 nous offre un petit supplément :

Les paramètres nommés

Les paramètres optionnels c’est sympa et pratique, mais il est vrai que même sous Delphi il restait impossible d’écrire du code tel quel “MaMethode(true,,MonEnum.ValeurA)”. En effet, tout paramètre doit recevoir une valeur et les paramètres “sautés” ne peuvent être remplacés par des virgules ce qui rendrait le code totalement illisible. C# 4.0 n’autorise pas plus ce genre de syntaxe, mais il offre la possibilité de ne préciser que quelques uns des paramètres optionnels en donnant leur nom.

La technique est proche de celle utilisée dans les initialiseurs de classe qui permettent d’appeler un constructeur éventuellement sans paramètre et d’initialiser certaines propriétés de l’instance en les nommant. Ici c’est entre les parenthèses de la méthode que cela se jouera. Pour suivre notre exemple précédent, si on veut ne fixer que la valeur de “param3” il suffit d’écrire :

   1:  MaMethode(param3 : MonEnum.ValeurZ); 

de même ces syntaxes seront aussi valides :

   1:  MaMethode(true,param3:MonEnum.ValeurX); 
   2:  MaMethode(param3:MonEnum.ValeurY,param1:false); 

En effet, l’ordre n’est plus figé puisque les noms lèvent toute ambigüité. Quant aux paramètres omis, ils seront remplacés par leur valeur par défaut.

Voici donc une amélioration syntaxique qui devrait simplifier beaucoup le code de nombreuses librairies, à commencer par le Framework lui-même !

Dynamique rime avec Polémique

Autre nouveauté de C# 4.0, les types dynamiques. Aie aie aie…

Dynamique. C’est un mot qui fait jeune, sautillant, léger. Hélas. Car cela ne laisse pas présager du danger que représente cette extension syntaxique ! La polémique commence ici et, vous l’aurez compris, je ne suis pas un fan de cette nouveauté :-)

Techniquement et en deux mots cela permet d’écrire “MaVariable.MethodeMachin()” sans être sûr que l’instance pointée par MaVariable supporte la méthode MethodeMachin(). Et ça passe la compilation sans broncher. Si çà pète à l’exécution, il ne faudra pas venir se plaindre. Le danger du nouveau type “dynamic” est bien là. Raison de mes réticences…

Si on essaye d’être plus positif il y a bien sûr des motivations réelles à l’implémentation des dynamiques. Par exemple le support par .NET des langages totalement dynamiques comme Python et Ruby (les dynamique de C# 4 s’appuient d’ailleurs sur le DLR), même si ces langages sont plus des gadgets amusants que l’avenir du développement (avis personnel). Les dynamiques simplifient aussi l’accès aux objets COM depuis IDispatch, mais COM n’est pas forcément non plus l’avenir de .NET (autre avis personnel).

Les deux autres emplois des dynamiques qui peuvent justifier leur existence sont l’accès simplifié à des types .NET au travers de la réflexion (pratique mais pas indispensable) ou bien des objets possédant une structure non figée comme les DOM HTML (pratique mais à la base de pas mal de code spaghetti).

Bref, les dynamiques ça peut être utile dans la pratique, mais ce n’est pas vraiment une nouvelle feature améliorant C# (comme les autres ajouts jusqu’à maintenant). Le danger de supporter un tel type est-il compensé par les quelques avantages qu’il procure ? C’est là que dynamique rime avec polémique !
Pour moi la réponse est non, mais je suis certain que ceux qui doivent jongler avec du COM ou des DOM Html penseront le contraire.

J’arrête de faire le grognon pour vous montrer un peu mieux la syntaxe. Car malgré tout le dynamisme n’est pas une invitation au chaos. Enfin si. Mais un chaos localisé. C’est à dire que l’appel à une méthode non existante reste impossible partout, sauf pour un objet déclaré avec le nouveau type “dynamic” :

   1:  dynamic x; 
   2:  x = Machin.ObtientObjetDynamique(); 
   3:  x.MethodeA(85); // compile dans tous les cas
   4:   
   5:  dynamic z = 6; // conversion implicite 
   6:  int i = z; // sorte de unboxing automatique
   7:   

Bien entendu le “dynamisme” est total : cela fonctionne sur les appels de méthodes autant que sur les propriétés, les délégués, les indexeurs, etc.

Le compilateur va avoir pour charge de collecter le maximum d’information sur l’objet dynamique utilisé (comment il est utilisé, ses méthodes appelées…), charge au runtime du Framework de faire le lien avec la classe de l’instance qui se présentera à l’exécution. C’est du late binding avec tout ce qui va avec notamment l’impossibilité de contrôler le code à la compilation.

A vous de voir, mais personnellement je déconseille fortement l’utilisation des dynamiques qui sont comme un gros interrupteur ajouté en façade de C# “Langage Fortement Typé On/Off”. Restez dans le mode “On” et ne passez jamais en mode “Off” !

Covariance et Contravariance ou le retour de l’Octothorpe

J’adore le jargon de notre métier. “Comment passer pour un hasbeen en deux secondes à la machine à café” est une mise en situation comique que j’utilise souvent, certainement influencé par mon passé dans différentes grosses SSII parisiennes et par la série Caméra Café de M6…
Ici vous aurez l’air stupide lorsque quelqu’un lancera “Alors t’en penses quoi de la contravariance de C#4.0 ?”… L’ingé le plus brillant qui n’a pas lu les blogs intéressants la veille sera dans l’obligation de plonger le nez dans son café et de battre en retraire piteusement, prétextant un truc urgent à finir…

Covariance et contravariance sont des termes académiques intimidants. Un peu comme si on appelait C# “C Octothorpe”. On aurait le droit. Octothorpe est l’un des noms du symbole #. Mais franchement cela serait moins sympathique que “do dièse” (C# est la notation de do dièse en américain, à condition de prononcer le # comme “sharp” et non “square” ou “octothorpe”).

Un support presque parfait sous C# 1 à 3

Un peu comme monsieur Jourdain faisait de la prose sans le savoir, la plupart d’entre nous a utilisé au moins la covariance en C# car il s’agit de quelque chose d’assez naturel en programmation objet et que C# le supporte pour la majorité des types. D’ailleurs la covariance existe depuis le Framework 2.0 mais pour certains cas (couverts par C# 4.0) il aurait fallu émettre directement du code IL pour s’en servir.

C# 4.0 n’ajoute donc aucune nouvelle fonctionnalité ou concept à ce niveau, en revanche il comble une lacune des versions 1 à 3 qui ne supportaient pas la covariance et la contravariance pour les délégués et les interfaces dans le cadre de leur utilisation avec les génériques. Un cas bien particulier mais devant lequel on finissait pas tomber à un moment ou un autre.

Un besoin simple

C# 4.0 nous assure simplement que les choses vont fonctionner comme on pourrait s’y attendre, ce qui n’était donc pas toujours le cas jusqu’à lors.

Les occasions sont rares où interfaces et délégués ne se comportent pas comme prévu sous C#, très rares. Mais cela peut arriver. Avec C# 4.0 ce sont ces situations rares qui sont supprimées. De fait on pourrait se dire qu’il n’y a rien à dire sur cette nouveauté de C# 4.0 puisqu’on utilisait la covariance et la contravariance sans s’en soucier et que la bonne nouvelle c’est qu’on va pouvoir continuer à faire la même chose !

Mais s’arrêter là dans les explications serait un peu frustrant.

Un exemple pour mieux comprendre

Supposons  les deux classes suivantes :

   1:  class Animal{ } 
   2:  class Chien: Animal{ } 

La seconde classe dérive de la première. Imaginons que nous écrivions maintenant un délégué définissant une méthode retournant une instance d’un type arbitraire :

   1:  delegate T MaFonction<T>();

Pour retourner une instance de la classe Chien nous pouvons écrire :

   1:  MaFonction<Chien> unChien = () => new Chien();

Vous noterez l’utilisation d’une expression Lambda pour définir le délégué. Il s’agit juste d’utiliser la syntaxe la plus concise. On pourrait tout aussi bien définir d’abord une fonction retournant un Chien, lui donner un nom, puis affecter ce dernier à la variable “unChien” comme dans le code ci-dessous :

   1:  public Chien GetChien()
   2:  {
   3:      return new Chien();
   4:  }
   5:   
   6:  MaFonction<Chien> unChien = GetChien; // sans les () bien sur !
   7:   

Partant de là, il est parfaitement naturel de se dire que le code suivant est valide :

   1:  MaFonction<Animal> animal = unChien;

En effet, la classe Chien dérivant de Animal, il semble légitime de vouloir utiliser le délégué de cette façon. Hélas, jusqu’à C# 3.0 le code ci-dessus ne compile pas.

La Covariance

La covariance n’est en fait que la possibilité de faire ce que montre le dernier exemple de code. C# 4.0 introduit les moyens d’y arriver en introduisant une nouvelle syntaxe. Cette dernière consiste tout simplement à utiliser le mot clé “out” dans la déclaration du délégué:

   1:  delegate T MaFonction<out T>();

Le mot clé “out” est déjà utilisé en C# pour marquer les paramètres de sortie dans les méthodes. Mais il s’agit bien ici d’une utilisation radicalement différente. Pourquoi “out” ? Pour marquer le fait que le paramètre sera utilisé en “sortie” de la méthode.

La covariance des délégués sous C# 4.0 permet ainsi de passer un sous-type du type attendu à tout délégué qui produit en sortie (out) le type en question.

Si vous pensez que tout cela est bien compliqué, alors attendez deux secondes que je vous parle de contravariance !

La Contravariance

Si la covariance concerne les délégués et les interfaces utilisés avec les types génériques dans le sens de la sortie (out), et s’il s’agit de pouvoir utiliser un sous-type du type déclaré, ce qui est très logique en POO, la contravariance règle un problème inverse : autoriser le passage d’un super-type non pas en sortie mais en entrée d’une méthode.

Un exemple de contravariance

Pas de panique ! un petit exemple va tenter de clarifier cette nuance :

   1:  delegate void Action1<in T>(T a);
   2:   
   3:  Action1<Animal> monAction = (animal) => { Console.WriteLine(animal); };
   4:  Action1<Chien> chien1 = monAction;

Bon, ok. Paniquez. !!!

Ici un délégué est défini comme une méthode ayant un paramètre de type arbitraire. Le mot clé “in” remplace “out” de la covariance car le paramètre concerné est fourni en entrée de la méthode (in).

La plupart des gens trouve que la contravariance est moins intuitive que la covariance, et une majorité de développeurs trouve tout cela bien complexe. Si c’est votre cas vous êtes juste dans la norme, donc pas de complexe :-)

La contravariance se définit avec le mot clé “in” simplement parce que le type concerné est utilisé comme paramètre d’entrée. Encore une fois cela n’a rien à voir avec le sens de “in” dans les paramètres d’entrée des méthodes. Tout comme “out” le mot clé “in” est utilisé ici dans un contexte particulier, au niveau de la déclaration d’un type générique dans un délégué.

Avec la contravariance il est donc possible de passer un super-type du type déclaré. Cela semble contraire aux habitudes de la POO (passer un sous-type d’un type attendu est naturel mais pas l’inverse). En réalité la contradiction n’est que superficielle. Dans le code ci-dessus on s’aperçoit qu’en réalité “monAction” fonctionne avec n’importe quelle instance de “Animal”, un Chien étant un Animal, l’assignation est parfaitement légitime !

M’sieur j’ai pas tout compris !

Tout cela n’est pas forcément limpide du premier coup, il faut l’avouer.

En réalité la nouvelle syntaxe a peu de chance de se retrouver dans du code “de tous les jours”. En revanche cela permet à C# de supporter des concepts de programmation fonctionnelle propres à F# qui, comme par hasard, est aussi fourni de base avec .NET 4.0 et Visual Studio 2010. Covariance et contravariance seront utilisées dans certaines librairies et certainement dans le Framework lui-même pour que, justement, les délégués et les interfaces ainsi définis puissent être utilisés comme on s’y attend. La plupart des développeurs ne s’en rendront donc jamais compte certainement… En revanche ceux qui doivent écrire des librairies réutilisables auront tout intérêt à coder en pensant à cette possibilité pour simplifier l’utilisation de leur code.

Et les interfaces ?

Le principe est le même. Et comme je le disais la plupart des utilisations se feront dans des librairies de code, comme le Framework l’est lui-même. Ainsi, le Framework 4.0 définit déjà de nombreuses interfaces supportant covariance et contravariance. IEnumerable<T> permet la covariance de T, IComparer<T> supporte la contravariance de T, etc. Dans la plupart des cas vous n’aurez donc pas à vous souciez de tout cela.

Lien

La documentation est pour l’instant assez peu fournie, et pour cause, tout cela est en bêta ne l’oublions pas. Toutefois la sortie de VS2010 et de .NET 4.0 est prévue pour Mars 2010 et le travail de documentation a déjà commencé sur MSDN. Vous pouvez ainsi vous référer à la série d’articles sur MSDN : Covariance and Contravariance.

Conclusion

Les nouveautés de C# 4.0, qui peuvent toujours changer dans l’absolu puisque le produit est encore en bêta, ne sont pas à proprement parler des évolutions fortes du langage. On voit bien que les 3 premières versions ont épuisé le stock de grandes nouveautés hyper sexy comme les génériques ou Linq qui ont modifié en profondeur le langage et décuplé ses possibilités.

C# 4.0 s’annonce comme une version mature et stable, un palier est atteint. les nouveautés apparaissent ainsi plus techniques, plus “internes” et concernent moins le développeur dans son travail quotidien.

Une certaine convergence avec F# et le DLR pousse le langage dans une direction qui ouvre la polémique. Je suis le premier a resté dubitatif sur l’utilité d’une telle évolution surtout que la sortie de F# accompagnera celle de C# 4.0 et que les passionnés qui veulent à tout prix coder dans ce style pourront le faire à l’aide d’un langage dédié. Mélanger les genre ne me semble pas un avantage pour C#.

C# est aujourd’hui mature et il est peut-être temps d’arrêter d’y toucher…
L’ensemble .NET est d’ailleurs lui-même arrivé à un état de complétude qu’aucun framework propriétaire et cohérent n’avait certainement jamais atteint.
.NET a tout remis à plat et à repousser les limites sur tous les fronts.

On peut presque affirmer que .NET est aujourd’hui “complet”. Même si la plateforme va encore évoluer dans l’avenir. Mais tous les grands blocs sont présent, des communications à la séparation code / IHM, des workflows aux interfaces graphiques et multitouch, de LINQ au Compact Framework.

Quand un système arrive à un haut niveau de stabilité, le prochain est déjà là, sous notre nez mais on le sait pas. Le palier atteint par .NET 4.0 marque une étape importante. Cet ensemble a coûté cher, très cher à développer. Il s’installe pour plusieurs années c’est une évidence (et une chance !). Mais on peut jouer aux devinettes : quelle sera la prochaine grande plateforme qui remplacera .NET, quel langage remplacera C# au firmament des langages stars pour les développeurs dans 10 ans ?

Bien malin celui qui le devinera, mais il est clair que tout palier de ce type marque le sommet d’une technologie. De quelle taille est le plateau à ce sommet ? Personne ne peut le prédire, mais avec assurance on peut affirmer qu’après avoir grimpé un sommet, il faut le redescendre. Quelle sera la prochaine montagne à conquérir ? Il y aura-t-il un jour un .NET 10 ou 22 ou bien quelque chose d’autre, de Microsoft ou d’un autre éditeur, l’aura-t-il supplanté ?

C’est en tout cas une réalité qui comme l’observation des espaces infinis qu’on devine dans les clichés de Hubble laisse songeur…

Rêver bien, mais surtout et pour les dix ans à venir : Stay Tuned !