2014-10-12 20 views
6

Per la mia tesi di master sto costruendo un plug-in di Visual Studio che dovrebbe eseguire alcune analisi del codice della soluzione aperta corrente. Per farlo ho deciso di provare a usare Roslyn, usando lo corresponding nuget package.Utilizzare Roslyn MSBuildWorkspace con Visual Studio 2013

Tutto funziona bene (SyntaxTree per la navigazione del codice, ...) fino a quando ho provato ad usare MSBuildWorkspace.Create(). Questa ultima chiamata fa sì che la seguente eccezione:

Impossibile caricare il file o l'assembly 'Microsoft. Build, Version = 14.0.0.0, Culture = neutro, PublicKeyToken = b03f5f7f11d50a3a 'o una delle sue dipendenze . Il sistema non riesce a trovare il file specificato . ":" Microsoft.Build, Version = 14.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a

ho trovato questi due post:

da cui ho capito che ho bisogno degli strumenti di MSBuild per Visual Studio 14, che si trova nel rel stato iso.

Non voglio installare Visual Studio 14 completo, anche perché il plug-in che sto scrivendo deve essere eseguito in Visual Studio 2013. Dai due post sembra che sia possibile installare solo questa parte di VS 14.

La mia domanda è in realtà: se installo MSBuild Tools per Visual Studio 14 cosa succederà con tutti gli altri progetti di Visual Studio su cui sto lavorando attualmente? Al momento usano lo strumento MSBuild di Visual Studio 2013. È possibile utilizzarlo ancora?

Aggiornamento

Quello che sto acctually cercando di ottenere è quello di trovare se un dato metodo ha riferimenti all'interno del progetto. L'idea era di procedere come in this post.

+0

I sistemi diagnostici che si integrano con VS saranno accoppiati a VS. Sembra che Roslyn ora richieda VS 14 e l'anteprima VS 13 non è più supportata. È certamente possibile installare più versioni di VS side-by-side ma poiché è CTP, c'è sempre qualcosa che può andare storto. Il solito standard: "Sebbene questi CTP siano pensati per essere installati fianco a fianco insieme alle versioni precedenti di Visual Studio, la completa compatibilità di ogni CTP non è garantita." –

+0

Il fatto che io possa installare versioni VS affiancate diverse (con la solita caldaia standard) è noto a me. Il fatto è che alla fine il plugin dovrebbe funzionare con Wisual Studio 2013. Se, per lavorare con VS 2013, ho bisogno di installare MSBuild di VS 2014 che non è un problema finché i "normali progetti VS 2013" continueranno a essere utilizzati il vecchio MSBuild. – Lando

+1

Come dice Jason, dovresti usare VisualStudioWorkspace e non avrai nessuno di questi problemi. Poiché VisualStudioWorkspace non è documentato, ho scritto una guida ai vari spazi di lavoro qui: http://joshvarty.wordpress.com/2014/09/12/learn-roslyn-now-part-6-working-with-workspaces/ – JoshVarty

risposta

1

Questo è entirely possible, ma per niente facile.

È necessario assicurarsi di caricare sempre la versione degli assembly Roslyn nella versione VS scelta, rimuovendo gli assiemi dal VSIX e gestendo AssemblyResolve per assicurarsi di ottenere quelli giusti.
Potete vedere il mio codice che fa esattamente questo here, e si può leggere di più su questa tecnica in my blog post

Si noti che se avete bisogno di [Export] eventuali interfacce definite nelle assemblee Roslyn, questo non funzionerà affatto, poiché MEF proverà a caricarli prima di aggiungere il gestore. (a meno che non si aggiunga un inizializzatore del modulo a mano in ildasm)

La parte più difficile è che è necessario limitarsi all'intersezione delle API in ogni versione Roslyn che si desidera supportare.

+0

Faccio una smorfia vedendo quel codice e non posso raccomandarlo. Hooking AssemblyResolve è un modo disordinato per farlo - e immagina se due estensioni provano a farlo, ognuno cercando di caricare diverse versioni di Roslyn! Riconosco che potrebbero non essere stati disponibili nel tuo caso particolare, ma vorrei anche inserire un commento in quel codice per indicare che se qualcuno ha bisogno di un reindirizzamento vincolante o qualcosa del genere, non dovrebbe farlo e utilizzare un meccanismo supportato. –

+0

@JasonMalinowski: il punto di quel codice è caricare la versione di Roslyn all'interno di VS; caricare una versione diversa di Roslyn è una cattiva idea. Non conosco alcuna alternativa al mio codice per far funzionare una singola DLL con VS2013 e Dev14. – SLaks

+0

Ma cosa succede quando due persone lo fanno? :-) –

3

È possibile eseguire il forkbase di codice di Roslyn e compilare con MSBUILD12 definito, che dovrebbe comunque funzionare, anche se in realtà non testiamo molto.

6

Quando dici che stai creando un plug-in per Visual Studio, se tutto quello che ti interessa è ottenere lo spazio di lavoro per la soluzione attualmente aperta (cioè il codice che l'utente sta modificando), non dovresti usare MSBuildWorkspace, davvero mai . Questo è un tipo per caricare le cose all'esterno di di Visual Studio. Cosa puoi fare se ti trovi nel prodotto è MEF [Importa] Microsoft.VisualStudio.LanguageServices.VisualStudioWorkspace. Ciò ti dà accesso in tempo reale a ciò che l'utente ha aperto ed evita di eseguire interamente MSBuild.

Nota, devi ancora stare attento alla scelta degli assembly di riferimento che costruisci contro: se usi i pacchetti NuGet più recenti che non funzioneranno poiché quelli saranno diversi nella versione (e anche nelle API - noi cambiato un sacco di cose) rispetto a quello che era nell'ultima anteprima di Visual Studio 2013.

+0

Utilizzando VisualStudioWorspace è possibile quindi ottenere il progetto e richiamare 'project.GetCompilationAsync(). Risultato;'? – Lando

+1

(Per favore, per capire meglio questa domanda, vedere l'aggiornamento della mia domanda originale con l'obiettivo Ultimi che sto cercando di raggiungere.) – Lando

+0

@Lando: Non usare '.Result'; usa 'attendi'. (altrimenti, si avranno deadlock e altri problemi) – SLaks

5

Il problema è che (sfortunatamente) gli assembly nei pacchetti pubblici di Roslyn nuget sono stati compilati con una versione più recente di MSBuild rispetto a ciò che si desidera.

Tuttavia, è abbastanza semplice da risolvere in modo che funzioni su MSBuild 4.0 (VS2012 +). Io li ho fornito con un PR con la correzione (a https://roslyn.codeplex.com/workitem/405), ma anche pubblicato un pacchetto di NuGet chiamato DesktopAnalysis che contiene tutte le assemblee per fare l'analisi di codice C#, che i lavori su VS2012 + (MSBuild 4.0+): https://www.nuget.org/packages/DesktopAnalysis

Basta fare un install-package DesktopAnalysis -pre invece e il gioco è fatto. Gli assembly sono uguali, il codice è lo stesso, ecc.

Lo sto utilizzando per fornire un'estensione di migrazione del codice che funzioni da VS2013 fino a VS2015 Preview.

Problemi correlati