MSBuild & # 8212; Utilizzare il file .csproj o rollare il proprio?

StackOverflow https://stackoverflow.com/questions/220075

Domanda

OK, quindi concedo prontamente che sono un principiante quando si tratta di integrazione continua.

Detto questo, sto cercando di impostare un ambiente CC.NET per educare me stesso, ma ho problemi a trovare le informazioni di cui ho bisogno per configurare la parte di build automatizzata.

A quanto ho capito, in C # il file .csproj prodotto da VS 2005 e in avanti è un file MSBuild valido. Per intenderci, sono stato in grado di integrare l'attività MSBuild in CC.NET utilizzando il file .csproj, ma ho alcuni problemi con questo:

  1. C'è molto da fare qui che non sono sicuro di aver davvero bisogno in un ambiente di build automatizzato.
  2. Non ho creato questo file. Non lo capisco e questo mi spaventa. ( Programmazione per coincidenza )
  3. La maggior parte di ciò che sta accadendo sembra essere astratta attraverso $(MSBuildToolsPath)\Microsoft.CSharp.targets
  4. Come risultato di 1, 2 e 3, la modifica del file per includere qualcosa come MbUnit sembra contorta e più difficile di quanto debba essere. La mia unica vera opzione è includerlo nella sezione AfterBuild , che mi sembra un po 'un hack.

Quindi, alcune domande per la gente di CC.NET, la gente di MSBuild e la gente di MbUnit.

  1. Quando si utilizza MSBuild, è consigliabile utilizzare il file .csproj generato da VS come file di build? O dovrei crearne uno mio?
  2. I test MbUnit dovrebbero far parte del file MSBuild o del file CC.NET? La mia ricerca sembra suggerire che appartengano al file MSBuild. In tal caso, devo creare un nuovo file .proj MSBuild e controllarlo su CVS oltre al file .csproj? Oppure l'attività MbUnit diventa parte del mio file .csproj?
  3. Simile alla domanda 2. Se aggiungo i test MbUnit al file MSBuild e finisco con il file .csproj, Target Name = " AfterBuild " è davvero la sezione in cui aggiungere tali informazioni ? Non dovrebbe esserci una sezione Target Name = " Test " ? L'uso del file .csproj generato da VS sembra impedire la seconda opzione.

So che c'è molto lì, ma la maggior parte di ciò che sono stato in grado di trovare online presuppone un certo livello di familiarità con questi argomenti che non ho - a meno che non mi sbagli, la curva di apprendimento per questa roba non è affatto una curva, è una funzione step. :)

Modifica 1: ho aggiornato il testo in modo che sia un po 'più conciso e per rispondere ad alcune domande persistenti che ho avuto con le risposte.

È stato utile?

Soluzione

Consiglierei di usare i file .csproj generati - in effetti per la produzione, penso che usare i file .sln generati sia una buona idea. Ho scoperto che guadagnerai utilizzando gli stessi file di soluzione degli sviluppatori.

Tenere presente che i file .sln in realtà non sono file di progetto msbuild validi, ma vengono trasformati in progetti msbuild dallo stesso msbuild quando vengono utilizzati come input. Tricky!

Ai fini dell'apprendimento, potresti voler registrare la build di un .csproj e passare a un'idea per quello che sta succedendo. MSBuild è un po 'più dichiarativo di Nant, quindi prenditi il ??tuo tempo e sperimenta un po'.

Infine, vorrei avvolgere i tuoi file .sln o .csproj in un progetto di script di compilazione continua con compiti di msbuild per costruire i tuoi progetti ed eseguire i test unitari insieme. In questo modo gli sviluppatori non devono eseguire il test unitario ogni volta che compilano, ma ogni volta che integrano il loro codice, i test unitari verranno eseguiti. E sì, assicurati che corrano veloci! Tutto ciò che richiede più di un secondo dovrebbe essere eseguito durante una build programmata (ogni notte?). Probabilmente sono meno test unitari e più test di integrazione scritti con un framework di test unitari se impiegano più di un secondo.

