Cosa dovrebbe andare in uno script di MSBuild tranne la compilazione?

Question

Attualmente sto cercando di configurare CruiseControl.net, quindi mi chiedo come suddividere i miei compiti.

In genere, voglio eseguire Unit Test (xUnit.net), Help File Generation (Sandcastle) e FxCop.

Ora mi chiedo solo se dovrei specificare un nuovo Target nella configurazione di msbuild (" Documentation ") e usarlo per eseguire SandCastle, o se appartiene a uno script separato? Inoltre, msbuild è pensato per costruire qualcosa, quindi immagino che ncover, xunit e FxCop non dovrebbero farne parte, o dovrebbero?

Qual è l'ambito previsto di msbuild?

Answer 1

Inserisci quasi tutto negli script di MSBuild, in modo che tu e altri sviluppatori possiate eseguire gli stessi passaggi localmente tramite la riga di comando. Altrimenti, quando qualcosa va storto con la build, devi eseguirne il debug sul server CC. Non è stata una bella esperienza di debug. Inoltre, desideri eseguire la build localmente prima di impegnarti per assicurarti che funzioni.

Le poche cose che non inserirò negli script di MSBuild sono:

• Aggiornamento SVN, poiché CC deve farlo comunque, e di solito non si desidera aggiornare quando si esegue una build locale. (Beh, faccio digito svn up & amp; & amp; msbuild abbastanza spesso, ma è così breve che non ho bisogno di inserirlo in uno script.)
• Creazione e pubblicazione di report di build; di nuovo questo è il dominio di CC, e non utile localmente

Per quanto riguarda la strutturazione dei tuoi file MSBuild, vorrai un " master " crea script che puoi utilizzare per creare tutto o solo alcuni target, ad esempio

• MSBuild / t: Build per creare semplicemente il codice in modo incrementale
• MSBuild / t: Rebuild per una ricostruzione pulita
• MSBuild / t: UnitTest per eseguire test unitari
• MSBuild per la scelta più frequente, ad esempio, equivalente a t:Build;UnitTest
• MSBuild / t: All per creare codice, documentazione e configurazione in modo pulito, eseguire tutti i test e impacchettare i risultati

Puoi anche aggiungere " scorciatoia " obiettivi per variazioni popolari.

Avere un singolo file di build principale non significa che tutto sia definito in questo singolo file; puoi includere altri file msbuild e / o chiamare msbuild ricorsivamente per organizzare la tua build. Ad esempio:

• Il file .proj principale dovrebbe essere relativamente semplice; principalmente, dovrebbe definire elementi specifici del progetto come l'elenco di soluzioni da costruire e sostituzioni specifiche del progetto
• Consenti al file master di includere un singolo file .targets che contenga target e proprietà predefinite; sforzarsi di mantenere questo progetto neutro e riutilizzabile.
• Se il file .targets diventa troppo grande, suddividilo in file separati, ad es. uno per il codice, uno per l'aiuto e la documentazione, uno per l'installazione e l'imballaggio. Consenti al tuo file .targets principale di includere quei sotto-file, in modo che il tuo file .proj debba ancora includere solo un file
• Allo stesso modo puoi dividere il file .proj master se necessario, ad es. per sottosistema.

Answer 2

Ho uno script di compilazione per singoli progetti e semplicemente li incatengo da un secondo file di compilazione durante la creazione di una suite ... ad esempio, il mio file di build protobuf-net gestisce il versioning (SVN) , compilation (MSBuild + NAnt per mono), testing (NUnit), packaging (zip), ecc. È il tuo processo di compilazione; fai quello che ti serve ;-p Se potessi, ad esempio, fare anche la distribuzione e la documentazione, se lo volessi.

Dipende anche da come lavori; se stai usando CruiseControl, potrebbe gestire gran parte di questo per te. Per quanto mi riguarda, mi piace una riga di comando " build " passo.