Perché dovrei usare MSBuild invece dei file della soluzione di Visual Studio?

Stiamo utilizzando TeamCity per l'integrazione continua e sta creando le nostre versioni tramite il file della soluzione (.sln). Ho usato Makefile in passato per vari sistemi ma mai msbuild (che ho sentito dire è simile a Makefiles + XML mashup). Ho visto molti post su come usare msbuild direttamente invece dei file della soluzione, ma non vedo una risposta molto chiara sul perché farlo.

Quindi, perché dovremmo preoccuparci di migrare dai file della soluzione a un 'makefile' di MSBuild? Abbiamo un paio di versioni che differiscono per un #define (build realizzate) ma per la maggior parte tutto funziona.

La preoccupazione maggiore è che ora dovremmo mantenere due sistemi quando aggiungiamo progetti / codice sorgente.

AGGIORNARE:

Le persone possono far luce sul ciclo di vita e interagire con i seguenti tre componenti?

1. Il file .sln di Visual Studio
2. I numerosi file .csproj a livello di progetto (di cui ho capito gli script msbuild "sub")
3. Lo script msbuild personalizzato

È sicuro dire che .sln e .csproj sono consumati / mantenuti come al solito all'interno della GUI dell'IDE di Visual Studio mentre lo script msbuild personalizzato è scritto a mano e di solito consuma il singolo .csproj già esistente "così com'è"? Questo è un modo in cui posso vedere ridurre la sovrapposizione / duplicazione nella manutenzione ...

Gradirei un po 'di luce su questo dall'esperienza operativa di altre persone

Il primo punto di fatto è che il file della soluzione diventa quasi magicamente un file MSBuild quando MSBuild lo esegue, il che è ciò che accade quando si crea la soluzione in Visual Studio. Inoltre, tutti quei file di progetto sono solo file msbuild gestiti da Visual Studio. In effetti, i file di progetto gestiscono la maggior parte del vero lavoro sporco qui, non importa se si sta costruendo da soluzioni o compilando da uno script msbuild personalizzato.

Usiamo anche TeamCity per creare e pubblicare applicazioni e in genere finiremo con script msbuild personalizzati per la maggior parte dei progetti. Il ruolo svolto da questi script, il che non è molto semplice con un file di soluzione, è la creazione di pacchetti per la distribuzione o la distribuzione. In genere, questi script gestiscono alcuni aspetti più operativi delle cose, come la creazione del progetto Web in una cartella specifica o la copia nelle configurazioni in esecuzione rispetto alle configurazioni di sviluppo. Il pesante sollevamento tende a essere gestito nei file di progetto stessi: lo script di build fa solo riferimento a quelli, non proviamo a ricreare quella ruota. Nel complesso funziona benissimo e non è un codice molto duplicato.

Il makefile per msbuild è il file .sln (o file vcproj).

Una tipica riga di comando di msbuild sarebbe simile a:

msbuild /p:Configuration=Release BigProject.sln

Il punto di usare msbuild è che puoi script e automatizzare il processo di compilazione. Che tu ne fossi a conoscenza o no, TeamCity utilizza da sempre msbuild.

Consentitemi di offrire la mia opinione su questa domanda.

Anche se puoi certamente usare il tuo file .SLN come "processo di compilazione", il file in sé non costituisce un processo di compilazione. Il file Solution è in realtà solo una parte di Visual Studio e viene utilizzato per lo sviluppo. Ma Visual Studio è solo una parte del processo di compilazione e rilascio. Non puoi fare affidamento su Soluzioni per gestire la tua build e le Soluzioni certamente non offrono una situazione di build scalabile.

L'intero scopo di stabilire un processo di compilazione è creare build affidabili. Vale a dire, il processo di compilazione è così affidabile che, indipendentemente dalla configurazione della build, otterrai un output di build prevedibile. Ogni volta, ogni macchina. Il risultato di una build prevedibile e affidabile è che il processo di test, distribuzione e rilascio può quindi essere altamente automatizzato, riducendo ulteriormente il rischio di errore umano.

Stabilire un processo di compilazione richiede un investimento, ma in alcuni casi è necessario l'investimento. Ecco alcuni fattori che favoriscono un processo msbuild:

• Il prodotto ha più team (interfunzionali o meno) che lavorano nello stesso progetto team
• La tua organizzazione ha un solo progetto di gruppo (dovrebbe essere il caso del 99% dei negozi tradizionali, anche quelli con oltre 200 sviluppatori)
• Hai più di 20 progetti che devono essere costruiti, alcuni dei quali dipendono da altri e sono gestiti da diversi team
• Il prodotto incorpora più tecnologie .NET (C #, C ++, VB, F #, ASP.NET, ecc.) O anche tecnologie non. NET (Grunt, nodo, npm, Java, ecc.)
• Il prodotto ha dipendenze dei pesi massimi o è costruito sopra una piattaforma dei pesi massimi. SharePoint, ad esempio

Vorrei fare un esempio per espandere il mio ultimo punto. La mia attuale azienda si occupa dello sviluppo di SharePoint. Lo sviluppo di SharePoint richiede almeno l'installazione di SharePoint Foundation per eseguire build su progetti SharePoint. Parlando in termini di un server di build leggero, è del tutto impraticabile richiedere che il server di build abbia installato SharePoint. SharePoint non è solo una bestia con requisiti elevati, ma avrebbe gravi conseguenze sulle prestazioni di una build e le build dovrebbero essere il più veloci e snelle possibile. Sfruttando MSBuild mi consente di eliminare questo requisito di installazione sul server di compilazione. In effetti, il nostro server di build non ha requisiti di installazione diversi da .NET framework (richiesto da MSBuild) e Node.

Come riferimento, consiglierei di leggere questo libro di Sayed Ibrahim Hashimi: http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1?ie=UTF8&qid=1412014650&sr= 8-1-fkmr0 & parole chiave = msbuild + affidabile + build

Questa è esattamente la domanda che mi sono posto alcuni mesi fa! Abbiamo organizzato tutto perfettamente:

• File di soluzione ben posizionato nella radice dei repository
• Crea passaggi configurati in Teamcity, ad esempio
  • Ripristina pacchetti NuGet
  • Crea soluzione
  • Esegui test unità
  • Configurare l'ambiente di test di integrazione
  • Esegui test di integrazione
  • Abbattere l'ambiente di test di integrazione
  • Creare un pacchetto di distribuzione
  • Crea script di migrazione

E poi, quando si tratta di riproducibilità, è diventato evidente che questo ha ottenuto un punteggio basso. Quando lasci che TeamCity sia il tuo script di build, diventa difficile riprodurre risultati simili, affidabili, sulla tua macchina di sviluppo.

Quando si dispone di uno script di compilazione, lo script di compilazione conosce tutto ciò che deve essere fatto e ha tutte le variabili in atto. Quando si utilizza un server CI come script di compilazione e si verificano alcuni problemi, come un test complesso che non riesce o che è necessario creare un pacchetto di distribuzione manualmente (come nel mio esempio), è necessario mettere insieme tutti i passaggi della compilazione manualmente.

Quindi, in breve , perché uno script di compilazione (MS)? Perché finirai per avere più requisiti quando si tratta della tua build. Probabilmente vuoi eseguire alcuni test e generare alcuni artefatti da quello. Probabilmente vuoi fare distribuzioni. E quando tutto ciò che vuoi deve essere eseguibile, sia che si trovi su un server di build o sul tuo computer, non può finire da nessuna parte se non in uno script di build.