Par Bill Gates, Jim allchin, DonBox, Chris Andersen…

Cette session de trois heures fut l’occasion d’annoncer officiellement la sortie en 2006 du prochain OS Microsoft dénommé Longhorn. Le maître mot de cet OS est indéniablement la sécurité. Une grande partie des ressources développement sont consacrées à l’élaboration d’une technologie nommée NGSCB (Next Generation Secure COmputing Base) empêchant les applications d’interférer (un peu à la manière du bac à sable, mais à tous les niveaux, hardware, noyau et utilisateur). Un autre point fort exposé est une interface graphique nommée AVALON incroyablement ‘sexy’, reposant sur les possibilités du hardware 3D. Tous les éléments visuels sont maintenant vectoriels et un nouveau langage basé sur XML de description d’interface graphique est proposé par l’OS. Il a aussi été mis en avant une nouvelle gestion des données nommée WinFS (Windows Futur Storage). L’accent est mis sur la cohérence de l’accès aux données qui ne sont plus cantonnées dans des fichiers organisés dans une arborescence physique de répertoires. Les fichiers peuvent être instantanément réorganisés logiquement selon une multitude de critères sémantiques (le ou les auteurs du fichier, le ou les projets concernés par le fichier…) un peu à la manière des clauses WHERE d’une requête SQL. En fait la cohérence est à tous les niveaux. Par exemple une personne connue de l’OS peut être le destinataire d’un mail et l’auteur d’un document. L’ouverture au monde extérieur de l’OS est aussi révolutionnaire. Une démonstration époustouflante du chef technique d’amazon.com permet de se faire une idée de la convivialité des futurs sites web. L’idée est qu’un site web est une application Longhorn instantanément téléchargée à partir du site et communiquant avec ce dernier avec la technologie des services web. Cependant, les points concernant la compatibilité de ce modèle avec les autres OS et le devenir du HTML dans ce contexte ont été éludés. En résumé une session à l’américaine avec des intervenants charismatiques, très riche en termes idées.

Visual Studio Whidbey : New IDE Features for XML and Data Access
Par Paul Yuknewicz

Cette session avait pour but de montrer que la démarche RAD (Rapid Application Development) concernant la gestion des données d’une application développée avec Whidbey (le futur VS.NET) avait évolué dans le bon sens. Pari tenu, j’ai eu la surprise de constater que les ingénieurs de Redmond se sont attaqués à l’argument majeur à l’encontre de la démarche RAD à savoir: la difficulté de faire du RAD et du développement en couche. L’idée est simple: le code généré pour la couche d’accès aux données est séparé du code généré pour la couche présentation (Web form ou Win form). Les deux couches sont seulement liées à un ensemble de schémas XSD. Il devient alors possible d’intercaler une ou plusieurs couches propriétaires, développées dans des assemblages propriétaires, pour manipuler les données. Les autres temps forts de cette session concernaient la possibilité de déboguer du XSL, la possibilité de travailler avec des documents XML volumineux et la possibilité de personnaliser les différents membres d’un dataset typé. J’ai juste regretté que le débat dataset typé vs. object spaces n’a pas été traité pour des causes de timing.

Programming SQL Server Yukon using managed code ; Building stored procedures, functions and user-defined types
Par Pablo Castro; Jose Blakeley; Ramachandran Venkatesh

On a pu voir dans cette session comment créer et déboguer des classes et des procédures écrites en C# directement consommables à partir de requêtes T-SQL. Les exemples gravitaient autour d’une application réelle de gestion de données géographiques. Ainsi, plutôt que d’avoir dans une table un champ pour la latitude et un autre pour la longitude, on définit un seul champ d’un type une classe propriétaire de coordonnées géographiques. Plusieurs opérations sont ajoutées à cette classe, comme le calcul de la distance entre deux points du globe. Ces opérations peuvent alors être utilisées dans une requête T-SQL du genre : sélectionne les zones géographique qui contiennent un point du globe données. Il est dommage que cette session a seulement abordé les aspects techniques de Yukon, survolant les enjeux stratégiques et architecturaux de plus de logique métiers dans la base de données. En effet, les données ont en général plus de valeur que les applications qui les traitent. C’est pour cette raison que les bases de données relationnelles ont plus de part de marché que les bases de données objets qui sont forcément couplées avec les types de données d’une application. Cet argument va à l’encontre de la démarche Yukon et aurait mérité plus d’attention.

