Avec Visual Studio 2010 (VS 2010), le développeur Windows et/ou .Net va s'ouvrir de nouveaux horizons, de nouveaux développements. Tout d'abord, c'est l'IDE idéal pour créer les meilleures applications pour Windows 7 !

VS 2010 permet de développer des applications natives (C++) Windows 7, ou en code managé (.Net) tout en tirant parti de toutes les nouveautés du système : multitouch, Direct Access, le nouveau SDK Windows, le ruban, etc. C'est aussi l'occasion de passer des applications WinForms aux applications WPF.

L'autre nouveauté est une intégration toujours plus fine entre Visual Studio et l'ensemble des logiciels Office 2010. Microsoft fournit un effort considérable pour simplifier le développement Sharepoint dans VS 2010. Ainsi, concevoir un projet Sharepoint n'est plus une corvée. Visual Studio dispose désormais des outils spécifiques Sharepoint, les templates projets, un explorateur serveur pour les sites et contenus Sharepoint, etc. Le développeur peut ainsi créer rapidement des applications Sharepoint, agréger des données métiers, intégrer des données de différentes sources (SQL Server, SAP, Siebel…). On peut aussi packager et déployer un projet Sharepoint 2010 depuis VS 2010.

Au-delà de Sharepoint 2010, VS 2010 continue à améliorer le développement des applications Office. Avec la prochaine sortie d'Office 2010, VS 2010 dispose d'une toute nouvelle version des outils Visual Studio Tools for Office. Il devient possible de développer en 32 et 64-bit, créer des packages de déploiement, bénéficier des nouvelles interfaces d'Office (ex. : Ruban, Linq).




Depuis plusieurs années, Microsoft, et l'ensemble de l'industrie informatique, sensibilise les développeurs aux développements multicore, à la programmation parallèle, permettant d'exploiter au mieux les processeurs à coeur multiples. Malheureusement, à peine 3 % du code produit est réellement parallélisé (chiffres Microsoft, 2008). Le défi est colossal. Car un logiciel non parallélisé ne tirera aucun avantage d'un processeur à 4 cœurs et l'utilisateur sera frustré de ne pas exploiter les performances de son ordinateur. Avec des logiciels toujours plus gros, puissants, la programmation parallèle devient un leitmotiv.

C'est pour cette raison que VS 2010 met en exergue le parallélisme aussi bien dans l'environnement que dans les librairies de développement. Tout est fait pour aider le développeur en limitant les modifications de code. Côté librairies, on dispose de PLinq, de Parallel Fx ou encore du Task Parallel Library. Mais pour exploiter au mieux la parallélisation, Microsoft a incorporé un tout nouveau runtime interne : le Concurrency Runtime qui doit gérer les tâches et les ressources. Au-delà de ces librairies et API, pour C++ et .Net, le développeur dispose aussi dans VS 2010 d'outils de débogage parallèle et d'analyse. Avec VS 2010, c'est le moment ou jamais de sérieusement se mettre à la programmation parallèle !




Cela fait presque 2 ans que l'on entend parler de services en ligne (Saas) ou encore de cloud computing. Microsoft propose sa propre vision du cloud avec Windows Azure. Et durant la conférence développeur (PDC) de novembre dernier, Microsoft a dévoilé la version finale de Windows Azure, des librairies, des outils. VS 2010 devient ainsi le centre de développement par excellence d'une application Azure.

On dispose de template Azure et des Windows Azure Tools for Visual Studio. Ils permettent de créer, déboguer et de déployer des services et applications cloud dans Azure. Là encore, tout est fait pour intégrer le cloud computing dans ses développements tout en facilitant la construction et le déploiement. Le développeur a accès à l'ensemble des services Azure : projet Dallas pour l'agrégation des données, SQL Azure (base de données dans le cloud), Azure Storage, .Net Services.

Et surtout, le développeur bénéficiera avec l'achat d'un VS 2010 de nombreuses heures d'utilisation Windows Azure. Idéal pour tester et comprendre le cloud computing !

Aujourd'hui, le développement ne se limite pas à l'intégration de nouvelles technologies. Il est important pour chaque développeur (et en particulier ceux qui sont en relation directe avec le client) d'avoir une vision de haut niveau de son projet, des relations avec ses clients, de l'avancement, de la qualité. C'est ce qu'on est en droit d'attendre d'un outil de développement moderne. Avec Visual Studio 2010, le référentiel commun à la gestion des bugs, des tests, des exigences et autres éléments de travail donne une transparence nouvelle aux projets de développement. Partager ce référentiel entre développeurs et testeurs garantit une meilleure collaboration entre les deux métiers. Cette collaboration est renforcée par des fiches de bugs, riches de contexte, permettant d'éviter de nombreux aller-retour entre la découverte d'un bug par le testeur et sa reproduction sur le poste du développeur.







