Come posso organizzare una compilazione di soluzioni rapida e comoda in VS 2010? [chiuso]

La tecnica più efficace che conosco è quella di creare progetti di riferimento in assembly compilati, in modo che tu stia compilando solo il progetto su cui stai lavorando attualmente, e non una dozzina di altri.

Sì, perdi l'accesso al codice sorgente per quegli assembly, ma presumibilmente non cambieranno ogni cinque minuti, e presumibilmente qualcun altro sta lavorando su quel codice, non tu. Quando viene rilasciata una nuova revisione per quell'assemblaggio, puoi semplicemente copiarlo sul tuo progetto / soluzione.

Usa la funzione "scarica progetto" per scaricare progetti che non sei pronto per rimuovere dalla soluzione, ma non vuoi eseguirli / compilarli ogni volta che devi eseguire il debug o se vuoi fare periodicamente clic su "compila soluzione" "senza colpire il progetto lento.

Se stai usando un controllo di versione distribuito, potresti voler controllare frequentemente il tuo codice nel repository locale e amp; quindi avere un server di build personale pull & compilare il codice per tutto il giorno. Quindi, una volta completata la compilazione dell'intera soluzione, trasferisci il repository al repository centrale del team. Oppure potresti occasionalmente eseguire il backup del codice su una macchina separata con un server di build che non preleva da un repository. In entrambi i casi, questo presuppone che tu disponga di una macchina di riserva e di un server di build (TeamCity è buono e ha una versione gratuita)

Uso un ramdisk (40 MB) per accelerare le compilation. Prima di avviare Visual Studio, lancio uno script PowerShell che sostituisce le directory bin / e obj / con le giunzioni sul ramdisk.

param([Parameter(Mandatory=$true)][string] $folder)

function MoveToRamdisk($folder, $target){
    $folder.Delete($true);
    [IO.Directory]::CreateDirectory($target);
    cmd /c mklink /J $folder.FullName $target
}

function MoveRepositoryFolderToRamdisk($folder){
    $target = $folder.FullName.Replace('D:\Repositories\', 'E:\TempBinaries\');
    MoveToRamdisk $folder $target
}

dir $folder -Recurse -Include bin,obj | %{ MoveRepositoryFolderToRamdisk $_ }

MoveToRamdisk (Get-Item "${env:LocalAppData}\Microsoft\VisualStudio.0\ProjectAssemblies") 'E:\VsProjectAssemblies'

Quindi crea un collegamento a:

%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe "C:\Path\To\InitializeDevelopmentRamDisk.ps1" "D:\Repositories\Solution1"

Uso DataRAM RamDisk, è freeware e non esegue processi in background.

Uno dei modi migliori che ho trovato per aumentare il tempo di compilazione è non compilare in Visual Studio e utilizzare invece msbuild. Utilizzando msbuild il nostro sistema ERP (160 progetti) impiega meno di un minuto per la compilazione. Una linea di comando di esempio sarebbe:

cd c:\Solution\
c:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild ERP.sln /m:4 /v:m /property:Configuration=Release;ToolsVersion=2.0;CacheVersion=2.0 /fileLogger /fileLoggerParameters:Logfile=C:\ERP.log;Verbosity=minimal

dove / m: è il numero # di core cpu nel tuo computer, e / v: è la verbosità dell'output visualizzato sullo schermo (i flag sono: q [uiet], m [inimal], n [ormal], d [etailed] e diag [nostic]).

Un'altra tecnica di ottimizzazione che usiamo è l'uso di più soluzioni. La nostra soluzione ERP principale contiene tutti i progetti per il sistema. Disponiamo quindi di soluzioni individuali per ogni area di progetto, ad esempio contabilità, inventario, logistica, ecc. La soluzione grande viene utilizzata solo quando si esegue una compilazione completa del sistema (tramite msbuild). Quando lavoriamo in Visual Studio apriamo solo le sotto-soluzioni che contengono un sottoinsieme limitato di progetti che rendono le compilazioni molto più veloci.

Dipende dalla lingua che hai scelto. Per le app C ++, è facile: dividere la soluzione in componenti e crearli separatamente, quindi collegarli ai file lib (consiglio di copiare il file lib compilato in una singola directory per l'intero progetto e mantenere tutti gli header condivisi anche in una singola directory) - usa le Impostazioni del progetto per impostare il percorso verso questi). Ciò significa che non è necessario tenere l'intera cosa in un'unica soluzione. È possibile creare una nuova soluzione "master" per creare tutto da utilizzare in un server di compilazione, ma TBH è più semplice per ottenere che il server di compilazione costruisca ciascun componente uno dopo l'altro.

Per le app .NET, è leggermente diverso, una volta che hai delle dipendenze per gli assembly che cambiano, devi ricostruire tutto (o entrare nell'uso dei file dei criteri, o smettere di usare i numeri di versione :)). Microsoft consiglia di utilizzare un'unica soluzione enorme per tutto il progetto e dividerlo solo se diventa " troppo grande da caricare in Visual Studio ". Tuttavia, descrivono come utilizzare "soluzioni partizionate" e "soluzioni multiple": si desidera quest'ultima. questo è il più complesso in quanto richiede un'attenta gestione dei riferimenti. In breve, dovresti utilizzare solo riferimenti ai file e creare uno script per creare ciascuna soluzione a turno, nell'ordine corretto.

Spero che MS abbia aggiunto un "percorso di riferimento" come si può avere per le librerie C +, quindi è possibile costruirle e copiarle in un'area di staging pronta per fare riferimento, ma poiché VS utilizza percorsi relativi, diventa difficile a meno che tutti mette le loro soluzioni nella stessa struttura ad albero, anche se c'è una soluzione se si usa una lettera di unità mappata su una directory, VS ricade sull'uso di percorsi assoluti.

Per quanto riguarda la domanda numero 2 NCrunch o Test continuo posso aiutare. Entrambi eseguono build e test continuamente. Con NCrunch puoi controllare il modo in cui thread e core vengono utilizzati per la creazione e l'esecuzione di test e puoi controllare quale vuoi includere nella sessione corrente. Immagino che il test continuo abbia caratteristiche simili ma non l'ho provato.