Dot.Blog

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

Blend 2 n'appelle pas VS 2008 mais VS 2005 : la solution [edit]

Voilà un truc agaçant : vous possédez les derniers softs de la dernière technologie de la mort-qui-tue et voila que pour créer le gestionnaire du "click" d'un bouton dans Blend 2 ce dernier vous dit que vous n'avez pas Visual Studio et qu'il a copié le code dans le presse-papiers. Il va falloir lancer à la main VS 2008, ouvrir le fichier cs qui va bien et faire un "coller" à la mimine. Back to the préhistoire ? Non : bug.

En fait ce bug est de type "registry". Lorsque VS s'installe il renseigne une clé de la registry qui indique son CLSID. Ainsi, les autres produits MS peuvent savoir quelle version de VS appeler. C'est simple et c'est bien vu. ... sauf qu'il manque un petit test pour s'assurer qu'on ne "régresse" pas dans les versions par exemple. Et c'est le cas si vous avez installer SQL Server 2005 après VS 2008.

Je parle de la version complète, pas la version Express de SQL Server 2005, la version qui installe... VS 2005 pour BIDS notamment. Et dans ce cas, la dernière version installée de VS est bien 2005 qui joyeusement et sans rien tester colle son CLSID à la place de celui de VS 2008. Moralité, soit Blend 2 appelle VS 2005 (ce qui est dommage pour le support du framework 3.5 !), soit vous avez désinstallé VS 2005 et Blend 2 ne le voyant pas (et ne cherchant pas VS 2008) vous propose de coller vous même le code du gestionnaire d'événement qu'il vient de créer...

C'est un bel exemple qui illuste à quel point tout informaticien doit rester humble même lorsqu'il a créé une application extraordinaire... ça finira toujours par péter à la figure de quelqu'un, un jour, exhibant alors un odieux bug, le vilain petit grain de sable dans la belle mécanique...

C'est donc le cas ici, malgré la qualité fantastique de Visual Studio et de Blend, et pour un petit bug dans une séquence mineure (écrite par un stagiaire, allez savoir), c'est tout l'extraordinaire édifice créé par ces deux outils qui s'écroule en partie au moins, faisant régresser "l'expérience utilisateur" (la mienne en l'occurence!) à la préhistoire des OS fenêtrés où bien avant COM ou autre DDE encore plus primitif, la seule façon de faire "communiquer" deux applications était le copier/coller !

On notera que ce petit bug serait sans conséquence si Blend prévoyait dans ses réglages le choix de la version de VS à utiliser. Et ici nous avons une autre démonstration : une mauvaise analyse ou réalisation d'une partie accessoire du logiciel (le paramétrage dans ce cas) met en évidence un bug qui aurait pu être masqué. Leçon à retenir : tout logiciel qui doit en appeler d'autres ou faire référence à des "objets" (au sens le plus large) externes doit absolument posséder dans ses réglages un moyen de dire quels sont ces applications ou ces objets et à quel endroit les trouver. Pan sur le doigts des développeurs de Blend :-)

Un bug dans le setup de VS + Un manquement à cette dernière "best practice" et c'est le mariage entre deux outils complémentaires qui se transforme en un divorce !

En farfouinant, j'ai trouvé la solution. Elle consiste tout simplement à trouver cette fameuse entrée de la registry ou VS indique son CLSID, entrée qui est utilisée par Blend notamment pour savoir comment appeler VS. Ensuite il faut connaître le CLSID de VS 2008 pour le mettre à la place de celui de VS 2005. Une fois qu'on a ces deux informations et qu'on effectue la correction, Blend 2 lance à nouveau VS 2008 automatiquement lorsqu'il créé un gestionnaire d'événement. Ouf !

Et comme je ne suis pas vache, après vous avoir fait la morale sur les bugs et les dialogues de paramétrage des applications, je vais vous donner cette fameuse entrée de registry et ce fameux CLSID... Roulement de tambour... And the winner is.....

changer la valeur de HKEY_CLASSES_ROOT\VisualStudio.DTE\CLSID 
en {1A5AC6AE-7B95-478C-B422-0E994FD727D6}

C'est tout. Bon, sauvegardez votre registry avant de faire la manip, je ne suis pas responsable si ça ne change rien chez vous, et je ne veux rien savoir si après la modif votre ordinateur ne boote plus ou que votre femme part vivre en Alaska avec votre soeur alors même que vous apprenez que votre père est le facteur et toutes ces considérations légales qu'on ajoute généralement dès qu'on donne un conseil qui demande à toucher à la registry. Vous êtes prévenu ! :-)

Et Stay Tuned !

[EDIT 20-9-08]
La solution fonctionnait mais quand j'ai refait la manip le lendemain, un double-click sur un .cs dans un projet sou Blend 2 m'ouvrait le fichier dans le bloc-notes... Et plus de liaison avec VS 2008. Grrrrr.

En (re)farfouillant, j'ai modifié deux autres petites choses qui semblent (en plus de la manip déjà décrite), cette fois-ci, apporter une réponse complète :

  1. Vérifier que les fichiers .cs sont bien associés à "Microsoft Visual Studio Version Selector", le double-click sous Blend semble utiliser les associations de fichier de Windows plutôt que le système de CLSID de la registry.
  2. Dans la clé HKEY_CLASSES_ROOT\VisualStudio.DTE évoquée plus haut, outre l'entrée CLSID il faut aussi mettre l'entré CurVer en conformité, elle doit contenir VisualStudio.DTE.9.0 et non pas la même chose avec 8.0 (VS 2005).

Voici le résultat final (exportation de branche depuis regedit) :

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\VisualStudio.DTE]
@="Microsoft Visual Studio DTE Object"

[HKEY_CLASSES_ROOT\VisualStudio.DTE\CLSID]
@="{1A5AC6AE-7B95-478C-B422-0E994FD727D6}"

[HKEY_CLASSES_ROOT\VisualStudio.DTE\CurVer]
@="VisualStudio.DTE.9.0"

Voilà... En espérant que cela aidera quelques âmes égarées sur la toile en quête d'une réponse à ce problème...
[/EDIT]

blog comments powered by Disqus