Deux articles ne seront pas de trop pour vous présenter la gamme cliente puis la gamme serveur. Nous verrons au passage que Visual Studio est plus que jamais la marque de Microsoft pour les développeurs suite à la disparition du nom Team System. C'est parti pour ce tour d'horizon, attachez vos ceintures !



S'il ne fallait retenir qu'une nouveauté dans Visual Studio 2010 pour les développeurs, il s'agirait de l'IntelliTrace, précédemment connue sous le nom d'Historical Debugger. Cette fonctionnalité révolutionne la manière dont un développeur va pouvoir déboguer une application via :

- L'enregistrement des évènements d'une application.
- La journalisation automatique des appels de méthode (trace) et la navigation à postériori dans ces traces.

Dans les deux cas le mécanisme utilisé est l'injection de code IL à l'exécution. Ce procédé d'instrumentation peut dégrader les performances de l'application. Cependant, dans le cas où l'on cherche à analyser une application en profondeur, on ne sera pas vraiment regardant là-dessus à la vue de l'énorme gain de temps qu'il procure.

Traçage des évènements

L'enregistrement des évènements est l'option la moins intrusive et permet de suivre l'ensemble des évènements émis depuis le lancement d'une application jusqu'à ce qu'elle se termine (Fig. 1).

Voici quelques exemples des évènements disponibles :
- Action sur un contrôle graphique.
- Accès aux fichiers.
- Accès à la base de registre.
- Exceptions.
- ADO.Net

Si vous ne trouvez pas votre bonheur dans les évènements fournis par défaut ou si vous souhaitez enregistrer des appels à vos propres librairies, il est tout à fait possible d'en ajouter de nouveaux via l'édition du fichier " CollectionPlan.xml ". Comme on peut le voir sur la figure 1, Visual Studio affiche dans la trace :

- La catégorie (par exemple " File ").
- La description courte de l'évènement (" Access C:\test.txt ").
- Une description longue (" Initialized a FileStream to the path C:\test.txt ").
- Le thread courant (" Thead: Main Thread [2116] ").
- Des liens vers des différentes vues ("Locals, Call Stack ").

La trace peut également contenir la valeur de certaines variables (dans notre exemple le chemin du fichier). Il est en effet possible lors, de la déclaration d'un évènement, de spécifier un ensemble de variables à tracer lorsque cet évènement survient. La valeur de ces variables est alors disponible dans la vue " Locals ". En plus de ces informations, Visual Studio est capable de faire le lien entre un évènement et la ligne de code l'ayant généré : un double-clic sur l'entrée vous transporte à la ligne correspondante dans le code ! Toutes ces informations sont accessibles aussi bien pendant une session de débogage qu'a postériori. En effet, toutes les données sont stockées dans un fichier " .tdlog " dont l'emplacement est paramétrable dans les options de Visual Studio. Une simple ouverture de ce fichier avec Visual Studio permet de naviguer dans la trace. Plus besoin d'exécuter des dizaines de fois l'application en espérant retomber sur le bug, ayant mis des points d'arrêt au préalable pour connaître l'état de l'application avant le problème : l'application plante, on ouvre la trace et l'on voit l'ensemble des évènements qui ont eu lieu !

Traçage de tous les appels de méthode

Si cette liste d'évènements n'est pas suffisante, il est possible d'activer en plus la trace de l'ensemble des appels des méthodes avec la valeur de leurs paramètres. Cette trace est plus lourde mais va permettre de stocker un arbre exhaustif des appels comme on peut le voir sur la figure 2.

On retrouve donc tous les appels de méthode du projet ainsi que les appels au Framework .Net (en gris). Pour chaque entrée et sortie de méthode, on aura aussi accès aux valeurs des paramètres ainsi qu'à la valeur de retour de la fonction ! Pour parfaire le tout, il est possible de se déplacer librement dans l'arbre des appels et de remonter dans l'historique afin de suivre exactement le parcours qu'a effectué l'application. Ce voyage dans le temps se reflète dans la trace des évènements qui se restreint dynamiquement aux événements effectivement réalisés. Cette navigation peut se faire soit via les mêmes raccourcis clavier que ceux utilisés pendant le débogage, soit par un jeu de boutons contextuels affichés dans la marge du code (Fig. 3).

