C'est dans une ambiance absolument euphorique que Bill Gates a inauguré cette édition 2003 de la PDC. La salle pouvant accueillir plus de 8000 personnes a pris pendant 3 heures des allures de stade de foot où les exclamations des speakers se mêlaient aux tonnerres d'applaudissements. Aucune pause de prévue, nous n'avons pas décroché une seconde de la prestation des différents intervenants qui nous ont littéralement coupé le souffle ... Microsoft n'a jamais fait autant d'annonces sur de nouveaux produits et les 3 prochaines années s'annoncent palpitantes et pleines de surprises pour les amoureux de technologies que nous sommes. 

Voici maintenant un aperçu des différentes sessions que nous avons suivi.

Keynote du matin : Bill Gates 

Bill Gate, fidèle à ses habitudes est intervenu en tant que visionnaire des technologies futures. Je cite : "Les gens veulent utiliser des multiples services indépendamment de leur localisation", "aujourd'hui, nous avons tous des mails, des documents word ou excel, des base de données, et lorsqu'il s'agit de faire des recherches sur l'ensemble de ces documents, il nous faut utiliser de multiples moteurs de recherches non sémantique" "LongHorn à travers WinFS répondra à ces besoins"

Après cette brève présentation, les sujets les plus intéressants ont très vite été abordés. LongHorn sera la plus grande évolution de systèmes d'exploitation Microsoft après Windows 95, dixit Bill Gates. Doté d'une interface utilisateur à couper le souffle, cet OS du futur est basé sur un fenêtrage 3D constitué de multiples niveaux de transparence et associé à des effets d'ombres, d'overlay, etc.... L'interface utilisateur de LongHorn est Avalon, incontestablement la technologie phare de cette PDC. Présenté par Microsoft et Adobe (tiens tiens), Avalon a occupé une grande partie des débats. Nous reviendrons plus en détail sur cette API graphique Vectorielle qui n'a pas fini de faire couler beaucoup d'encres. 

WinFS fût la deuxième grande nouveauté de cette session. Pour ceux qui connaissent un peu RDF (Resource Description Framework), le principe est assez similaire. Le but consiste à étendre les méta-données d'une ressource ou d'un document pour l'indexer de manière sémantique. Vous cherchez tous les documents relatifs au projet "Audit Dupont" rédigés par l'auteur "Dubois", la requête WinFS vous renvoie un graphe en 3D vous permettant de naviguer dans les documents indépendamment de leur stockage physique (document attaché dans un mail, NTFS, office, base de données, etc..). La démo nous a totalement subjugué car, quoi qu'on en pense, WinFS répond à un réel besoin d'unification des données. En revanche, qui dit unification dit forcément intégration complète avec le système d'exploitation sous-jacent. Longhorn ne sera pas qu'un simple OS mais bel et bien un ensemble de Framework sur lesquels viendront se greffer les applications Windows de demain.  

Puis ce fût ensuite au tour de Don Box de nous présenter le second nouveau venu : Indigo. Indigo constitue le serveur d'application du futur pour Microsoft, il est destiné à héberger des WebServices à travers les standards WS-*. Son architecture est totalement extensible dans la mesure où l'utilisateur spécifie des ports, des channels, sur le principe de .NET Remoting.

Il est désormais possible de passer un contexte transactionnel et de sécurité entre composants serveur. Finalement le digne remplaçant de WSE avec en plus un socle d'exécution pour les composants d'entreprise. Qui a dit "concurrent des EJB ?" ;-).

