Vantaggi dell'utilizzo di MSBuild o NAnt rispetto all'esecuzione di DevEnv.exe dalla riga di comando

Question

Qualcuno può spiegare quali vantaggi ci sono nell'utilizzo di uno strumento come MSBuild (o NAnt) per creare una raccolta di progetti rispetto all'esecuzione di DevEnv.exe dalla riga di comando?

Un collega con cui avevo lavorato in passato aveva spiegato che (almeno con le versioni precedenti di Visual Studio) l'utilizzo di DevEnv.exe era molto più lento rispetto alle altre tecniche, ma non ho letto alcuna prova di ciò o se è ora un punto controverso ora che a partire dal 2005, Visual Studio utilizza MSBuild sotto il cofano.

So che un vantaggio dell'utilizzo di MSBuild ti consente di creare i tuoi progetti senza richiedere l'installazione di Visual Studio sulle macchine di compilazione, ma non ero sicuro che ce ne fossero altri.

Answer 1

Uno dei motivi è che nella costruzione di un prodotto c'è molto di più della semplice compilazione. Attività come la creazione di installazioni, l'aggiornamento dei numeri di versione, la creazione di impegni, la distribuzione dei pacchetti finali, ecc. Possono essere molto più semplici grazie a ciò che offrono questi strumenti (e le loro estensioni).

Mentre potresti fare tutto questo con script regolari, l'uso di NAnt o MSBuild ti offre un solido framework per fare tutto questo. C'è molto supporto da parte della comunità per entrambi, incluse attività aggiuntive che possono essere scaricate (come il Progetto di attività della community di MSBuild ). Inoltre, c'è supporto per loro in numerosi prodotti di terze parti e open source.

Se sei solo interessato alla compilazione (e non all'intero processo di compilazione), potresti scoprire che un vantaggio in termini di risparmio di MSBuild è supporto per la costruzione con più processori .

Answer 2

La risposta ovvia del mio team è che non tutti hanno installato Visual Studio , in particolare non installiamo Visual Studio sui nostri server build / CI.

Answer 3

Il motivo principale per l'utilizzo di uno strumento di compilazione esterno come NAnt o MsBuild è la capacità di automatizzare il processo di compilazione e quindi fornire un feedback continuo sullo stato del sistema. Inoltre possono essere usati per un sacco di cose oltre a un "puro" build ed è qui che inizi davvero a trarne valore, è estremamente utile poter costruire e testare la tua applicazione con un solo comando.

Puoi anche iniziare ad aggiungere elementi come la raccolta di metriche, il confezionamento dei file binari di rilascio e ogni sorta di cose eleganti come quella.

Answer 4

Per quanto riguarda C #, devenv.exe 2005 esegue il compilatore in-proc, il che può causare eccezioni di memoria insufficiente per soluzioni considerevoli. Msbuild ricorre all'avvio del processo csc.exe per ciascun progetto. I progetti che non vengono compilati con devenv / build funzionano bene con msbuild. Spero ti piaccia questo motivo.

Answer 5

Stiamo sperimentando il passaggio da DevEnv a uno strumento (Visual Build Pro) che utilizza MsBuild sotto il cofano e abbiamo ottenuto un riferimento "richiesto per l'assemblaggio" System.Drawing ... " errore per un progetto che non ne ha bisogno e che funziona bene in Visual Studio.

Answer 6

Abbiamo un grande sistema costituito da C #, C ++ gestito e semplici vecchi assembly / dll C ++ non gestiti. Esiste un codice C ++ che dipende dal codice C ++ gestito che dipende dal codice C # che dipende dal codice C ++ gestito che dipende dal semplice vecchio codice C ++ (wow!). Durante la configurazione del nostro ambiente di build automatizzato, alcuni anni fa, abbiamo scoperto che MSBuild.exe non gestiva correttamente tutte le dipendenze che abbiamo.

Lavorando con Microsoft siamo stati in grado di risolvere alcuni dei problemi, ma non tutti. Se la mia memoria mi serve, non potremmo mai ottenere gli assembly C # che dipendevano dalle DLL C ++ gestite da costruire. Quindi abbiamo finito per creare uno script di build personalizzato che chiamava devenv.exe dalla riga di comando e ha funzionato bene.

Ovviamente, era con VS2005, ora potrebbe essere risolto, ma lo script funziona ancora, quindi non abbiamo rivisto il problema.