Une autre option très utile est la possibilité de se déplacer entre les différents appels d'une même méthode. En sélectionnant " Search For This Method In IntelliTrace " dans le menu contextuel, on peut alors visualiser les différents appels puis reprendre notre investigation en naviguant dans l'arbre des appels.

Exemple d'utilisation de l'IntelliTrace

Afin de montrer l'avantage de l'IntelliTrace, voici un petit exemple. Nous avons une classe Calc exposant quatre méthodes permettant d'ajouter, de supprimer, de diviser et de multiplier un opérande fourni en paramètres à la valeur stockée dans la propriété Resultat. La propriété Resultat est mise à jour avec le résultat de l'opération :



Nous allons maintenant appeler ces quatre opérations en parallèle afin de simuler une application multi-thread :



Comme on peut s'en douter, le résultat est aléatoire et va dépendre de l'ordre d'exécution des threads. Si vous exécutez ce code plusieurs fois, il peut arriver que vous ayez une exception de type DivideByZeroException. Sans IntelliTrace, il faudrait ajouter un mécanisme de journalisation afin de savoir l'ordre d'exécution des appels qui a généré cette erreur et il faudrait relancer l'application en espérant retomber sur le problème. Avec IntelliTrace, plus besoin de tout cela ! Afin de ne pas ajouter de code, nous avons modifié le fichier CollectionPlan.xml afin de définir des évènements sur les méthodes de la classe Calc. Lorsque l'erreur est arrivée, il a suffi de regarder la vue des évènements pour voir ce qui s'est passé depuis le lancement de l'application (Fig. 4) :



On s'aperçoit ainsi que si les opérations sont exécutées dans l'ordre suivant :
- Ajout : 2 + 0 = 2
- Multiplication : 2 * 2 = 4
- Soustraction : 4 - 4 = 0
- Division : 6 / 0 => erreur

Nous obtenons alors notre exception. Cet exemple est assez simple et certains d'entre vous auront vu les séquences qui ne fonctionnent pas juste en regardant le code mais dans un vrai programme multi-thread, cela peut faire gagner énormément de temps ! De plus, comme vous pouvez le voir sur l'image, lors de la déclaration des évènements personnalisés nous avons capturé la valeur du paramètre de la fonction et la valeur de la propriété Resultat afin d'enrichir la trace. Il est à noter que la capture de valeur ne peut se faire que sur des variables, d'où le fait que la classe Calc n'utilise pas de propriété automatique.



Penchons-nous maintenant sur une des fonctionnalités de base de la gestion de configuration : les branches. Celles de TFS et VS 2010 ont gagné en importance : elles sont devenues des composantes de premier ordre, nous allons donc passer en revue les dernières améliorations autour des branches et des ChangeSets. Premier point, les branches sont maintenant directement identifiables au niveau du contrôleur de source (Fig.5).

Attention, si vous migrez depuis TFS 2008 il faudra indiquer où sont les branches à l'aide de l'action " Convert to Branch " du menu contextuel.

Question ergonomie, certaines boîtes de dialogues sont devenues des fenêtres documents à part entière comme l'historique des ChangeSets. Ce dernier permet également d'afficher les labels (enfin !) (Fig. 6).



Lors de développements complexes, on a besoin d'avoir du recul vis-à-vis de la structure des branches en place, on veut pouvoir visualiser l'ensemble ou partie des branches de notre projet. C'est ce que propose la vue hiérarchique des branches, accessible depuis n'importe quelle branche dans son menu contextuel (Fig.7).



Depuis ce document, il est alors très facile de fusionner deux branches. En effet, un simple glisser-déposer d'une branche vers une autre suffit pour effectuer l'opération ! La résolution des conflits a également été sensiblement améliorée. Au lieu de devoir régler tous les conflits dans une fenêtre modale, les conflits sont affichés dans la fenêtre des changements en attente (Pending Changes), ce qui est finalement beaucoup plus naturel. On dispose de plus d'informations, comme les utilisateurs impliqués, ainsi que les liens ve rs les ChangeSets à l'origine du conflit (Fig.8).



Enfin, il est également possible de suivre l'évolution d'un ChangeSet au fil des branches. En effet, en tant que développeur, comment savoir si nos modifications on bien été répercutées dans la structure de branches existante et surtout de quelle manière ? La réponse est dans la fonction " Track Changeset " accessible directement depuis chaque ChangeSet. Cette dernière nous propose un affichage de type hiérarchique ou chronologique. Vous pouvez voir comment le correctif a été rétro-intégré dans la branche Main puis partiellement porté dans la branche WPF_Poc (les fusions partielles apparaissent en jaune) (Fig. 9).