Modifica: alcune informazioni aggiuntive che ho trovato utili - l'utilizzo di MSBuild 3.5 ti consentirà di ottenere l'output di destinazione da un file .sln, mentre queste informazioni non vengono restituite in MSBuild 2.0 (anche se penso che dovrebbe funzionare per i file .csproj in entrambe le versioni). È possibile utilizzare l'output (i file creati) come input per il framework di test delle unità.

Altri suggerimenti

Lascia il file csproj ben solo (come dici, non lo capisci).

Crea il tuo file proj msbuild e chiama csproj (o sln) dal tuo file build principale tramite l'attività msbuild. Di 'al tuo server CI di creare il tuo file di build.

Questa separazione semplifica l'aggiunta di attività pre e post (test unitari, script SQL per prove di fumo, fxcop / altre analisi statiche, ecc.) e non si romperà l'ambiente di lavoro. Significa anche che puoi fare i tuoi obiettivi personalizzati in qualunque cosa tu voglia (msbuild / ant, ecc.) Dai un'occhiata a MSBuildContrib su codeplex per extra bontà.

Non è necessario lo stuido visivo sul server di compilazione (a meno che non si disponga di progetti di distribuzione, a meno che non sia stato modificato anche dall'ultima volta che ho guardato)

Crea il tuo file di progetto (tutto ciò che termina con * proj è considerato un file di progetto da MSBuild) e chiama la tua build da lì. In questo modo: 

<MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">

Nota che msbuild può anche creare .sln (file di soluzione) senza alcuna modifica, che di solito è più facile che avere un mucchio di file csproj ...

Uso sia NAnt che MSBuild. NAnt è stato aggiornato con NAntContrib in modo da ottenere msbuild taks. Potrei essere una configurazione temporanea, ma finora non ho riscontrato grossi problemi. Detto questo, inoltre, non creo un nuovo file csproj perché utilizzo lo stesso csproj / sln che utilizzo in VS2008. Creazione di progetti con script NAnt legacy notevolmente semplificati (abbiamo usato csc task).

Note:

  1. Se si utilizza il flusso di lavoro di Windows Fondamento nei tuoi progetti lo farai hanno grandi difficoltà a costruire tale progetto senza msbuild.
  2. Non installare VS.NET sul tuo computer di costruzione. Puoi usare Wix per creare l'installazione msi.
  3. @Franci Penov: eseguire test unitari DOVREBBE far parte di ogni build. Vuoi davvero aspettare fino a domani per trovare un bug? C'è una nota a margine: i test unitari dovrebbero essere eseguiti molto velocemente.

Personalmente penso che sia giusto andare con il file .csproj. Non c'è molto da fare lì dentro che non dovresti aggiungere te stesso se lanci il tuo progetto MSBuild.

Comunque, qualunque sia la strada che decidi di percorrere, ti consiglio comunque di non aggiungere MbUnit come parte del tuo passo di compilazione, ma di aggiungerlo come passaggio separato in CC.Net. L'esecuzione di test unitari dovrebbe far parte del ciclo giornaliero di CI; tuttavia, non dovrebbe far parte di ogni build.

OK, poche cose a cui fare attenzione. Il formato csproj è cambiato da VS2005 a VS2008. Inoltre, se utilizzi MSBuild, ricorda che non sarai in grado di creare file .vdproj (installazione); per questo è necessario devenv (l'eseguibile VS). Detto questo, puoi sempre creare un'attività MSBuild che chiama devenv e la costruisce per te.

Per quanto riguarda la tua domanda se creare il tuo file csproj o utilizzare quello creato da VS2005, suggerirei una via di mezzo: crea il tuo modello di progetto , che soddisfa le tue esigenze e lascia che VS si occupi del resto.

Va ??bene usare .csproj come input per msbuild. È possibile aggiungere manualmente attività per esso in csproj che verrà ignorato durante il completamento da VS. Ma se hai intenzione di fare cose non banali, è meglio creare script di msbuild separati. E possono essere referenziati dai file csproj. Hai dato un'occhiata a MS Build Server che fa parte di TFS? Si integra con SourceControl di TFS e potrebbe essere utilizzato per CI. I suoi file di progetto sono script msbuild.

  

Se ho usato nAnt, è necessario che VS sia installato sul server?   Intendevi "MSBuild"? No, non è necessariamente necessario installare VS per utilizzare msbuild con i file csproj.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top