Patrice 's Blog

Projettant de développer un plug-in pour VS.net, j'ai bouquiné ce week-end les rares bouquins traitant du sujet.

Il existe 3 manières de personnaliser VS.net :

• Les macros : comme les macros Office, nous avons la possibilité d'écrire des macros pour automatiser certaines tâches. On peut faire pas mal de choses grâce au DTE et au modèle objet permettant de manipuler VS.net. Bien evidemment, le code est interprété par VS.net et on reprend la main sur l'IDE après que le code soit exécuté. Lorsque l'on souhaite déployer une macro on la délivre sous forme de code source ce qui est pas terrible si l'on souhaite protéger notre code méga révolutionnaire que l'on a développé en 6 mois De plus les macros ne peuvent être écrite qu'en VB.net aucun autre langage n'est supporté.
• Seconde manière et la plus courante, le développement d'Add-ins pour VS.net. Les add-ins permettent une intégration dans l'IDE plus poussé notemment en créant des Tool Window comme le Solution Explorer ou la Boite à Outils. On arrive à une intégration professionnelle et très satisfaisante. Mais, car il y a un mais... Oubliez .net si vous souhaitez développer des add-ins vous allez bouffer du COM et de l'ActiveX à foison !!! En effet, un Addin est un composant COM (même si vous pouvez développer les addins en managé en VB.net ou en C#, VS.net va appeler votre addin en tant que composant COM). Vous devez donc créer un GUID, enregistrer votre composant COM dans la base de registre, et l'enregistrer de nouveau dans la base de registre pour indiquer à VS.net que ce composant est un addin qu'il peut utiliser. Cela peut déjà paraitre lourd (pourquoi on peut pas développer des assemblys .net directement ??? ) mais ce n'est pas tout... Si l'on souhaite développer une Tool Window, vous devez multiplier par 2 ce genre de manipulations foireuses d'un autre temps... En effet une ToolWindow est de nouveau un composant COM (En effet, chaque ToolWindow (le Solution Explorer, la boite à outils, etc..) sont en réalité des contrôles ActiveX ! ), donc vous devez créer un autre GUID enregistrer votre composant COM dans la base de registre, et enregistrer de nouveau votre composant dans la base de registre pour indiquer à VS.net que ce composant est une ToolWindow. A ce stade là on a une toolwindow que l'on peut intégrer à VS.net mais sans interface. Pour intégrer une interface, il faut développer... un controle ActiveX qui contiendra des boutons, zones de textes, etc... et de nouveau enregistrement du composant ActiveX dans la base registre... Bien évidemment, comme on ne peut pas développer d'ActiveX avec .net (vb.net ou c#), on doit développer notre interface en non managé donc en C++ ou en VB6 (de koi faire des plug-in de + de 2Mo... ). La seule solution viable est donc de faire son contrôle en C++... Encore un mauvais point... Heureusement un développeur de chez MS a développé un petit contrôle ActiveX qui hoste des User Controls .net On doit donc quand même enregistrer ce contrôle ActiveX mais on bénéficie de l'IDE de VS.net et des contrôles .net pour faire notre interface
• 3ème solution et la plus puissante : les packages VSIP, et de nouveau vous pouvez oublier .net car vous ne pouvez développer vos packages VSIP qu'en C++ non managé. Il faut donc encore user d'astuce pour coder le strict minimum en C++ et loader des bibliothèques .net que vous aurez développé.

La question que je me pose est donc : Pourquoi MS n'utilise-t-il pas lui même .net pour développer ses outils (et notamment VS.net) mais continue d'utiliser COM et les ActiveX et nous oblige donc à notre tour à utiliser les précédentes générations de technos maison ??? (Cela semble être reglé avec VS 2005, on pourra apparemment tout faire en managé mais bon... je vais pas attendre 2005 pour développer mon plugin...)