Là encore, un simple glisser-déposer permettra d'opérer une fusion entre deux branches, cette fois-ci, seul le ChangeSet sera répercuté.




A partir de la version Premium, Visual Studio 2010 contient des fonctionnalités spécifiques pour le développement de bases de données dont on avait déjà eu un avant-goût avec la release out-of-band de GDR2 pour Visual Studio 2008. Ces outils sont malheureusement encore peu connus du fait de leurs sorties tardives, ce qui va sans doute changer avec la version 2010 qui les inclut nativement. On distingue les outils de comparaison et ceux dédiés au développement.

Les outils de comparaison

Les outils de comparaison marchent aussi bien sur les schémas que sur les données. La comparaison de schémas va, après avoir sélectionné les schémas source et cible ainsi que les objets à comparer, afficher leurs différences sous forme de liste (Fig. 10).


Il est facile de faire ressortir les similitudes ou de se concentrer uniquement sur les différences. Visual Studio permet alors de générer un script TSQL de mise à jour du schéma cible ou de le mettre directement à jour. Il est bien entendu possible de comparer un schéma existant à celui d'un projet de type base de données, les fonctionnalités proposées seront les mêmes. L'outil est particulièrement pratique pour repérer les différences entre les bases de différents environnements (développement et pré-production par exemple) et pour générer les scripts de mise à jour le cas échéant. Avec l'outil de comparaison de données, on va pouvoir sélectionner les tables dont on veut comparer les données depuis une base source et une base cible. La liste de résultats contiendra (Fig.11) :



- Les lignes différentes (même clé primaire mais données différentes).
- Les lignes uniquement présentes dans la table source.
- Les lignes uniquement présentes dans la table cible.
- Les lignes identiques.

Comme pour la comparaison de schémas, Visual Studio 2010 proposera de mettre à jour les tables cibles directement ou de générer un script de mise à jour contenant l'ensemble des requêtes SQL. Il est bien entendu possible de sélectionner les mises à jour que l'on veut effectuer.




Avec la vague 2010, une nouvelle SKU vient compléter Visual Studio, il s'agit de Microsoft Test & Lab Manager ou MTLM (pour éviter un claquage de la mâchoire). Le constat de Microsoft fut simple : le développement d'applications ne demandait principalement l'intervention, il y a vingt ou dix ans, que de développeurs.

Aujourd'hui d'autres rôles ont fait surface et dans un souci de productivité, il est important d'offrir un outil qui est adressé aux testeurs fonctionnels. En effet, l'intégration entre les deux mondes est essentielle si l'on veut pouvoir développer efficacement et sereinement son application. MTLM était donc destiné initialement aux testeurs mais il suscite néanmoins de l'intérêt chez les développeurs, d'où sa présence dans la version Ultimate de Visual Studio.

Nous ne pouvons malheureusement pas nous attarder sur l'ensemble des fonctionnalités que nous offre ce nouveau logiciel mais il est intéressant de parler de certains concepts et certaines fonctionnalités qui vont changer la vie d'une équipe de développement.




Vous avez la possibilité de déclarer des campagnes de test (Test Suite) qui vont enfin formaliser cette tâche dans le développement de votre logiciel. Ces campagnes sont composées d'une série de Test Case ou de Requirement à tester (Fig. 12).


Un Test Case est tout simplement un test manuel (idéal pour tester les IHM) tandis qu'un Requirement est la formalisation d'une exigence à remplir. L'intérêt du Requirement est qu'il peut se lier à n'importe quel type de Work Item qui va détailler son implémentation (typiquement les types Task ou Test Case). La gestion des Requirements et des campagnes de test permettent donc d'assurer la traçabilité complète entre une exigence et la validité de son implémentation !

Nous ne nous étendrons pas plus sur le sujet mais sachez que Microsoft a bien fait les choses, MTLM gère le déroulement d'une campagne, l'analyse des résultats d'une campagne (avec les statistiques de régression par rapport au déroulement précédent, etc.(Fig.13)).





Une campagne de tests va toujours s'inscrire dans un contexte d'exécution ou Test Plan. Celui-ci permet de définir sur quelles machines (Test Environment) la campagne va être exécutée pour les tests manuels et automatiques et en fonction de quels paramétrages spécifiques (Test Settings). La notion de Test Environment est très importante, nous aurons l'occasion de revenir dessus dans la prochaine partie avec Team Lab. Le Test Plan permettra en outre de maîtriser la campagne dans son exécution (date de début, date de fin, responsable, etc. (Fig. 14)).