Indigo: Services and future of distributed application
Par Don Box

Cette session fut l’occasion pour le charismatique Don Box de démontrer pourquoi seule l’architecture orientée service (SOA) est envisageable pour faire communiquer les différents composants d’une application distribuées. Il y a beaucoup de débat autour de ce qu’est la notion même de SOA : il faut ici comprendre que l’on fait du SOA dés le moment où l’on communique avec des messages synchrones ou asynchrones, indépendamment de la technologies sous jacente utilisée (Web Service/ASMX, .NET Remoting, DCOM/COM+…). La réflexion part du constat que ce qui est valable pour la communication entre humains reste valable pour la communication entre programmes. Les points suivants sont soulignés : Les frontières entre entités doivent être clairement définies et immuables dans le temps, les entités doivent être autonomes et fiables (elles gèrent leur sécurité), les entités doivent partager le minimum (en fait seulement des schémas XSD) et chaque entité est identifiée grâce à un nom global stable dans le temps (une URI par exemple). On nous montre alors pourquoi l’idée même d’objets distribués est incompatible avec ces contraintes, et pourquoi seule une architecture par envoi de messages entre services est envisageable. Dans ce contexte, le terme INDIGO englobe toutes les technologies proposées par Microsoft allant dans le sens du SOA, que ce soit au niveau de .NET/WHidbey ou au niveau du futur OS Longhorn.

Journée de mardi

Whidbey Par Eric Rudder, Ari Bixton, Scott Guthrie, Ori Amiga, Rick LaPlante…

Cette session a été l’occasion d’aborder plus en détail les nouvelles fonctionnalités proposées par Whidbey pour améliorer la productivité des développeurs. La session était parsemée de plusieurs démos concernant le développement winform, ASP.NET, mobile device et WhiteHorse, un plugin whidbey permettant de faciliter le dialogue entre développeurs et architectes dans le développement d’une application SOA. Parmi les nouveautés dans la couche présentation on peut citer la snap line, une fonctionnalité permettant d’aligner horizontalement et verticalement les contrôles au design time, des nouveaux contrôles permettant d’imprimer ou d’afficher des médias comme des photos ou la technique de Master Page en ASP.NET permettant de réaliser de l’héritage visuel de page d’une manière très souple. Toujours en ASP.NET, il est maintenant aisé de permettre à l’utilisateur de personnaliser la présentation des données. Une démo particulièrement impressionnante a montré comment développer en moins de 10 minutes une application ciblant les device mobiles, avec de multiples fonctionnalités telles que la récupération de media, l’envoi de mail et l’accès à des web services.

Longhorn SDK Par Steven Goulet

On peut définir le longhorn SDK (nom de code Vegas) comme l’API de Longhorn, de la même manière que win32 est l’API des système Windows 32bits actuels. Longhorn SDK est l’unification de win32, conservé pour avoir une compatibilité ascendante, et de WinFX le modèle de programmation entièrement orienté objet de Longhorn englobant notamment le Framework .NET actuel. Longhorn SDK est très vite présenté par des chiffres : 13595 types (3,5 fois le nombre de type du framework .NET actuel), 50 millions de mots sur 200 000 pages de documentation (10 fois l’encyclopédie oxford). Un gros effort a été fait pour offrir des outils de recherche performants pour les développeurs. WinFX contient aussi de nombreux outils pour aider les développeurs et les administrateurs. Une démo nous a permis de voir comment facilement développer une application graphique en XAML l’exécuter directement, en faire un assemblage exécutable ou bien un fichier source C# avec l’outil xamlc. Cette démo a ainsi exposé l’intimité qui se crée entre l’IDE (Whidbey) et l’OS (Longhorn), notamment au niveau de la compilation.

Visual C# Whidbey : IDE enhancement for C# Par Scott Wiltamuth, Anson Horton John Stallo

