Miglioramento dell'analisi del codice

Question

CA statico rende più lento il mutch di build solution. Nel mio caso> 2x più lento rispetto a CA. Possiamo disabilitarlo, ma è una cattiva decisione perdere il suo potere. Quindi cosa possiamo fare?

Prima consente di vedere come funziona CA.

Si crea una soluzione. Ad ogni progetto build dopo msbuild Compile target viene chiamato fxcopcmd.exe con percorsi agli assembly che devono essere analizzati. fxcopcmd. genera un log di CA xml che viene utilizzato da VS (o forse da un flusso di output). fxcopcmd.exe carica gli assembly (veloce) e analizza i suoi in modo sincrono, quindi viene caricata solo una CPU e 3 (nel mio caso) non stanno facendo nulla. Solo dopo che la CA è terminata, viene creato il prossimo progetto nella catena di dipendenze del progetto.

Quindi il punto debole in CA era che possiamo migliorarlo - per forzarlo a lavorare in parallelo per utilizzare tutte le CPU.

vedo tale soluzione

Per rendere fxcopcmd.exe falso che porterà i parametri da MSBUILD, ricordare e immediatamente riferire al msbuild che tutto è ok e non ci sono stati errori (tramite CA xml.log, o file riuscito, o forse stream ..). Quindi MSBUILD costruirà il prossimo progetto e in quel momento chiameremo real fxcopcmd.exe con parametri salvati ... se MSBUILD chiamerà fxcopcmd.exe sul prossimo progetto - chiameremo ancora una volta fxcopcmd.exe ... quindi ci sarà pochi processi che caricheranno tutte le CPU. Dopo il completamento di fxcopcmd.exe, possiamo chiamare il nostro target MSBUILD che chiamerà solo la destinazione CA da microsoft.common.targtets senza compilazione e il nostro falso fxcopcmd.exe segnalerà immediatamente i risultati (CA è terminata in quel momento e abbiamo il log) a MSBUILD-VS.

Cosa ne pensi? Questo accelera CA? Perché Microsoft non ha creato questo tipo di personale e utilizza solo una CPU in CA?

Answer 1

Ho chiesto una volta a similar question on Connect and got a reply directly from the team. Al vertice di ALM nel 2012 ho discusso l'argomento e ci sono stati una serie di ragioni (in nessun ordine particolare)

• Il motore di analisi del codice sarà molto probabilmente sostituito una volta Progetto Roslyn si integra nel prodotto di Visual Studio. Roslyn offrirà analisi in tempo reale (come Resharper) e la capacità di risolvere i problemi rilevati.
• Il motore richiede molta CPU e utilizza già più CPU, pertanto l'esecuzione di più istanze potrebbe non essere di aiuto come si sospetta. Inoltre, fxcop può essere molto intensivo di I/O (caricamento di assembly, pdb e altri file) che peggiorerebbe solo quando si caricano più istanze contemporaneamente.
• Il motore di compilazione deve accedere all'output di build. Per referenziare, ma anche per altre attività. Pertanto, è necessario sapere che i file non sono più in uso al termine di un'attività. Ad esempio, quando si aggiunge un'attività che IlMerges riunisce un numero di assiemi che rimuove quelli precedenti, è necessario accedere a tali file. Lo stesso vale per le semplici azioni move/package/etc.
• La possibilità di fallire la compilazione in anticipo quando viene rilevato un problema di analisi del codice (impostato su livello = errore) non funzionerà, dal momento che si stanno raccogliendo i risultati solo alla fine. Forse ti costringe a costruire tutto, solo per scoprire che non puoi usare il risultato finale.

Come si può vedere qui a this MSDN forum post, FxCop per sé già utilizza più thread e (almeno nelle regole forniti con 2010) ci sono alcuni problemi con la concorrenza già che ci causano di spegnere la concorrenza per FxCop in alcuni casi.Se si desidera FxCop utilizzare più (o meno) le discussioni, è possibile modificare il file fxcopcmd.exe.config:

<FxCopEngineSettings Version="1.32"> 
    <Engines> 
    <Engine Name="Introspection" Enabled="True"> 
     <!-- Change this number to use more (or fewer) threads --> 
     <Threading Count="1" /> 
     <EnableFlowAnalysis>True</EnableFlowAnalysis> 
    </Engine> 
    </Engines> 
</FxCopEngineSettings> 

Anche se il post sul forum menziona Visual Studio 2008, ho applicato questo per risolvere i problemi con il 2010 pure.

Un modo molto più semplice per rendere FxCop più efficiente è chiamarlo una volta dopo che tutti i progetti sono stati compilati. Ciò farà sì che carichi una volta tutti i simboli e gli assiemi di riferimento e consenta al motore di sfruttare al massimo il parallelismo. Ci sono alcuni problemi con questo anche quando si ha una soluzione che mescola più piattaforme di destinazione e cpu o quando si vogliono usare diversi file .rules per diversi progetti.

Oppure si potrebbe fare la stessa cosa che faccio, ovvero configurare FxCop per la soluzione locale, ma non impostarlo per l'esecuzione su ogni build. Quindi in Team Foundation Server Team Build (o qualsiasi altro build server che si può utilizzare), sovrascrivere la configurazione per FxCop per eseguire "Sempre". In questo modo non avrai alcun impatto sulle prestazioni mentre crei la tua soluzione locale. Permette comunque di eseguire l'analisi del codice per l'intera soluzione localmente (dalla voce di menu Analizza) e la build automatizzata può proteggerti dal controllo del codice con problemi.