La démonstration de Don Box sur le sujet a consisté à injecter un message XML dans un blog (en l'occurrence le sien). Rien de très original mais toujours efficace.

CLI200 - Avalon : Introducing the Next Generation of Windows Presentation.

Cette session fût la première présentation officielle d'Avalon. Ce Framework s'inscrit comme la fusion des applications modernes avec l'art graphique. Pour ceux qui connaissent le fonctionnement des ASP.NET, Avalon reprend bon nombre de ses idées. L'objectif d'Avalon consiste à modéliser une interface graphique client riche en XML, plus précisément en XAML (prononcer Xameul) associé à du code managé (C#, VB, J#) en code behind. A terme, l'idée consiste à séparer les rôles entre graphistes et développeurs afin de produire des interfaces graphiques plus sexy, un peu sur le modèle des applications Flash ou des jeux vidéos en 16M de couleurs. Il est très difficile de vous décrire l'ergonomie de telles applications, nous avons été littéralement bluffés par les capacités graphiques d'Avalon et nous ne pouvons que vous conseiller de télécharger l'outil pour vous faire une idée plus précise. D'un certain point de vue, Avalon se rapproche quelque peu de standards tels que SVG/RCC ou même d'outils Java tels que XUL. Le concept n'est bien entendu pas nouveau, mais Microsoft a décidé d'y mettre les moyens et le résultat est à la hauteur des espérances.

Pour information, voici un exemple de fichier XAML :

<?xml version="1.0" encoding="utf-8" ?>
<DockPanel xmlns="http://schemas.microsoft.com/2003/xaml">
<FlowPanel Width="50%" DockPanel.Dock="left">
    <FlowPanel.Resources>
    <Style>
    <Text Heght="36pt" FontSize="36pt">My Text XAML</Text>
    <Button ID="OKButton" Click="ButtonClick">OK</Button>
    <Button ID="CancelButton" Click="ButtonClick">Cancel</Button>
    </Style>
    </FlowPanel.Resources>
</FlowPanel>
<def:Code><![CDATA[
void ButtonClick(object el, ClickEventArgs args)
{
   MessageBox.Show("The button has been clicked !");
} ]]>
</def:Code>
</DockPanel>

Il est également possible de déplacer le code C# dans une zone externe au fichier XML. Et à terme, il est fort probable que ASP.NET et WinFx trouvent des points de raccordement pour former un socle commun d'interface graphique.

Pour résumer, Avalon un super DHTML pour clients riches ?

Auteur : SJ

WSV200 - ASP.NET : Overview of Whidbey

La présentation s'adressait aux développeurs ASP.NET pour les sensibiliser aux problématiques de sécurité relatives à la réalisation d'un site web.

Erik Olson a tout d'abord présenté l'importance du respect de quelques règles simples de sécurité pour ne pas être victime d'une des trois attaques classiques : le détournement du flot d'exécution, l'attaque de sites à partir d'un autre site et l'injection de code SQL.

Les règles proposées sont celles que l'on connaît déjà depuis longtemps :
- Validation par les contrôles de validation ASP.NET ou quand il n'y a pas d'interface utilisateur par des expressions régulières,
- Encodage des sorties grâce aux contrôles ASP.NET ou à Server.HTMLEncode et
- Utilisation systématique de paramètres dans l'appel de code SQL.

Ensuite, il a abordé quelques points comme :
- L'authentification - nous vous conseillons d'utiliser l'authentification Windows ou l'authentification par formulaire mais sur SSL et en stockant un hash du mot de passe ; Whidbey intègre entièrement le processus d'authentification par formulaire,
- Le stockage de données confidentielles - Utilisation de l'API DPAPI d'une manière générale ou pour le Web.config l'utilitaire aspnet_setreg ; Whidbey intègre l'encryptage des données XML.

Voilà donc une session utile qui rappelle les bons principes assez anciens mais importants aux yeux des développeurs Web. Les Slides et démos sont téléchargeables sur http://www.asp.net/whidbey. Un sujet peut-être moins sexy que WinFX, Yukon ou Whidbey mais tellement d'actualité...

(Auteur : Yann Faure - Regional Director - Bewise)

TLS347 - Introducing MSBuild, the universal Build Engine for Whidbey and LongHorn

Cette session était attendue pour plusieurs raisons. MsBuild arrive à point nommé pour la plupart des développeurs .NET qui ne disposent aujourd'hui d'aucun outil de construction digne de ce nom dans le monde Microsoft. De plus, la position de MsBuild par rapport à Nant suscite également de nombreuses interrogations. Pourquoi réinventer un outil ? Qu'est-ce que MsBuild fait de plus que son homologue Open Source ? Pourquoi ne pas simplement contribuer au projet initial pour l'étendre à .NET ? Bref, autant de questions auxquelles nous étions venu chercher des réponses.

Et bien pour tout vous avouer, nous avons eu droit pendant 1h15 à une magnifique présentation  de .... ant !. Cela peut paraître surprenant dit comme cela mais MsBuild est bel et bien une copie conforme de Ant ou plutôt de Nant. Si les deux speakers ont commencé leur session en affirmant qu'ils supportaient les efforts de la communauté Nant et qu'ils participaient au développement du Framework, ils ont également justifié leur décision de tout ré-écrire par plusieurs raisons que nous vous listons plus bas.

Concernant la partie technique, la notion de Target a été reprise à l'identique. Les Task font également partie intégrante du projet. Le plagiat (désolé du terme mais c'est bel et bien le cas) va jusqu'à reprendre l'API dans le nommage même des classes. L'interface des Custom Task s'appellent Task, la méthode à implémenter execute(...) et la manière d'utiliser les propriétés est absolument identique. Mais où sont les différences me direz-vous ? Et bien, les développeurs ont eu la bonne idée d'ajouter quelques fonctionnalités non existantes dans Ant aujourd'hui. Le tout est expliqué page 36 de l'ouvrage "Introducing Longhorn" distribué gratuitement aux participants pendant la conférence.