Le rôle d'Architecte d'Entreprise a été traité avec peu de réussite dans les éditions précédentes de Team System. Ayant conscience de son échec, Microsoft a décidé de faire table rase et de repartir sur une nouvelle brique qui serait orientée cette fois-ci vers l'aspect Architecte Logiciel.

Virage à 180° particulièrement réussi! Si l'édition précédente n'avait quasiment aucun intérêt, Microsoft a su retenir toutes les critiques et s'orienter vers une nouvelle direction qui remplit une bonne partie du contrat : venir en aide, assister et fournir les briques de base pour les Architectes Logiciels.

Les différentes fonctionnalités sont réparties dans les éditions Premium et Ultimate de Visual Studio 2010.

Pour l'édition Premium, nous avons l'accès en lecture-seule des différents diagrammes (UML, Couche Logique, et DGML). L'édition Ultimate, quant à elle, offre la totalité des fonctionnalités à travers : la modélisation UML, les diagrammes de couche logique (avec validation de l'architecture applicative) et l'Architecture Explorer.




Une bonne surprise est le revirement de Microsoft concernant l'utilisation de l'UML. Dans le passé, l'éditeur de Redmond était parti dans la direction des DSL, prétextant une ouverture plus large par opposition à un standard clairement défini et délimité comme l'UML. Cependant, l'un n'empêche pas l'autre et Visual Studio 2010 le prouve par le biais des briques architectes et en délivrant l'excellent DSL Toolkit. L'UML est un standard adopté par beaucoup d'entreprises, l'avoir au sein de Visual Studio renforce la position de l'éditeur et conforte son ambition d'avoir un environnement avec le maximum de fonctionnalités clés intégrées.




Les fonctionnalités architecte s'articulent autour de deux concepts principaux : les diagrammes et l'Architecture Explorer.

Les différents types de diagrammes sont au nombre de sept, cinq pour l'UML (Class, Sequence, Use Case, Activity et Component), le diagramme de couche logique et enfin le diagramme générique DGML (pour Directed Graph Markup Language) : (Fig. 15).



Architecture Explorer est un concept assez nouveau, un peu déroutant au premier abord, mais qui deviendra vite indispensable lorsque l'on travaille sur des gros projets ou lorsque l'on reprend un projet existant. Celui-ci vous permet de parcourir un Project, une Solution ou des fichiers exécutables afin d'y découvrir les différents éléments tels que les espaces de noms, classes, méthodes, propriétés, etc. (Fig. 16).



Lorsque vous avez ciblé l'élément qui vous intéresse, vous avez la possibilité de générer un diagramme relationnel (Fig.17).



Vous avez aussi la possibilité de générer un diagramme relationnel à partir d'exécutables et en choisissant la granularité de restitution selon les types : assemblage, espace de nom, classe, méthodes et leurs expositions : public, internal, protected et private (Fig.18).






Microsoft prône souvent le pragmatisme lorsqu'il s'agit de sa suite de développement ALM, une fonctionnalité démontre particulièrement cet état d'esprit : la validation du diagramme de couche logique à travers la compilation.

Une des responsabilités majeures de l'architecte logiciel est de définir pour une application tout un ensemble de couches logiques représentant les différentes parties de celle-ci, puis de définir les interactions possibles entre elles et veiller à ce qu'elles soient respectées dans le code.

Visual Studio 2010 prend ce scénario en charge intégralement. La création d'un diagramme de couche logique nous permet de modéliser l'architecture logique (Fig.19)



Ensuite, nous pouvons attacher des éléments du projet (assemblage, espace de nom, classe, etc.) à des couches spécifiques. Et enfin, nous spécifierons pour chaque diagramme s'il valide ou non l'architecture, et la compilation du projet se chargera de vérifier l'intégrité de celui-ci. Lorsqu'un développeur utilise un objet sans que la liaison entre les couches soit modélisée, une erreur sera générée. De plus, il est possible d'automatiser cette vérification pour qu'elle génère une erreur pendant un Build !

• Loïc Baumann
  14 ans d'expérience dans le monde du développement logiciel. Il est actuellement Architecte Logiciel et expert en ALM chez Winwise ainsi que MVP Team System.
  http://loicbaumann.org
  
• Guillaume Rouchon
  8 ans d'expérience dans le monde du développement logiciel. Il est actuellement Consultant / Formateur .NET et expert ALM chez Winwise.
  http://blog.qetza.net
  
• Vincent Labatut
  10 ans d'expérience dans le monde du développement logiciel. Il est Consultant / Formateur .NET et expert ALM chez Winwise.
  http://blogs.codes-sources.com/vlabz