---

Agosto 2017

Volume 32 Numero 8

Il presente articolo è stato tradotto automaticamente.

Visual Studio - Creazione di estensioni per più versioni di Visual Studio

Da Carlos Quintero | 2017 agosto

La versione di una nuova versione di Visual Studio è sempre una sfida per gli sviluppatori di estensioni (pacchetti, componenti aggiuntivi, modelli e così via). Ad esempio, Visual Studio 2010 introdotti di nuovo Visual Studio Installer per le estensioni (file con estensione VSIX). Visual Studio 2012 sono state introdotte i temi chiaro o scuro; e Visual Studio 2015 rimosso aggiuntivi (con il componente aggiuntivo Gestione). non dimenticare che ogni versione di Visual Studio fornisce un nuovo SDK, i nuovi assembly di estendibilità e nuove API. Con Visual Studio 2017, questo problema è ancora maggiore, a causa di impostazioni del nuovo modulare in base a carichi di lavoro e i singoli componenti e a una nuova versione del manifesto per il meccanismo di distribuzione VSIX. Mentre alcuni sviluppatori (in particolare da Microsoft) rilasciare una nuova estensione diversa per ogni versione di Visual Studio, la maggior parte si preferisce rilasciare una singola estensione aggiornata destinate le versioni più ampia di intervallo di Visual Studio.