"On the surface, MsBuild and Ant seem similar. Both tools use XML as their project serialization format, and both use tasks as their atomic unit of build operation. However, a deeper look reveals differences in the two tools, some of which i describe here :

• Ant does not provide build-in target dependency analysis - a requirement for a scalable build system

• Ant does not have a clear concept of a project manifest - a necessity to develop additional tools to process the output of build system

• Ant does not have a normalized concept of task input and task output

• Unlike Ant, MSBuild is a secure build engine. MSBuild introduces concepts such as partially trusted builds, product level sandboxing and task level sandboxing

• MSBuild has a richer extensibility model that Ant

• Ant does not provide the ability to import (macro insert) parts of the project file. A necessity to factor the build system."
   

Nous vous laissons vous faire votre propre opinion sur le sujet. Le côté positif étant qu'un développeur Ant ne sera vraiment, mais alors vraiment pas perdu avec MsBuild.

Auteur : SJ

Session Indigo : Indigo signe la fin de .NET Remoting

Nous reviendrons plus longuement dans d'autres sessions sur Indigo mais l'information importante de la journée émane directement de Don Box. L'API .NET Remoting ne sera plus maintenu à l'avenir et restera en l'état. On peut là aussi se poser des questions sur la stratégie de l'éditeur qui a mis en avant un Framework qu'on savait d'ores et déjà condamné par la sortie d'un éventuel serveur d'application. Malgré tout, Microsoft continuera à supporter .NET Remoting dans les versions futures de ses produits.

Le cas Mono

Nous vous avons déjà relaté les évènements survenus avec la session de Miguel de Icaza que Microsoft n'a pas souhaité voir intervenir pendant la PDC. DNG l'a rencontré et nous avons pu échanger longuement avec lui. Son avis sur la question est assez tranché. Pour lui, le problème se situe à un niveau élevé de Microsoft Corp. Énormément de personnes chez l'éditeur souhaitent une tribune (même minime pour Mono) mais selon Miguel de nombreux cadres dirigeants voient en Mono un partenaire pour le moins gênant. Décidé à présenter la dernière version de Mono, Miguel de Icaza fera une présentation privée dans les couloirs de la PDC.

Le cas mono est très intéressant car il faut bien avouer que la tâche de Ximian sera des plus ardues. Avec la quantité de nouveautés et d'évolutions que nous avons pu découvrir pendant cette PDC, on voit mal comment Mono (aujourd'hui en version 0.26) pourra rivaliser demain avec Microsoft sur des sujets tels que Indigo, ASP.NET v2, Avalon, etc ...

Mono une cause perdue ? Nous poserons toutes ces questions à Miguel ce soir.

Using Data in your "Avalon" application - ARC340