Cette session a exposé une multitude de fonctionnalités ajoutées à Whidbey pour aider les développeurs C# dans les taches suivantes: écriture du code, réécriture du code (Refactoring), la navigation dans le code, le déboguage. La session a commencé avec une démo visant à démontrer que l’intellissense de Whidbey sait gérer les types génériques de C#2 (y compris au niveau de la généricité contrainte!). Dans cette démo, on voit apparaître l’espace de nom System.Collections.Generics et la classe générique Dictionary<K,V> (Key Value). Une autre démo montre la notion d’expansions. Une expansion permet d’effectuer une tache répétitive comme l’ajout d’une propriété à une classe. La vraie nouveauté est que vous pouvez créer vos propres expansions, car chaque expansion est décrite par un fichier écrit dans un langage xml. De nouveaux outils de navigation dans le code basés sur les métadonnées font leur apparition (par exemple la recherche de tous les endroits où une méthode est appelée, basée sur les métadonnées de la méthode et pas simplement sur son nom). Lorsque l’on écrit qu’une classe implémente une interface, on peut éventuellement demander à Whidbey de générer le squelette de l’interface dans la classe. Lorsque l’on renomme un type, Whidbey s’occupe de modifier tous les endroits du code où le type est utilisé. On peut sélectionner un bloc de code et demander à ce qu’il devienne une méthode à part entière. Whidbey est alors assez intelligent pour trouver les paramètres in et out ainsi que la visibilité et le type de méthode (partagée ou statique). Le débogage n’est pas en reste notamment au niveau de la visualisation de l’état des objets. Whidbey appelle automatiquement la méthode ToString() pour chaque objet visualisé dans le débogueur. Vous pouvez donc personnaliser cette visualisation. Mieux encore, durant le débogage Whidbey vous propose un mode user-friendly pour visualiser les données contenues dans un dataset. Il est à noter que le système de compilation est désolidarisé de whidbey et commence à s’intégrer à l’OS (intégration qui sera complète dans le futur longhorn). Vous pouvez personnaliser vos scripts de déploiement en leur permettant d’utiliser des classes propriétaires qui dérivent de la classe Task. Enfin, une dernière démo a montré que Whidbey permet de visualiser votre code C# sous la forme d’un diagramme de classes UML. Vous pouvez alors travailler sur ce diagramme. Les modifications sur cette vue sont intégrées dans le code en temps réel, et vice versa.

C# langage enhancements Par Anders Heljsberg

Cette session animée par le chef du projet C# en personne a fait la part belle aux quatre fonctionnalités apportées à C#2 qui sont : les génériques, les types partials, les itérateurs et les méthodes anonymes. Je ne reviens pas sur ces points car ils sont complètements couverts par ce document : http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/SpecificationVer2.doc

En revanche, voici quelques détails peu documentés concernant C#2. Vous pouvez déclarer qu’une classe est statique, c’est à dire qu’elle ne peut avoir que des membres statiques et qu’elle ne peut avoir d’instances. Vous pouvez faire en sorte que les niveaux d’accessibilités des deux accesseurs d’une propriété soient différents. Vous pouvez définir des alias sur les espaces de noms et les utiliser dans votre code avec l’opérateur ::. Vous pouvez définir un tableau de taille fixé ‘à la C’ : public fixed char szPath[256] ;. Vous pouvez ponctuellement désactiver la gestion des avertissements par le compilateur grâce à la directive #pragma warning.

Visual studio Whidbey : Deploying applications using click once
Par Sean Draine

Le mode de déploiement ‘click once’ est un nouveau mode de déploiement pour clients riches à mi chemin entre un déploiement traditionnel par fichiers MSI et un déploiement par téléchargement à partir d’Internet. Le terme ‘click once’ illustre la volonté de limiter la complexité de l’installation à un seul et unique click sur un lien hypertexte. Il n’y a plus besoin de passer par un assistant compliqué. Au niveau de Whidbey, il n’existe pas de projet de déploiement click once à proprement parler. Le développeur configure le déploiement click once pour chaque application, directement dans le projet concerné. Les paramètres de configuration concernent surtout la sécurité (les permissions requises pour un bon fonctionnement de l’application…) et la mise à jour automatique (vérifie toutes les ‘durées’ si une nouvelle version existe, en interrogeant une URL donnée) . Vous pouvez alors demander à Whidbey de déployer le projet, à partir d’un site web, d’un serveur FTP, de fichiers partagés ou en local. Dans le dernier cas, un fichier XML est généré (appelé manifest). Ce fichier doit être numériquement signé. Il contient les informations relatives au déploiement (sécurité, mise à jour, une valeur de hachage pour chaque fichier de l’application afin d’optimiser les futures mises à jour en ne téléchargeant pas les fichiers inchangés…). Au menu des détails intéressant, vous pouvez configurer les chargements de fichiers au fur et à mesure qu’ils sont consommés par l’application, vous pouvez protéger vos fichiers de clé publique/privé utilisés pour signer vos assemblages et le fichier manifeste XML par mot de passe, une API existe pour que l’application demande à l’utilisateur plus de permissions, il est assez aisé de faire du roll-back de version à partir de la fenêtre windows d’installation des applications et l’intellisense de whidbey tient compte de la configuration de sécurité (les permissions interdites sont grisées dans le menu intellisense).

