Extensibilidad VS2010: ¿qué tan diferente es?

Question

Una pregunta para aquellos de ustedes que ya vieron VS2010. ¿Qué tan grandes son los cambios que los desarrolladores de complementos tendrán que hacer para que sus complementos funcionen bajo VS2010?

Answer 1

Ya hemos migrado una versión de desarrollo de nuestro producto Visual Lint a VS2010, y en su mayor parte la migración fue sencilla, o lo habría sido si no hubiera tantos errores en el modelo de automatización Visual Studio 2010 Beta 1 . La experiencia ha sido similar al trabajo que tuvimos que hacer para soportar VS2005 (en contraste, VS2008 fue muy fácil), por lo que es obvio que VS2010 representa un cambio importante en la evolución de Visual Studio.

Como estamos usando el mismo binario para todas las versiones de Visual Studio que admitimos (lo que significa que el código está contenido en C ++ nativo en todo momento), los cambios importantes en las interfaces tienden a ser bastante visibles para nosotros. Esta vez, las áreas que nos han causado problemas son:

1. El nuevo formato de archivo de proyecto .vcxproj (analizamos los archivos de proyecto para leer las propiedades del proyecto, ya que es más confiable en múltiples versiones de Visual Studio que usar VCProjectEngine, el modelo de automatización de Visual C ++). Por lo tanto, tuvimos que escribir un nuevo analizador para archivos .vcxproj, y como son potencialmente muy complejos, esa fue una tarea importante en sí misma.
2. Varios errores en la barra de comandos / interfaces de comando (presumiblemente relacionados con la nueva integración del editor WPF / barra de comandos). Carlos Quintero ha blogueado extensamente sobre este tema, por lo que si tiene inquietudes en esta área, le recomendamos leer su blog.
3. Un cambio no documentado en la secuencia de inicio del complemento en Beta 1, lo que significaba que las interfaces de la ventana DTE no funcionaron hasta que se produjo el evento OnStartupComplete. MS nos informó que están revirtiendo este cambio particular en Beta 2 debido a posibles problemas de compatibilidad, pero de todos modos hemos desensibilizado nuestro código ahora.
4. Windows de herramientas en Beta 1 no puede ser creado por CLSID interno (aunque ProgID funciona bien). Este es el último que estamos esperando antes de que podamos concluir el último bit importante del puerto.

Sospecho que nuestra experiencia será bastante representativa para la mayoría de los complementos: es solo si está utilizando las áreas afectadas directamente por cambios importantes en Visual Studio (por ejemplo, el editor o la integración de Intellisense) que es probable que los efectos sean particularmente grave.

Finalmente, no planeamos migrar la compilación misma a VS2010; actualmente está construido en VS2008, y simplemente no podemos ver ninguna razón para migrar a un IDE que muestra todas las señales de que todavía es un "trabajo en progreso". incluso cuando RTMs más adelante este año (aunque esa es solo mi opinión personal, YMMV).

Answer 2

Por suerte, acabo de escribir sobre este asunto exacto y mostró lo que se necesitaba para actualizar mi complemento. (enlaces a continuación)

Básicamente, su respuesta es que hay una migración de bajo impacto, porque una "compatibilidad con retroceso compatible" está en su lugar para la mayoría de las funciones. Sin embargo, es comprensible que para obtener las novedades en 2010, como MAF, MEF y WPF, habrá algo de trabajo por parte de los desarrolladores.

• 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
• (más por venir)

Por último: asegúrese de leer esta excelente publicación de Carlos Quintero, MVP sobre complementos, marcos y compatibilidad con CLR. El blog de Carlos es el mejor que he encontrado para complementos.