Estensibilità VS2010: quanto è diversa?

Question

Una domanda per quelli di voi che hanno già guardato VS2010. Quanto sono grandi le modifiche che gli sviluppatori di componenti aggiuntivi dovranno fare per far funzionare i loro componenti aggiuntivi con VS2010?

Answer 1

Abbiamo già migrato una versione di sviluppo del nostro prodotto Visual Lint su VS2010 e per la maggior parte la migrazione è stata semplice - o lo sarebbe stata se non ci fossero così tanti bug nel modello di automazione Beta 1 di Visual Studio 2010 . L'esperienza è stata simile al lavoro che dovevamo fare per supportare VS2005 (al contrario VS2008 è stato un gioco da ragazzi), quindi è ovvio che VS2010 rappresenta un grande cambiamento nell'evoluzione di Visual Studio.

Poiché stiamo usando lo stesso binario per tutte le versioni di Visual Studio che supportiamo (il che significa che il codice è concepito per essere C ++ nativo in tutto), le modifiche alle interfacce tendono ad essere abbastanza visibili per noi. Questa volta, le aree che ci hanno causato problemi sono:

1. Il nuovo formato di file di progetto .vcxproj (analizziamo i file di progetto per leggere le proprietà del progetto poiché è più affidabile su più versioni di Visual Studio rispetto all'uso di VCProjectEngine, il modello di automazione di Visual C ++). Quindi abbiamo dovuto scrivere un nuovo parser per i file .vcxproj, e poiché sono potenzialmente molto complessi, questo è stato un compito importante in sé.
2. Vari bug nella barra dei comandi / interfacce di comando (presumibilmente correlati alla nuova integrazione dell'editor / barra dei comandi di WPF). Carlos Quintero ha scritto un ampio blog su questo argomento, quindi se hai dubbi in questo settore ti consigliamo di leggere il suo blog.
3. Una modifica non documentata alla sequenza di avvio del componente aggiuntivo in Beta 1, il che significa che le interfacce DTE Window non funzionavano fino a quando non si è verificato l'evento OnStartupComplete. Gli Stati Uniti ci hanno informato che stanno invertendo questo particolare cambiamento nella Beta 2 a causa di potenziali problemi di compatibilità, ma abbiamo desensibilizzato il nostro codice a questo ora, comunque.
4. Le finestre degli strumenti in Beta 1 non possono essere create dal CLSID interno (sebbene ProgID funzioni correttamente). Questo è l'ultimo che stiamo aspettando prima di poter concludere l'ultimo bit importante della porta.

Sospetto che la nostra esperienza sarà piuttosto rappresentativa per la maggior parte dei componenti aggiuntivi - è solo se si stanno utilizzando le aree interessate direttamente dai principali cambiamenti in Visual Studio stesso (ad esempio editor o integrazione di intellisense) che gli effetti possono essere particolarmente grave.

Infine, non stiamo pianificando la migrazione della build stessa su VS2010; è attualmente costruito in VS2008, e semplicemente non possiamo vedere alcun motivo per migrare verso un IDE che mostra tutti i segni di essere ancora un "work in progress" anche quando sarà RTM entro la fine dell'anno (questa è solo la mia opinione personale - YMMV).

Answer 2

Per fortuna, ho appena scritto di questo argomento esatto e ha mostrato cosa ci voleva per aggiornare il mio componente aggiuntivo. (link sotto)

Fondamentalmente la tua risposta è che c'è una migrazione a basso impatto, perché un back shards compatibile "shim" è disponibile per la maggior parte delle funzionalità. Comprensibilmente, però, per ottenere le nuove cose nel 2010 come MAF, MEF e WPF, ci sarà un po 'di lavoro da parte degli sviluppatori.

• 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
• (altri a venire)

Infine, assicurati di leggere questo post eccezionale di Carlos Quintero, MVP su componenti aggiuntivi, Frameworks e compatibilità CLR. Il blog di Carlos è il migliore che ho trovato per i componenti aggiuntivi.