In questo articolo verrà illustrato a questo scopo. A tale scopo, verrà esaminata lo scenario più comune: un pacchetto con un comando, creato in un linguaggio gestito (c#, in questo caso) e distribuito come file VSIX.

Gli obiettivi da portare a termine sono i seguenti:

• Per utilizzare un singolo progetto di Visual Studio per creare il pacchetto.
• Per utilizzare Visual Studio 2017 per lo sviluppo e debug.
• Per generare un singolo pacchetto DLL come risultato della compilazione.
• Inserire tale singola DLL all'interno di un singolo file VSIX.
• Per poter installare il file VSIX in Visual Studio 2017 e in molte versioni (2015, 2013 e così via) precedenti.

Perché sono necessari due elementi, ovvero un file DLL (ovvero il pacchetto) e un file di progetto VSIX (che rappresenta il mezzo di distribuzione per il pacchetto), verrà descritto ognuno di questi separatamente: In primo luogo, il loro funzionamento in fase di esecuzione o di installazione in secondo luogo, come per svilupparle.

Il File VSIX

Come accennato in precedenza, Visual Studio 2010 è stato introdotto il meccanismo di distribuzione VSIX per installare le estensioni di Visual Studio, che è stato il modo allora. Un file VSIX ha l'estensione. VSIX e può essere installato in modi diversi. Se viene pubblicato il file VSIX in Visual Studio Marketplace (in precedenza Visual Studio Gallery) ed è compatibile con la versione di Visual Studio e l'edizione in uso, è possibile installarlo tramite la finestra di dialogo estensioni e aggiornamenti. Nel menu Strumenti, fare clic su estensioni e aggiornamenti e quindi passare a Online | Visual Studio Marketplace (vedere figura 1 le estensioni e finestra di dialogo aggiornamenti).

Figura 1, le estensioni e aggiornamenti finestra di dialogo

È anche possibile fare doppio clic su un file VSIX. In questo caso, esecuzione di Visual Studio avvio (C:\Program Files (x86) \Common Shared\MSEnv\VSLauncher.exe) associata all'estensione di file. VSIX. Consente di individuare l'utilità VSIXInstaller.exe della versione di Visual Studio installata più recente (la versione più recente è necessario essere in grado di installare tutte le versioni precedenti). Quindi, il programma di installazione di VSIX Mostra la finestra di dialogo in figura 2 il programma di installazione di VSIX che consente di selezionare le versioni compatibili di Visual Studio ed edizioni in cui installare l'estensione.

Figura 2, il programma di installazione VSIX

File VSIX possono essere installati a livello di programmazione, tramite l'utilità VSIXInstaller.exe con le opzioni della riga di comando, ad esempio la destinazione di Visual Studio versione (2017, 2015 e così via) e l'edizione (Community, Professional e così via). È possibile trovare tale utilità nella sottocartella Common7\IDE dell'installazione di Visual Studio.

In ogni caso, Visual Studio o l'utilità VSIXInstaller.exe deve sapere quali versioni di Visual Studio ed edizioni supporta il file VSIX. Tali informazioni possono essere individuate tramite un file manifesto all'interno del file. Il file VSIX è effettivamente un file con estensione zip, pertanto è possibile rinominare l'estensione del file. VSIX in. zip e quindi aprirlo per esaminarne il contenuto (vedere figura 3 contenuto di un File3 VSIX).

Figura 3 contenuto di un File di progetto VSIX

Come si può notare, esistono più file all'interno di: Il file DLL è il pacchetto DLL. Il file. pkgdef viene usato in fase di installazione per aggiungere alcune chiavi nel Registro di sistema di Windows che consente a Visual Studio per la DLL viene riconosciuto come un pacchetto. Il file [Content_Types] XML descrive il tipo di contenuto per ogni estensione di file (. dll, JSON e così via). I file catalog.json e manifest.json sono necessari per Visual Studio 2017. Il file extension vsixmanifest descrive il nome di estensione, versione e informazioni e le versioni di Visual Studio le edizioni supportate.

È possibile decomprimere il file Extension. vsixmanifest e aprirlo con un editor di testo per esaminarne il contenuto, che avrà un aspetto simile a quello mostrato figura 4 il contenuto di un manifesto File4.

Figura 4 il contenuto di un File manifesto

Come si può notare, il manifesto indica l'elemento XML InstallationTarget le edizioni supportate di Visual Studio. In questo caso, il valore Microsoft.VisualStudio.Pro ha come destinazione la versione Professional edition e versioni successive, ad esempio Premium, Ultimate, Enterprise e altre tali edizioni. Si noti che è destinato anche l'edizione Community, che è sostanzialmente Professional edition con alcune restrizioni di licenza e senza alcune funzionalità. Inoltre, indicante l'intervallo di versioni supportate di Visual Studio: 10.0 (2010), 11.0 (2012), 12.0 (2013), 14.0 (2015), 15.0 (2017).

Quando il file VSIX di un'estensione per ogni utente è installato (da Visual Studio o dal programma di installazione di VSIX), i file all'interno vengono decompressi e copiati in una cartella in questa posizione casuale: C:\Users\ < utente > \AppData\Local\Microsoft\VisualStudio\ < numero di versione > \Extensions\ < casuale di cartella >. < Numero di versione > può avere un suffisso "Exp" viene aggiunto per "Istanza sperimentale" (illustrato più avanti) e per Visual Studio 2017 esso includerà inoltre "id" dell'istanza di Visual Studio installati. L'id istanza viene generato in modo casuale in fase di installazione di Visual Studio; è stato aggiunto per supportare le installazioni side-by-side di versioni della stessa versione (2017) di Visual Studio, un elemento che non è stato possibile prima. Per le estensioni a livello di computer, viene utilizzata la sottocartella Common7\IDE\Extensions. Si noti che in ogni caso ogni versione di Visual Studio utilizza la propria cartella per le relative estensioni.

Anche se sarebbe più interessante se tutte le versioni di Visual Studio è supportato lo stesso formato del manifesto, purtroppo non è il caso. Visual Studio 2010 introdotti VSIX e la prima versione del manifesto. Visual Studio 2012 è stata introdotta la versione 2, completamente diversa e non è compatibile con la versione 1. Tuttavia, Visual Studio 2012, 2013 e 2015, tutta la versione di supporto 2-grado di accettare un manifesto della versione 1, pertanto è possibile compilare un file VSIX con una versione 1 e di destinazione da Visual Studio 2010 a Visual Studio 2015. Ma Visual Studio 2017 supporta la versione 1 né versione 2. In alternativa, è necessaria una versione terzo del manifesto. Fortunatamente, versione 3 mantiene utilizzando il valore "2.0.0.0" nell'attributo versione dell'elemento PackageManifest XML e aggiunge solo un elemento XML denominato < prerequisiti > (e i due nuovi file catalog.json e manifest.json, nel file VSIX). In tal caso, è completamente-compatibile con la seconda versione, è supportata da Visual Studio 2012, 2013 e 2015 (ma non da Visual Studio 2010, che supporta solo la versione 1). Ciò significa che è possibile destinazione di Visual Studio 2010-2017 con un singolo file VSIX. A questo punto, assegnerà in Visual Studio 2010 e continua con un file VSIX che supporta Visual Studio 2012, 2013 e 2015 2017.

Il pacchetto di DLL

Un pacchetto di Visual Studio gestito è una DLL che contiene una classe che eredita da Microsoft.VisualStudio.Shell.Package. È decorata con determinati attributi che consentono al momento della compilazione per generare un file. pkgdef (ovvero, come indicato in precedenza, è possibile trovare all'interno del file VSIX e nella cartella di installazione dell'estensione). Il file. pkgdef viene utilizzato all'avvio (versioni precedenti di Visual Studio) o in fase di installazione (versione 15.3 di Visual Studio 2017) per registrare la DLL come un pacchetto per Visual Studio. Una volta registrato, verrà effettuato un tentativo di caricare il pacchetto a un certo punto, all'avvio o quando uno dei comandi viene eseguito se il pacchetto utilizza il caricamento ritardato, ovvero la procedura consigliata, Visual Studio. Durante il tentativo di caricare la DLL gestita e inizializzare il pacchetto, vengono eseguite tre operazioni: la DLL verrà caricata da Common Language Runtime (CLR) di una versione di Microsoft .NET Framework; utilizza alcune DLL fornite da .NET Framework; utilizzare alcune DLL fornite da Visual Studio. Esaminerà ognuna di queste a sua volta.

.NET Framework è la somma delle seguenti operazioni: Il CLR + librerie (classe di base e librerie aggiuntive). CLR è il runtime (JIT del compilatore, garbage collector e così via) e carica la DLL gestita. In passato, distante ogni .NET Framework versione 1.0, 1.1 e 2.0 (usato da Visual Studio.NET 2002, Visual Studio.NET 2003 e Visual Studio 2005) fornita la propria versione di Common Language Runtime (1.0, 1.1 e 2.0). Tuttavia, .NET Framework 3.0 e 3.5, utilizzato da Visual Studio 2008, ha continuato a utilizzare l'esatta stesso CLR 2.0 di .NET Framework 2.0, invece di introdurre una nuova. Visual Studio 2010 introdotto in .NET Framework 4 e Common Language Runtime 4.0, ma poiché quindi all nuove versioni di .NET Framework 4. x sono utilizzati CLR 4.0 (anche se lo scambio "sul posto" con una versione compatibile con le versioni precedenti anziché il riutilizzo di Common Language Runtime 4.0 esatta di .NET Framework 4). Poiché Visual Studio 2012 e versioni successive tutte utilizzano CLR 4.0, la versione di CLR non è un problema quando la DLL di estensione è destinato a Visual Studio 2012, 2013 e 2015 2017.

Librerie costituiscano la seconda parte di .NET Framework; si tratta di DLL a cui fa riferimento un progetto di Visual Studio e utilizzati in fase di esecuzione. Per sviluppare un'unica estensione destinato a più versioni di Visual Studio, è necessario utilizzare il Framework .NET più recente installato per impostazione predefinita per la versione minima di Visual Studio che si desidera di destinazione. Ciò significa che se si desidera di destinazione di Visual Studio 2012 e versioni successive, è necessario utilizzare .NET Framework 4.5. È possibile utilizzare, ad esempio, .NET Framework 4.5.1 introdotti da Visual Studio 2013, perché qualsiasi DLL introdotte nella versione non è presente in un computer con solo Visual Studio 2012 installato. E, a meno che non si necessita di tale DLL, non si desidera imporre agli utenti di installare .NET Framework 4.5.1 per utilizzare l'estensione (potrebbe influire negativamente sulle vendite o di download e di supporto).

L'estensione deve anche le DLL fornite da Visual Studio (in genere denominato Microsoft.VisualStudio.*). In fase di esecuzione, Visual Studio consente di trovare la DLL in alcuni percorsi noti, ad esempio la cartella Common7\IDE con le relative sottocartelle Common7\IDE\PublicAssemblies e Common7\IDE\PrivateAssemblies e dalla Global Assembly Cache (GAC). Global Assembly Cache per .NET Framework 4. x si trova in C:\Windows\Microsoft.NET\assembly (in C:\Windows\assembly è un altro Global Assembly Cache, ma che uno è per versioni precedenti di .NET Framework). Visual Studio 2017 Usa un'installazione più isolata che evita Global Assembly Cache, che si basa invece le cartelle descritte in precedenza.

Esistono un paio di principi fondamentali da seguire quando si sviluppano e generazione di un file VSIX: È necessario utilizzare le versioni fornite per la versione minima di Visual Studio le destinazioni di estensione. Ciò significa che se si desidera di destinazione di Visual Studio 2012 e versioni successive, è necessario utilizzare solo gli assembly e l'estensibilità le API fornite da tale versione (o inferiore). Se l'estensione viene utilizzata una DLL introdotta da Visual Studio 2013 o versioni successive, l'estensione non funzionerà in un computer con solo Visual Studio 2012. Il secondo principio è che l'estensione mai necessario distribuire le DLL di Visual Studio, né ai percorsi detto (cartelle di Visual Studio o Global Assembly Cache), né la cartella di installazione dell'estensione. Queste DLL sono fornite tramite la destinazione di Visual Studio, il che significa che vi non deve includere il file VSIX.

Tutte le DLL Visual Studio contengono un numero di versione (8.0 15.0) nel nome, ad esempio Microsoft.VisualStudio.Shell.11.0.dll o Microsoft.VisualStudio.Shell.Immutable.10.0.dll. Queste informazioni per identificare la versione di Visual Studio che li introdotto, ma non ottenere significativo: è un nome, non è una versione. Ad esempio, sono disponibili quattro versioni di Microsoft.Visual.Studio.Shell.11.0.dll (11.0.0.0, 12.0.0.0, 14.0.0.0 e 15.0.0.0), ciascuno di essi forniti, rispettivamente, da una versione di Visual Studio (2012, 2013, 2015 e 2017). Vengono installati i primi tre 14.0.0.0 per 11.0.0.0 dalla rispettiva versione di Visual Studio nella Global Assembly Cache e la quarta versione, 15.0.0.0, utilizzata da Visual Studio 2017, viene installata nella cartella Common\IDE\PrivateAssemblies.

Perché un'estensione che è destinato a Visual Studio 2012 e versioni successiva è necessario utilizzare gli assembly di Visual Studio con versione 11.0.0.0 (il primo principio indicato in precedenza), ciò significa che il riferimento Microsoft.Visual.Studio.Shell.11.0.dll deve essere versione 11.0.0.0. Tuttavia, poiché tale versione non è installata da Visual Studio 2013 e versioni successive (avviano versione 12.0.0.0) e l'estensione non deve distribuire DLL di Visual Studio (secondo il principio della), non sarebbe l'estensione esito negativo quando si tenta di utilizzare tale DLL di Visual Studio? La risposta è no, e viene grazie a un meccanismo di reindirizzamento dell'associazione di assembly fornito da .NET Framework, che consente di specificare le regole "quando si richiede questa versione di un assembly, utilizzare la versione più recente". Naturalmente, la nuova versione deve essere completamente-compatibile con la versione precedente. Esistono diversi modi per reindirizzare gli assembly da una versione a altra. Unidirezionale è la seguente: Un file eseguibile (con estensione .exe) può fornire un file di configurazione corrispondente (. estensione di file exe) che specifica i reindirizzamenti. In tal caso, se si passa alla cartella di installazione di Visual Studio Common7\IDE, sono disponibili il file eseguibile devenv.exe di Visual Studio e un file devenv.exe config. Se si apre il file. config con un editor di testo, si noterà che contiene un numero elevato di operazioni di reindirizzamento di assembly:

<dependentAssembly>
  <assemblyIdentity
    name="Microsoft.VisualStudio.Shell.11.0"
    publicKeyToken="b03f5f7f11d50a3a"
    culture="neutral"/>
  <bindingRedirect
    oldVersion="2.0.0.0-14.0.0.0
    newVersion="15.0.0.0"/>
</dependentAssembly>

In tal caso, Visual Studio 2017 (15.0) include un reindirizzamento della versione dell'assembly per 11.0 che indica che ogni volta che un elemento richiede 2.0.0.0 a 14.0.0.0, in alternativa, usare la nuova versione 15.0.0.0 le versioni precedenti. Ovvero come Visual Studio 2013 o versioni successive possono utilizzare un'estensione di riferimento 11.0 versione 11.0.0.0, anche se non dispongono di quella determinata versione.

L'estensione di sviluppo

Ora che si conoscono funzionamento in fase di esecuzione, è possibile sviluppare il pacchetto. In breve, si creerà un progetto VSIX usando Visual Studio 2017 con un manifesto che fa riferimento a versioni di Visual Studio dai 12.0 per 15.0; contiene un pacchetto e un comando. e utilizzerà solo i riferimenti con versione 11.0.0.0 (o inferiore) installato da Visual Studio 2012.

Ci si potrebbe chiedere al momento le versioni di Visual Studio devono essere installate nel computer di sviluppo. La procedura consigliata è di due computer di sviluppo come indicato di seguito: Il primo, se si dispone di spazio sufficiente sul disco, installare tutte le versioni di Visual Studio-2015, 2013, 2012 e il 2017. Essi possono tutti coesistere side-by-side e sarà in grado di tali test durante lo sviluppo. Per Visual Studio 2017, addirittura nelle diverse edizioni, ad esempio Community, Professional ed Enterprise possono coesistere nello stesso momento, un elemento che non era possibile con le versioni precedenti di Visual Studio. Se lo spazio disponibile è un problema, installare i componenti minimi per le versioni precedenti, o ignorare alcuni versione al centro dell'intervallo (2013 o 2015).

Nel secondo computer di sviluppo, installare solo Visual Studio 2017 o, ancora meglio, un server di compilazione con nessuna versione di Visual Studio installata (solo la compilazione strumenti 2017), per compilare l'estensione per il rilascio. Questo approccio consente di verificare che l'utente non inavvertitamente utilizzi DLL o altre dipendenze dalle cartelle installate dalle versioni precedenti di Visual Studio. È inoltre possibile chiedersi se sarebbe più sicuro per lo sviluppo o di compilazione in un computer con solo Visual Studio 2012 installato e la risposta è che non è possibile: Per generare un file VSIX per Visual Studio 2017 (che crea un manifesto della versione 3 e aggiunge i file catalog.json e manifest.json), è necessario di Visual Studio SDK 15.0 di Visual Studio 2017 o, con alcune operazioni, Visual Studio SDK 14.0 di Visual Studio 2015. Il Visual Studio SDK 12.0 di Visual Studio 2013 né di Visual Studio SDK 11.0 di Visual Studio 2012 può generare file VSIX per Visual Studio 2017.

E la procedura consigliata per i test (grave): Usare un computer separato (virtuale o basato su cloud) per ogni versione di Visual Studio (è quindi necessario quattro computer per testare l'estensione di Visual Studio 2012 per Visual Studio 2017 in isolamento). Questa procedura consigliata ha consentito di trovare alcuni errori nell'esempio di codice per questo articolo.

Per ottenere i modelli di progetto di Visual Studio 2017 per creare un pacchetto (o qualsiasi altro tipo di estensione) è necessario il carico di lavoro "Sviluppo di estensioni di Visual Studio". Se non è stata installata durante l'installazione di Visual Studio 2017, passare alla cartella C:\Program Files (x86) \Microsoft Visual Studio\Installer, avviare vs_Installer.exe, fare clic sul pulsante di modifica e selezionare il carico di lavoro nella parte inferiore dell'elenco.

Creare un nuovo progetto VSIX usando il File | New | Menu progetto. passare a Visual c# | Modelli di estendibilità. Verificare che .NET Framework 4.5 selezionata nell'elenco a discesa in alto. Selezionare il modello di progetto VSIX. Denominare il progetto VSIXProjectVS2012_2017. Fare doppio clic sul file vsixmanifest per aprire il relativo editor personalizzato. Nella scheda dei metadati, impostare il nome del prodotto, autore, versione e così via. Nella scheda destinazioni di installazione, fare clic sul pulsante di modifica, selezionare l'identificatore Microsoft.VisualStudio.Pro (che valore destinato anche l'edizione Community, che è sostanzialmente Professional edition) e impostare l'intervallo di installazione di destinazione, [11.0,15.0], come illustrato nella figura 5. Una parentesi chiusa, pertanto il valore incluso. Una parentesi significa che è escluso il valore, pertanto è anche possibile impostare [11.0,16.0). È inoltre possibile scegliere una versione secondaria (ad esempio 15.3) con il numero di build (ad esempio 15.0.26208.1).

Figura 5 destinazioni di installazione

Nella scheda dipendenze, eliminare tutti gli elementi. Nella scheda dei prerequisiti, fare clic sul pulsante di modifica e impostare il componente di Visual Studio 2017 minimo che richiede l'estensione. In questo esempio, è necessario solo l'editor di componenti di base di Visual Studio. In questa sezione è nuova per Visual Studio 2017 e il manifesto della versione 3, pertanto si applica solo alla versione 15.0 (vedere figura 6 Prerequisites6):

Figura 6 prerequisiti

Aggiungere un pacchetto per il progetto VSIX facendo clic con il nodo del progetto VSIX in Esplora soluzioni, quindi selezionare Aggiungi | Menu nuovo elemento per visualizzare la finestra di dialogo Aggiungi nuovo elemento. A questo punto, passare a Visual Studio c# quelli | Estendibilità | Nodo package VS, selezionare il modello di pacchetto di Visual Studio e denominarla MyPackage.cs. Aggiungere un comando per il pacchetto di ripetizione di azioni del passaggio precedente, ma la selezione di questa volta il modello di comando personalizzata. Denominare questa MyCommand1.cs.

Per seguire il principio di usando le dipendenze di minor numero di richieste, nel codice sorgente di MyPackage.cs e MyCommand1.cs, rimuovere gli spazi dei nomi (grigio) inutilizzati. Quindi fare doppio clic sul nodo del progetto VSIX in Esplora soluzioni e fare clic su Gestisci pacchetti NuGet per la voce di soluzione. Nella sezione installati, disinstallare tutti i pacchetti nell'ordine indicato di seguito:

Microsoft.VisualStudio.Shell.15.0
Microsoft.VisualStudio.Shell.Framework
Microsoft.VisualStudio.CoreUtility
Microsoft.VisualStudio.Imaging
Microsoft.VisualStudio.Shell.Interop.12.0
Microsoft.VisualStudio.Shell.Interop.11.0
Microsoft.VisualStudio.Shell.Interop.10.0
Microsoft.VisualStudio.Threading
Microsoft.VisualStudio.Shell.Interop.9.0
Microsoft.VisualStudio.Shell.Interop.8.0
Microsoft.VisualStudio.TextManager.Interop.8.0
Microsoft.VisualStudio.Shell.Interop
Microsoft.VisualStudio.TextManager.Interop
Microsoft.VisualStudio.Validation
Microsoft.VisualStudio.Utilities
Microsoft.VisualStudio.OLE.Interop

(Non disinstallare il pacchetto Microsoft.VSSDK.BuildTools, ovvero Visual Studio SDK).

Nel nodo di riferimenti del progetto in Esplora soluzioni, disinstallare tutti i riferimenti rimanenti (che non sono stati acquisiti come pacchetti NuGet) ad eccezione di sistema e System. Design. È ora possibile ricompilare la soluzione. Si riceverà errori di compilazione che deve essere risolto aggiungendo solo i riferimenti indicati nella figura 7.

Figura 7 riferimenti di Visual Studio 2012

Nome assembly	Versione dell'assembly	Sottocartella di SDK di Visual Studio 2012
Interop	7.1.40304.0	v 2.0
VisualStudio	7.1.40304.0	v 2.0
8.0	8.0.0.0	v 2.0
Microsoft.VisualStudio.Shell.Interop.9.0	9.0.0.0	v 2.0
Microsoft.VisualStudio.Shell.Interop.10.0	10.0.0.0	v 2.0
Microsoft.VisualStudio.Shell.Immutable.10.0	10.0.0.0	v 4.0
11.0	11.0.0.0	v 4.0

Purtroppo, Microsoft non fornisce un pacchetto NuGet ufficiale per 11.0 (è possibile trovare un VSSDK NuGet non ufficiale. Shell.11 del pacchetto, sebbene). Se si dispone di Visual Studio 2012 (è necessario se la versione minima supportata per l'estensione), è possibile ottenere dalla Global Assembly Cache come spiegato in precedenza. In alternativa, è possibile ottenere tutti gli assembly necessari per l'installazione di Visual Studio 2012 SDK (bit.ly/2rnGsfq) che fornisce loro nella versione 2.0 le sottocartelle e v 4.0 della cartella C:\Program Files (x86) \Microsoft Visual Studio 11.0\VSSDK\VisualStudioIntegration\Common\Assemblies. L'ultima colonna della tabella viene illustrata la sottocartella di Visual Studio 2012 SDK in cui è possibile trovare ogni assembly.

Per evitare dipendenze in pacchetti NuGet non ufficiali o in cartelle specifiche di locale (da un SDK di Visual Studio o da un'installazione di Visual Studio), l'approccio migliore consiste per ottenere gli assembly da ovunque e creare una cartella denominata VS2012Assemblies sotto la cartella radice del progetto. Copiare le DLL nella cartella, fare riferimento a esse da tale posizione (con il pulsante Sfoglia della finestra di dialogo Gestione riferimenti del progetto) e aggiungere la cartella VS2012Assemblies al controllo del codice sorgente, garantendo che le DLL vengano aggiunti a esso (in genere gli strumenti del controllo codice sorgente non aggiungono DLL per impostazione predefinita). In tal caso, a questo punto, gli assembly di Visual Studio necessari fanno parte del codice sorgente.

Per seguire il principio di non includere riferimenti ad assembly nel file VSIX e non anche nella cartella di output, selezionare ogni riferimento e nella finestra Proprietà verificare che la proprietà Copia localmente è impostata su False. A questo punto è possibile ricompilare la soluzione senza errori. In Esplora risorse passare alla cartella di output. Solo questi file devono essere generati: Extension. vsixmanifest, VSIXProjectVS2012_2017.dll, VSIXProjectVS2012_2017.pkgdef e VSIXProjectVS2012_2017.vsix.

Quando si compila il progetto, una delle destinazioni di MSBuild consente di distribuire l'estensione per l'istanza sperimentale di Visual Studio. Si tratta di un'istanza di Visual Studio che usa diverse cartelle e voci del Registro di sistema rispetto all'istanza normale, in modo che non si apporta la normale istanza inutilizzabile se si verificano problemi con l'estensione durante lo sviluppo. (È sempre possibile reimpostare l'istanza sperimentale, fare clic sul pulsante Start di Windows, digitare "Reimposta il" e l'esecuzione del comando "Ripristinare Visual Studio 2017 sperimentale istanza".) Se si passa alla scheda Debug della pagina delle proprietà del progetto, è possibile impostare il campo programma esterno di inizio del file devenv.exe di Visual Studio 2017. (È importante modificare questa opzione se l'aggiornamento, in quanto farebbe riferimento a una versione precedente di Visual Studio.) È inoltre possibile vedere che gli argomenti della riga di comando specificano "Exp" come suffisso radice (vedere figura 8 Debug sperimentale Instance8), in modo che l'istanza sperimentale viene usato anche per il debug.

Figura 8 istanza sperimentale di Debug

Fare clic su Debug | Voce di menu Debug di avvio e un nuovo Visual Studio istanza sarà avviato (si noti che la relativa didascalia indica "Istanza sperimentale"). Se si fa clic su strumenti | Richiama la voce di menu MyCommand1, verrà caricato il pacchetto, il comando verrà eseguito e verrà visualizzata una finestra di messaggio.

Se si desidera utilizzare 2017 di Visual Studio per eseguire il debug dell'estensione in una versione precedente di Visual Studio, è necessario apportare due modifiche: In primo luogo, poiché una volta creato l'estensione è distribuito in Visual Studio questa istanza sperimentale di quella il cui SDK è stato utilizzato per compilare il progetto, è necessario rimuovere il pacchetto NuGet Microsoft.VSSDK.BuildTools versione 15.0 e utilizzare versione 14.0 per Visual Studio 2015 o versione 12.0 per Visual Studio 2013. Per Visual Studio 2012 non è un pacchetto NuGet per VSDK, pertanto è necessario modificare il file con estensione csproj, quindi scegliere la variabile VSToolsPath il percorso di 11.0 di VSSDK (C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0), che deve essere installato separatamente. In secondo luogo, è necessario passare alla scheda Debug della pagina delle proprietà del progetto e impostare il campo programma esterno di inizio per la corrispondenza Common7\IDE\devenv.exe eseguibile.

Come è noto, molti progetti di Visual Studio supportano il round trip. Ovvero possono essere aperti e il debug con diverse versioni di Visual Studio senza subire modifiche. Non è il caso con i progetti di estendibilità "automatica." Tuttavia, con alcune masterizzazione di MSBuild e Visual Studio SDK, è possibile ottenere il, ma è sempre un approccio complesso.

Una volta completato lo sviluppo e debug, è possibile compilare l'estensione nella configurazione Release ed eseguirne il test sulle versioni di Visual Studio installate nelle istanze isolate nel computer di test. Se tutto va bene, è possibile pubblicare l'estensione di Visual Studio Marketplace.          

---

Carlos Quintero ha ricevuto il premio Microsoft Most Valuable Professional 14 volte, attualmente nella categoria di Visual Studio e tecnologie di sviluppo. Egli aiuta ad altri sviluppatori di creare estensioni per Visual Studio dal 2002, blog su di esso dal 2006 al visualstudioextensibility.com e più recente utilizzo di tweet su di esso: @VSExtensibility.

Grazie ai seguenti esperti per la revisione dell'articolo: Justin Clareburt, Alex Eyler e Mads Kristensen

---

Viene illustrato in questo articolo nel forum di MSDN Magazine