Jean-Marc

Le progamme VSIP ... plus intéressant que ce que je ne pensais avant d'être chez MS

2008-06-03T21:50:00Z

Avant d’être chez Microsoft, je pensais que le programme VSIP (Visual Studio Industry Partner), c’était plutôt pour l’aspect marketing, et pour des d’entreprises qui voulaient vendre leur produit avec Visual Studio, et profiter d’une synergie de vente avec Microsoft. Cet aspect existe.

Mais il existe également un volet technique à ce programme, qui pourrait bien vous intéresser si vous vous lancez sérieusement dans l’extensibilité Visual Studio.

Si on voulait faire l’historique du programme VSIP, il faudrait dire qu’au début, pour télécharger le VS SDK, il fallait être membre du programme VSIP. Il y avait alors 3 niveaux : Affiliate (membre de base, sans frais d’entrée dans le programme), Alliance et Premium.
Aujourd’***, le VS SDK est librement téléchargeable, ainsi que les ressources pour l’exploiter. En effet, en plus des entreprises qui créent des produits commerciaux autour de Visual Studio (c’était la raison d’être initiale de VSIP), Microsoft veut également aider techniquement les organisations, les communautés techniques ou les individus, qui veulent étendre Visual Studio et distribuer les extensions a l’intérieur de leur organisation, ou tout simplement, par hobby (si ! si ! ca existe !). C’est tout là qu’est la mission de mon équipe VSX.
Du coup le programme VSIP est réduit à deux niveaux (puisque le niveau Affiliate n’est plus utile que pour demander des PLK et des SLK ... dont il faut bien dire qu'elles embêtent un peu tout le monde). Et la grande nouvelle que j’ai apprise, c’est que même simplement pour des raisons techniques, le niveau Alliance est rudement intéressant. Il vous offre notamment :

un contact direct avec les équipes de Microsoft (la notre, mais aussi le cas échéant des équipes du cœur de Visual Studio, de Team Architect, etc …). Ces contacts ont lieu au cours de réunions techniques qu’on appelle Dev clinics, où, en fait, les membres du programme apportent leurs propres problèmes, questions et y trouvent des réponses. Alors, vous me direz c’est a Redmond. Oui, 4 fois par ans c’est à Redmond, mais il y a aussi une DevClinic en marge de la TechEd Europe. Et puis, bon, … ca pourrait venir des DevClinics plus fréquentes en Europe.
L’accès a des informations sur le futur de Visual Studio et a des informations business (reserve aux seuls membres)
L'accès a des builds internes (voir des sources pour le niveau Premium)

Je vous mets ci-dessous un slide qui compare les deux programmes.

Vous me direz maintenant, ca a un cout. Ben oui, c’est vrai, mais, ..., j’ai oublie de vous dire ... il y a un abonnement d’un an a MSDN Premium (donc avec Team System) d’inclus dans le programme … et donc ... , dans le cas du niveau Alliance, cela n’est finalement plus cher du tout … (et on ne parlera pas du taux de change actuel du dollar). Hummm ....

Mes premiers pas chez Microsoft - UK ... si on peut dire

2008-06-03T20:23:00Z

Certains d’entre vous le savent déjà. Peut-être tous : j’ai maintenant un blog sur MSDN. Bon ! le contenu est en anglais, et ca ne va pas m’empêcher d’écrire sur celui-ci, en français.

En effet, je travaille pour Microsoft UK, à Cambridge, depuis le 25 mars, mais je n’ai pas encore eu (enfin, pris) le temps de vous l’annoncer, et voici pourquoi. En fait, à vrai dire, j’ai commencé par sécher la première semaine, parce que le soir même de mon départ de la DGA je rentrais d’urgence a l’hôpital (militaire bien sur : d'ailleurs cet hôpital est vraiment génial, et le personnel soignant est dévoué et compétent ... je n'ai pas trouvé que c'était si fréquent, alors je voulais le dire, au passage). Bon ! Alors vous imaginez ! commencer un nouvel emploi, et dans un autre pays en plus, et ne pas être là au début ! Il a fallu que ca tombe sur moi !! Evidemment cela a bien fait rire mes petits copains de MS France ! Mais ca c’est bien passe quand même. Je ne dirais pas que chez Microsoft de telles situations sont prevues, mais, bon, ils ont gere. Je me demande ce que ca aurait donne le meme cas dans la DGA ?

Ensuite, quand je dis que je travaille à Cambridge, ce n’est pas tellement vrai non plus. Au bout de deux semaines j’étais à Redmond, pour deux semaines. En effet, j’appartiens a l’équipe Visual Studio Ecosystem, (notre portail est justement http://msdn.com/vsx) et, si j'ai l'honneur de partager mon bureau avec Stuart Kent et Steve Cook (entre autres), mon manager, James Lau, est aux US … quand on peut faire simple, ce n’est pas intéressant pour Jean-Marc !

Apres mon séjour aux US (ou j'ai trouvé qu'il faisait bien froid pour une fin avril), je me suis laisse embringuer dans un Tour d’Europe VSX, avec James, justement. On en parle sur nos blogs (enfin surtout lui, parce que moi j’écris quand même moins et moins vite en anglais qu’en français, quoi que, avec mon clavier anglais, c’est assez difficile pour les accents et les c cédilles). On s’amuse beaucoup, et notre public a l’air d’aimer.

Du coup j’ai appris plein de choses. Et en particulier quelque-chose qui pourrait vous intéresser sur le programme VSIP.

DslFactory en session pleinière aux Techdays

2008-03-06T05:02:00Z

Sébastien a eu l'honneur de participer à la session pleinière du 3ème jour des Techdays, le 13 février dernier.

Il illustrait une partie présentée par Bernard Ourghanlian, directeur technique et de la sécurité de Microsooft France à qui il donnait la réplique. Il a ainsi présenté, devant plus de 4000 personnes, un DSL spécifique de comportements dynamiques de simulation, créé par la Marine Nationale et la Délégation Générale pour l'Armement.

J'ai hâte de voir les webcasts !

Lancement de la "Visual Studio Gallery"

2008-02-28T05:00:00Z

L'équipe "Visual Studio Ecosystem" de Microsoft vient de lancer officiellement, hier, la "Visual Studio Gallery" que vous pourrez trouver en http://visualstudiogallery.com/

C'est un portail dans lequel sont référencés, regroupés par catégorie, auteur, etc ... tout un tas de produits ou exemples de personalisation et d'extensibilité Visual Studio. Certains sont gratuits et libres, d'autres des versions d'évaluation, et d'autres, encore des produits commerciaux. Cela va des macros, snippets, aux langages graphiques DSL en passant par des packages etc ...

Evidemment, nous sommes présents, ! avec, pour le moment, le WCF Designer, et la bibliothèque DslFactory.Utilities, et d'autres exemples vont venir les compléter dans les semaines qui suivent.

Notez enfin que l'équipe VSX en a profité pour changer le look de son portail : http://msdn.com/vsx

Migrer un DSL de Visual Studio 2005 vers Visual Studio 2008

2008-01-12T18:21:00Z

Les DSL çà se migre bien !

Tout d'abord, je voudrais vous souhaiter une excellente année 2008. Nous avons été un peu négligents, ces temps-ci, vis à vis de la communauté. Nous étions, Alain, Sébastien et moi en train de nous remettre du VSX Day (et çà vous a laissé le temps d'en digirer tout le contenu ;-)).

Mais il était prévu qu'on aborde un peu plus en détails le VS SDK de VS 2008 en début d'année, alors allons-y !

Nico a demandé, (fin novembre - honte à nous !),

"Est ce que l'on a une idée de la compatibilité des DSL fait en VS 2005 avec VS 2008 ?
Pour l'instant, l'installation ne fonctionne pas (le setup généré réclame VS 2005).
Faut-il recompiler le projet en VS 2008 ? Est ce que tout le méta-modèle est compatible ?"

Je viens seulement de m'intéresser à la migration de mon plus gros DSL (en terme de classes, mais çà, ce n'est pas très important, puisque c'est du code qui est généré généré, mais surtout en terme de volume code custom). En supposant que le SDK 2008 est installé dans C:\Program Files\Microsoft Visual Studio 2008 SDK, j'ai suivi la procédure expliquée dans le fichier C:\Program Files\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Tools\DSLTools\MigrationGuide.htm, et çà m'a pris même pas deux heures, j'ai eu une nouvelle PLK en 5 minutes, et çà a parfaitement marché du premier coup. Mes modèles existants se sont parfaitement ouverts dans VS 2008, et tout fonctionne comme avant. Je m'y attendais, pour tout vous dire, mais l'équipe DSLTools a encore fait fort.

Je suis donc en mesure de répondre :

"Est ce que l'on a une idée de la compatibilité des DSL fait en VS 2005 avec VS 2008 ? " oui : elle me semble parfaite.

"Faut-il recompiler le projet en VS 2008 ?" Oui, mais c'est un peu plus compliqué que çà.

"Est ce que tout le méta-modèle est compatible ?" le .dsl l'est. Le méta-modèle aussi, il le semble !

La procédure de migration - retour d'expérience

Alors pourquoi çà m'a pris quand même deux heures ? je vais l'expliquer, et pour çà je vais migrer avec vous un autre DSL que vous connaissez : le DSL WCF Language.

Le guide de migration nous dit qu'il faut :

Première étape : créer un nouveau DSL minimal avec Visual Studio 2008 en lui donnant le même nom de DSL et le même nom de namespace que le DSL à migrer. Ces informations peuvent se trouver dans le fichier dsldefinition.dsl original (ou encore dans les propriétés du DSL que vous trouverez dans la fenêtre des propriétés en cliquant sur le fond diagramme que constitue la définition de votre DSL : propriétés Name (WcfLanguage) et Namespace (DslFactory.WcfLanguage)).

Première surprise : la solution a changé, on a des fichiers en plus :

ils concernent la suppression de warning lors de l'analyse statique de code.
Par ailleurs, le répertoire CtcComponents et son horrible fichier Commands.ctc du projet DslPackage a été remplacé par un fichier Commands.vsct qui décrit les menus au format XML.

Deuxième surprise : si vous exécutez le DSL, vous verrez que les formes sont plus belles, et plus fines qu'auparavant (les icônes par défaut ont également changé)

Deuxième étape : remplacer les fichiers dsldefinition.dsl et dsldefinition.dsl.diagram de la nouvelle solution sous Visual Studio 2008, par ceux de la version 2005, ainsi que le contenu des répertoires Resources des deux projets Dsl et DslPackage. C'est important parce que les ressources, notamment les images, seront référencées par le code généré à partir du .dsl.

Il est possible que vous ayiez également à ajouter des références au projets si vous utilisez des Domain Types externes (c'est le cas pour le WcfLanguage où nous utilisons les types AdressFilterMode de System.ServiceModel et IsolationLevel de System.Transactions, il nous faut donc référencer ces deux assemblages.

Si vous avez des propriétés dont le Kind est CustomStorage, vous devrez aussi recopier du code custom. Comme le WCF Language est bien structuré, il nous suffit d'ajouter le répertoire "CustomCode", ainsi que le fichier Resources.resX que nous avions ajouté dans le répertoire de solution Properties en lui donnant comme propriété "Custom Tool" la valeur ResXFileCodeGenerator

Troisième étape : l'ajout de références

Si votre projet était simple, vous n'auriez éventuellement aucune référence à ajouter, ou bien uniquement des références à des assemblages qui ne sont pas concernés par le changement de Visual Studio. Par contre, dans le cas du WcfLanguage, nous avons des références à DslFactory.Utilities (qui aura été migré de la même façon), EnvDTE, et EnvDTE80. Il faut donc ajouter ces références aux assemblages EnvDTE, mais en prenant bien garde à ce que cela soit ceux de Program Files\Microsoft Visual Studio 9 et pas de Visual Studio 8. Dans le cas du WCF Language, il faut aussi ajouter VSLangProj en prenant les mêmes précautions (même si l'assemblage de même numéro de version peut aussi se trouver en d'autres endroits, comme dans Visual Studio 8) [il faut vous dire que sur ma machine, j'ai encore conservé Visual Studio 2005 et son VS SDK 4.0 à coté de Visual Studio 2008 et son VS SDK 1.0, c'est pourquoi je pourrais me tromper en ajoutant les références. Si vous n'avez que le VS SDK 2008, vous n'aurez pas ce problème]

Quatrième étape : transformer tous les templates, générer le DSL et l'exécuter.

Et çà marche !

Quatrième étape : Migrer les boutons, menus contextuels.

Il nous reste une chose à faire : notre DSL n'a pas encore retrouvé les menus contextuels sur ses formes. Dans la solution pour Visual Studio 2005, deux fichiers étaient concernés :

GeneratedCmd.tt qui contenait la définition des ids des boutons (generate, showAsRole, etc ...)

<#@ Dsl processor="DslDirectiveProcessor" requires="fileName='..\..\Dsl\DslDefinition.dsl'" #>

<#@ include file="DslPackage\GeneratedCmd.tt" #>

#define guidCmdSet { 0xe642d46e, 0x89bf, 0x4dd6, { 0xbe, 0x00, 0x81, 0x8f, 0x27, 0x92, 0xfc, 0x1b } }

#define generate 0x100

#define showAsRole 0x101

#define showAsMember 0x102

#define hide 0x103

#define showHiddenMembers 0x104
#define showUsedConcepts 0x105

et Commands.ctc du répertoire CtcComponents

#include "stdidcmd.h"

#include "vsshlids.h"

#include "msobtnid.h"

#include "virtkeys.h"

#include "DSLToolsCmdID.h"

#include "..\GeneratedCode\GeneratedCmd.h"

CMDS_SECTION guidPkg

MENUS_BEGIN

GENERATED_MENUS

// Add additional menu definitions here.

// NewMenu, Relative to Group, Priority, Type, Name, Text;

MENUS_END

NEWGROUPS_BEGIN

GENERATED_GROUPS

// Add additional menu group definitions here.

// NewGroup, Parent Group, Priority;

NEWGROUPS_END

BUTTONS_BEGIN

GENERATED_BUTTONS

// Add additional button definitions here.

// Command, Parent Group, Priority, Image, Type, Visibility, Text;

guidCmdSet:generate, guidCmdSet:grpidContextMain, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Generate code" ;

guidCmdSet:showAsRole, guidCmdSet:grpidContextMain, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Show as a role" ;

guidCmdSet:showAsMember, guidCmdSet:grpidContextMain, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Show as a member" ;

guidCmdSet:hide, guidCmdSet:grpidContextMain, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Hide the member" ;

guidCmdSet:showHiddenMembers, guidCmdSet:grpidContextMain, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Show hidden members" ;

guidCmdSet:showUsedConcepts, guidCmdSet:grpidContextMain, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Show used concepts" ;

guidCmdSet:showAsRole, guidCmdSet:grpidExplorerMenuGroup, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Show as a role" ;

guidCmdSet:showAsMember, guidCmdSet:grpidExplorerMenuGroup, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Show as a member" ;

guidCmdSet:hide, guidCmdSet:grpidExplorerMenuGroup, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Hide the member" ;

BUTTONS_END

BITMAPS_BEGIN

BITMAPS_END

CMDS_END

CMDUSED_SECTION

CMDUSED_END

CMDPLACEMENT_SECTION

GENERATED_CMDPLACEMENT

// Add additional command placements here.

// Command, Group, Priority;

CMDPLACEMENT_END

VISIBILITY_SECTION

GENERATED_VISIBILITY

// Add additional visibility definitions here.

// Command, GUID when visible;

VISIBILITY_END

KEYBINDINGS_SECTION

// Command, when available, emulation, keystate;

KEYBINDINGS_END

Ces deux fichiers étaient assez embêtants à maintenir parce que non seulement le format du fichier .ctc n'était pas très intuitif, mais en plus il fallait garder la cohérence entre les deux.

Avec le VS SDK 2008, le fichier .ctc a été remplacé par le fichier Commands.vsct qu'il nous faut donc remplir

Avant d'ajouter les commandes, ce fichier a le contenu suivant :

<?xml version="1.0" encoding="utf-8"?>

</Commands>

</CommandTable>

Il nous suffit donc de migrer le contenu du .ctc et du .h dans le .vsct :

D'abord les identifiants des commandes.En s'aidant du fichier GeneratedVSCT.vsct généré, on obtient la fin du fichier suivante où les #define ont été remplacés par des IDSymbol. Le guid du guidCmdSet est recopié tel quel du GeneratedVSCT.vsct :

</Commands>

</GuidSymbol>

</Symbols>

</CommandTable>

Ensuite, nous écrivons les boutons :

A titre d'exemple, la ligne suivante du .ctc :

guidCmdSet:generate, guidCmdSet:grpidContextMain, 0x0200, OI_NOID, BUTTON, DIS_DEF, "Generate code" ;

devient le texte en gras suivant :

<Button guid="guidCmdSet" id="generate" priority="0x0200" type="Button">

<Parent guid="guidCmdSet" id="grpidContextMain"/>

<CommandFlag>DefaultDisabled</CommandFlag>

<CommandFlag>DefaultInvisible</CommandFlag>

<CommandFlag>DynamicVisibility</CommandFlag>

<Strings>

<ButtonText>Generate code</ButtonText>

</Strings>

</Button>

</Buttons>

Pour finir, le fichier devient :

<?xml version="1.0" encoding="utf-8"?>

<CommandFlag>DefaultDisabled</CommandFlag>

<CommandFlag>DefaultInvisible</CommandFlag>