Cette session a abordé la problématique de liaison des données dans les applications Avalon. Namita Gupta nous a présenté rigoureusement mais au pas de charge les techniques simples et efficaces pour lier les données dans ce type d'application.

La description de la liaison de données est dans le droit chemin de ce que nous connaissons sous les Windows Forms. En effet, la description de cette liaison se fait dans l'interface (donc avec Avalon ici dans le fichier XAML) ou par code : <TextBox Text="*Bind(Path=MaDonneeALier)"/>. Une fois cette liaison décrite, il suffit d'affecter le DataContext au contrôle ou au container.

Il est possible de rendre cette liaison :
- Bidirectionnelle (les données sont modifiables par l'interface),
- Dynamique (l'affichage se met à jour lorsque la donnée change) si la source implémente l'interface IPropertyChanged,
- Transformable (les données sont affichées d'une manière plus adaptée pour l'utilisateur) en créant un type qui implémente IDataTransform. Cette transformation peut alors être appliquée sur n'importe quelle liaison.

Si on va un peu plus loin, il est tout à fait possible de lier vos contrôles sur vos classes. Encore une fois par description XAML ou code :

<ListBox>
<MaClasse MaPropriete="MaValeur1"/>
<MaClasse MaPropriete="MaValeur2"/>
<MaClasse MaPropriete="MaValeur3"/>
</ListBox>

Le rendu s'effectue alors par un appel à ToString() à moins que vous ayez défini un style :

<Style def:Name="*typeof(MaClasse)">
<Style.VisualTree>
<DockPanel>
<Image Source="images/MonImage.png"/>
<Text Text="*Bind(Path=MaPropriété)"/>
</DockPanel>
</Style.VisualTree>
</Style>

Namita Gupta nous a alors présenté sous forme d'exemple la version Avalon de la grille Infragistics (les dirigeants étaient dans la salle).

Parmi les nouveautés intéressantes, il est possible, lors de liaisons avec un contenu multiple (ListBox par exemple), de modifier la liste des données sous-jacentes (ajout ou suppression) ainsi que de filtrer grâce à une CollectionView les données à afficher.

Nous voyons que l'on peut lier des données de toutes les manières imaginables mais quelles données ? Tout simplement tout ce que vous voulez. Le slogan de l'oratrice était : Your Data, Your Way. Nous pouvons lier notamment des sources de type DataSet, XML, Classes, contrôles Avalon, Indigo et WinFS. Elle a présenté une démo à couper le souffle où, par une simple liaison de données, les informations d'un certain type sont récupérées de manière asynchrone de WinFS :

<WinFSDataSource>
<WinFSDataSource.Query>
<Query TargetType="*typeof(MaClasse)" xmlns="winfs"/>
</WinFSDataSource.Query>
</WinFSDataSource>

Les mêmes possibilités sont offertes avec XmlDataSource et SqlDataSource.

Voilà une session qui assoit encore plus la technologie de la liaison de données qui avait été décriée il y a quelques années lors de ses débuts sous Visual Basic. C'est une bonne revanche !

Auteur : Yann Faure (Bewise)

TLS401 Visual C++ Whibey: Under the Covers Targeting the CLR

Si actuellement vous travaillez déjà en « Managed C++ » (MC++), vous avez sans doute remarqué quelques petits défauts, comme : - Un assemblage généré par VC++.NET est à la fois non vérifiable et non « safe » et donc le déploiement sur un lecteur réseau ou sur le Web n’est pas autorisé (CAS). - La clarté des métas donnés générés par un module MC++ est souvent discutable (ILDASM) - La syntaxe des extensions managed C++, est parfois ambiguë : o int* p ; // est ce un pointer GC ou du pointeur du Heap de la Runtime C. o L’ajout de __gc permet de soulever l’ambiguïté mais au prix d’une lisibilité dégradée) - Interopérabilité avec les autres langages .NET pose certaines contraintes (une fichier .OBJ contenant du code managed n’est pas consommable un autre langage .NET)

Dans son incarnation actuelle VC++.NET (2002-2003) est finalement un langage plus orienté sur la migration de code C/C++ vers le plateforme .NET que sur la création de nouvelles applications .NET. Il faut le reconnaître, les contraintes de déploiement et de sécurité font de VC++.NET 2002-2003 un mauvais candidat pour un nouveau développement .NET.

La prochaine version de Visual C++ .NET : nom de code Whidbey, arrive avec de nombreuses nouveautés. Cette session animée avec énergie et précision par Jeff Cox, m’a permis d’apprécier quelques éléments clefs de cette prochaine version :

Mixité des modules

Les nouveaux fichiers .OBJ générés par le compilateur deviennent compatibles avec les fichiers .NETMODULE. En conséquence ils sont exploitables par les autres langages .NET. Par exemple, si mon fichier C# « foo.cs » consomme des types logés dans le fichier « bar.obj » généré par le compilateur C++. Nous sommes donc autorisé à construire l’assemblage foo ainsi: csc /t :library foo.cs /addmodule :bar.obj

Assemblage multi modules sous Visual Studio .NET Whidbey

Une des contraintes de VS.NET actuellement est son incapacité de générer des assemblages multi modules. Dans la prochaine version Visual Studio .NET vous pourrez par exemple ventiler des sources écris en C#, en C++ et en VB.NET dans des dossiers (folders) au sein d’un même projet. Dans ce cas le compilateur adéquat sera invoqué au moment de la compilation du projet.

Amélioration syntaxique

Les extensions (attributs) apportées au compilateur pour supporter le managed C++ (__gc, __value, __box …) sont souvent déroutantes pour le néophyte (et même parfois pour le programmeur confirmé). Ainsi, la prochaine du compilateur à par exemple transformé le mot clef « __value » permettant de qualifié une classe ou une structure en un type Valeur au sens CLI, en un nouveau mot clef « Value » (remplace __value). Dans la même idée, un pointeur de type garbage collector (GC) pouvait s’exprimer en fonction du contexte avec l’opérateur « * » ou encore « __gc * ». Il devient « ^ » (rappel les pointeur du langage Pascal) offrant pour le lecteur du code source une syntaxe claire et sans équivoque. Enfin, notons qu’une nouvelle option (CLR :oldsyntaxe) du compilateur permet de compiler des fichiers managed C++ écris avec l’ancienne syntaxe (i.e. VS C++ 2002 & 2003).

Compatibilité CLI

La prochaine version, VC++ Whibey apporte aux programmeurs C++ une véritable opportunité de travailler sous la plateforme .NET (version 2.0) en respectant toutes les contraintes de compatibilités imposé par le CLI. Le programmeur accède à de nouveau commutateurs de compilation comme /CLR:pure (100% IL) et /CLR:safe (100% vérifiable) lui permettant de cibler le nature de son exécutable avec précision.

Performances interopérabilité à l’exécution

Dans la version actuelle de VC++.NET, traverser la frontière entre le monde virtuel de la CLR et le monde réel de l’OS, entraîne systématiquement de traverser un enchaînement des couches techniques par toujours justifiées. En effet dans le cas d’un appel d’un appel d’un fonction de la Runtime C (printf par exemple), pourquoi le compilateur actuelle ne choisit pas d’utiliser un appel directe et efficace via P/Invoke. La prochaine version de Visual C++.NET apporte cette amélioration offrant pour tous les consommateurs « Mangaged C++ » de la Runtime C un accès plus performant.

A travers cette session j’ai apprécié les efforts du Team VC++ pour apporter à ce langage tous les ingrédients qui feront de cette prochaine version, Visual C++ .NET Whidbey, un évènement majeur pour les programmeurs C++ travaillant sous la plateforme .NET. Notons enfin notons que les éléments décris relève d’une version bêta et que certains éléments peuvent naturellement évolués au moment de la sortie effective du produit.


Auteur : Bruno Boucard
 

N'hésitez pas à lire également le récit de Patrick Smacchia sur les sessions. La PDC continue et nous comptons assurer une couverture quasi temps réel alors restez-nous fidèle !

Merci aux différents chroniqueurs : Yann Faure (Regional Director - Bewise), Bruno Boucard (Architecte Indépendant - Société Générale), Pierre Couzy (WinWise)