Visual studio Whidbey : Building office solution with managed code
Par Reza Chitsaz

Voilà une session qui décrit un avantage conséquent de Whidbey : la possibilité de développer pour Office. Pour l’instant seul Word et Excel sont supportés. Le modèle de programmation est celui du Framework .NET, donc complètement différent de celui d’Office VBA. Cette session a commencé sur une démo exposant l’ajout de code managé dans un feuillet excel. Concrètement, l’assemblage contenant le code peut être dans le fichier Excel ou dans un assemblage séparé (un peu à la façon d’un fichier .xla). Un éditeur WYSIWYG de feuillet Excel fait son apparition au sein de Whidbey. L’éditeur est très similaire à celui des winforms, et d’ailleurs, tous contrôle géré (standard ou propriétaire) peut être ajouté directement à une page excel. La souplesse du Framework .NET permet de s’abonner à toute sorte d’évènements comme le changement d’une cellule, alors qu’en VBA nous n’étions limité qu’à un obscur sous-ensemble d’évènements. La notion de smart pane (un dialogue personnalisé pour faciliter l’édition des documents word ou excel, en tenant compte du contexte courant) devient très simple à programmer et à personnaliser. Enfin, les pages Excel peuvent être très facilement remplies par les données d’un dataset et plusieurs facilités permettent aux développeurs de ne plus se soucier de la disponibilité du client (on-line ou off-line).

.NET Framework : Exploring what’s new in the Base Class Library for Whidbey
Par Kit George

Cette session expose une multitude de détails ajoutés au Framework .NET. En voici quelques uns :

-La possibilité de personnaliser la visualisation du contenu d’une hashtable durant le débogage à l’aide d’une famille d’attribut (DebugDisplayAttribute…).

-La possibilité de générer un fichier de code source (C# ou VB.NET) avec l’outil resgen.exe. Ce fichier permet d’obtenir une propriété pour chaque label utilisé pour la localisation de l’application courante. Les avantages sont la détection par le compilateur d’une erreur et la possibilité d’utiliser l’intellisense.

-Quelques chose que j’avais à cœur depuis longtemps : la possibilité qu’un assemblage puisse permettre à certains assemblages d’accéder à ses types internes. Ceci est réaliser grâce à un attribut d’assemblage [assembly ::internalsVisibleTo(« AssemB »,PublicKeyToken= …)]. C’est un peu la même idée que la notion d’amitié du C++ appliquée au niveau des assemblages.

-L’utilisation de types génériques pour assigner une valeur nulle à des types valeurs: Nullable<int> intVal = Nullable<int>.default ; (très utile pour récupérer es valeurs d’une BD relationnelles).

-Les méthodes pour parser des chaînes de caractères lèvent une exception lorsque la chaîne de caractère n’est pas exploitable. Ceci est très coûteux, aussi chaque méthode Parse() à son équivalent bool TryParse(), beaucoup plus performant dans le cas de chaînes non exploitables.

-Une nouvelle possibilité de configuration du ramasse-miettes spécialement adapté lorsque de petits objets références des gros objets.

-Une classe Semaphore pour la synchronisation (c’est vrai qu’elle manquait).

-Une classe pour la manipulation de variables d’environnements.

-Une classe pour la lecture des données relatives aux volumes.

-Une facilité permettant de lire ou d’écrire une collection de chaînes de caractères dans un fichier en une seule ligne.

-Une classe spécialisée dans la lecture et l’écriture de données sur les ports séries.

-Une classe facilitant la manipulation des évènements de l’event log.

-La possibilité de mettre des couleurs lorsque l’on écrit sur la console (vive le progrés!).

 

Auteur : Patrick Smacchia