VS2010 Extensibility - En quoi est-ce différent?

Question

Une question à ceux d’entre vous qui ont déjà regardé VS2010. Quelle est l'ampleur des changements que les développeurs de compléments devront effectuer pour que leurs compléments fonctionnent sous VS2010?

Answer 1

Nous avons déjà migré une version de développement de notre produit Visual Lint vers VS2010 et la migration était généralement simple - ou l'aurait été s'il n'y avait pas eu autant de bogues dans le modèle d'automatisation Visual Studio 2010 Bêta 1 . L’expérience ressemble au travail que nous avons dû faire pour prendre en charge VS2005 (VS2008 était en revanche un jeu d’enfants), il est donc évident que VS2010 représente un changement majeur dans l’évolution de Visual Studio.

Comme nous utilisons le même fichier binaire pour toutes les versions de Visual Studio que nous prenons en charge (ce qui signifie que le code reste en C ++ natif), les modifications les plus récentes des interfaces ont tendance à être assez visibles pour nous. Cette fois-ci, les problèmes qui nous ont causé sont:

1. Le nouveau format de fichier de projet .vcxproj (nous analysons les fichiers de projet pour lire les propriétés du projet, car ils sont plus fiables entre plusieurs versions de Visual Studio que d'utiliser VCProjectEngine - le modèle d'automatisation Visual C ++). Par conséquent, nous avons dû écrire un nouvel analyseur syntaxique pour les fichiers .vcxproj. En raison de leur complexité potentielle, il s’agissait là d’une tâche majeure.
2. Divers bogues dans les interfaces barre de commande / commande (probablement liés à la nouvelle intégration de l'éditeur / barre de commande WPF). Carlos Quintero a beaucoup blogué sur ce sujet, alors si vous avez des inquiétudes dans ce domaine, nous vous conseillons de lire son blog.
3. Modification non documentée de la séquence de démarrage du complément dans la version bêta 1, ce qui signifie que les interfaces de fenêtre DTE ne fonctionnaient pas tant que l'événement OnStartupComplete n'avait pas eu lieu. Les États-Unis nous ont informés qu'ils annulaient ce changement particulier dans la version bêta 2 en raison de problèmes de compatibilité éventuels, mais nous avons désensibilisé notre code à celui-ci maintenant, de toute façon.
4. Les fenêtres d’outils de la Bêta 1 ne peuvent pas être créées par un CLSID interne (bien que ProgID fonctionne correctement). C’est la dernière chose que nous attendons avant de pouvoir conclure le dernier élément majeur du port.

Je pense que notre expérience sera assez représentative de la plupart des compléments - ce n’est que si vous utilisez les zones directement affectées par les modifications majeures apportées à Visual Studio lui-même (par exemple, l’éditeur ou l’intégration d’intellisense) que les effets sont susceptibles de se produire. particulièrement sévère.

Enfin, nous ne prévoyons pas de migrer la version elle-même vers VS2010; il est actuellement construit dans VS2008 et nous ne voyons tout simplement aucune raison de migrer vers un IDE qui présente tous les signes de "travail en cours". même quand il RTMs plus tard cette année (c'est juste mon opinion personnelle cependant - YMMV).

Answer 2

Par chance, je viens d'écrire à propos de ce sujet exact et a montré ce qu'il fallait pour mettre à niveau mon complément. (liens ci-dessous)

En gros, votre réponse est qu’il existe une migration à faible impact, car une "cale" compatible avec les versions antérieures est en place pour la plupart des fonctionnalités. Naturellement, cependant, pour obtenir les nouveautés en 2010, telles que MAF, MEF et WPF, des travaux seront nécessaires sur la partie développeurs.

• http: / /jb-brown.blogspot.com/2008/11/migrating-visual-studio-add-in-to-2010.html
• http: / /jb-brown.blogspot.com/2008/11/migrating-visual-studio-add-in-to-2010_29.html
• (plus à venir)

Enfin - Assurez-vous de lire cet article remarquable de Carlos Quintero, MVP sur la compatibilité des compléments, des cadres et du CLR. Le blog de Carlos est le meilleur que j'ai trouvé pour les ajouts.