Sono consapevole che ci sono altre domande relative a NAnt e MSBuild su Stack Overflow, ma non sono riuscito a trovare un confronto diretto tra i due e quindi ecco la domanda.
Quando si dovrebbe scegliere NAnt su MSBuild? Quale è meglio per cosa? NAnt è più adatto a progetti domestici / open source e MSBuild per progetti di lavoro? Qual è l'esperienza con uno dei due?
Risposte:
Ho fatto un'indagine simile questa settimana. Ecco cosa sono stato in grado di determinare:
NAnt:
MSBuild:
Differenze soggettive: (YMMV)
Una delle principali attrattive di MSBuild per me (su piattaforme Windows) è che fa parte di .NET stesso. Ciò significa che qualsiasi macchina Windows aggiornata con Windows Update avrà MSBuild disponibile. Aggiungete a ciò il fatto che anche il compilatore C # fa parte di .NET stesso e che avete una piattaforma in grado di costruire progetti su macchine pulite. Non è necessario installare Visual Studio Behemoth. NAnt, d'altra parte, deve essere installato esplicitamente prima che una build possa essere attivata.
Solo per la cronaca, ho usato NMake, Make, Ant, Rake, NAnt e MSBuild su build non banali in passato (in quell'ordine). Il mio preferito è MSBuild, senza dubbio (e non lo favorisco perché "è quello che usa Visual Studio"). IMHO, è uno strumento di costruzione molto poco apprezzato.
Confronterei NAnt vs. MSBuild con la differenza tra programmazione procedurale e funzionale. NAnt è abbastanza semplice e ottieni quello che vedi. MSBuild d'altra parte richiede un po 'più di pensiero. La curva di apprendimento è più ripida. Ma una volta "capito", puoi fare alcune cose incredibili con esso.
Quindi consiglierei di guardare a MSBuild se anche graviti verso una programmazione funzionale o logica - se sei disposto a investire un po 'di tempo e sforzi prima di vedere risultati tangibili (ovviamente, credo anche fortemente che l'investimento alla fine ripaghi e tu può fare cose più potenti in modo più efficiente).
Personalmente, uso entrambi - per lo stesso progetto.
MSBuild è eccezionale nella creazione di soluzioni e progetti di Visual Studio: ecco perché è fatto.
Secondo me, NAnt è più facilmente modificabile a mano, in particolare se conosci già Ant. NAnt può chiamare MSBuild molto facilmente con NAntContrib. Quindi, creo a mano uno script NAnt per fare cose come copiare file compilati, ripulire ecc. E chiamare MSBuild per eseguire la parte "trasforma il mio codice sorgente C # in assembly".
Se vuoi un esempio di ciò, guarda il mio file di build Buffer di protocollo . (Non direi che è un favoloso script NAnt, ma fa il suo lavoro.)
NAnt ha più funzioni predefinite , ma MSBuild ha una struttura fondamentale molto migliore (elementi metadata rock) che rende molto più semplice la creazione di script riutilizzabili di MSBuild.
MSBuild richiede un po 'di tempo per capire, ma una volta fatto è molto bello.
Materiale didattico:
KISS = Usa MSBuild.
Perché aggiungere qualcos'altro al mix quando hai qualcosa che farà un lavoro ragionevole fuori dalla scatola? Quando MSBuild è arrivato, NAnt è morto. E Mono avrà un'implementazione di MSBuild, ( xbuild ).
DRY = Usa MSBuild.
Chiediti cosa vuoi da un sistema di build? Voglio un sistema di compilazione utilizzato anche dal mio IDE anziché mantenere due diverse configurazioni.
Personalmente, mi piacerebbe sentire alcuni veri argomenti per NAnt, perché non riesco proprio a pensare a nessuno che trattiene veramente l'acqua.
Una cosa che ho notato menzionare diversi poster è stata la modifica manuale dei file .csproj (o .vbproj, ecc.).
MSBuild consente la personalizzazione di questi file. * Proj mediante l'uso di file .user. Se ho un progetto chiamato MyCreativelyNamedProject.csproj e voglio personalizzare le attività di MSBuild al suo interno, posso creare un file chiamato MyCreativelyNamedProject.csproj.user e utilizzare CustomBeforeMicrosoftCommonTargets e CustomAfterMicrosoftCommonTargets per personalizzare quei file.
Inoltre, sia NAnt che MSBuild possono essere personalizzati in base al contenuto del cuore tramite attività personalizzate di MSBuild e tramite estensioni NantContrib.
Quindi, usare NAnt o MSBuild si riduce davvero alla familiarità:
Vale anche la pena aggiungere che MSBuild è praticamente garantito per funzionare con tutte le nuove versioni di .NET e Visual Studio non appena vengono rilasciate, mentre NAnt potrebbe avere qualche ritardo.
Uso entrambi in quanto i miei script NAnt chiamano MSBuild. Il mio motivo principale per stare con NAnt è l' isolamento . Lasciami spiegare perché ritengo che questo sia importante:
Aggiunta di dipendenze al progetto. Il file di build NAnt è estraneo a Visual Studio (nel mio caso lo considero un professionista), quindi Visual Studio non tenta di farci nulla. Le attività di MSBuild sono incorporate in modo da far parte della soluzione e possono fare riferimento ad altre attività di MSBuild. Ho ricevuto il codice sorgente da qualcun altro solo per scoprire che non potevo costruire, perché le attività della community di MSBuild non erano installate. Ciò che trovo particolarmente frustrante è che Visual Studio non avrebbe creato e generato un sacco di errori che mi hanno fatto perdere tempo nel debug. Ciò, nonostante il fatto che la build richiesta potesse essere andata avanti (ad esempio come build di debug) senza alcuni degli extra dell'attività di MSBuild. In breve: non posso aggiungere dipendenze al mio progetto se posso evitarlo .
Non mi fido di Visual Studio per quanto riguarda il suo team di sviluppo. Ciò risale ai primi giorni di Visual Studio quando avrebbe massacrato il mio HTML. Non uso ancora il designer per esempio (in una conferenza recentemente ho scoperto che i colleghi hanno fatto lo stesso). Ho scoperto che Visual Studio può rovinare dipendenze e numeri di versione nel file DLL (non posso replicarlo, ma è successo in un progetto in modo coerente e ha causato molto dolore e tempo perso). Ho fatto ricorso a una procedura di compilazione che utilizza Visual Studio per compilare solo in modalità debug. Per la produzione, utilizzo NAnt in modo da controllare tutto esternamente . Visual Studio non può più interferire più se costruisco usando NAnt.
PS: sono uno sviluppatore web e non faccio lo sviluppo di Windows Form.
Anche se non ho molta familiarità con MsBuild, ho l'impressione che alcune delle differenze chiave su entrambi i lati possano essere integrate da aggiunte:
Di recente ho dovuto costruire un progetto Silverlight a Nant. Ho scoperto che la vita sarebbe più semplice se lo facessi solo con MsBuild - ho finito per chiamare un'attività MsBuild da uno script Nant, quindi suppongo che non sia troppo fuori dall'ordinario mescolare e abbinare i due.
Oltre a ciò, suppongo che sarà una questione di preferenze personali - ovviamente puoi gestire alcune / la maggior parte delle funzionalità di MsBuild da Visual Studio, se è il tuo genere. Nant sembra più flessibile e più adatto se preferisci scrivere script a mano, e se vieni dal mondo Java probabilmente sarai a casa con esso.
Ho finito per usare entrambi. Durante la riprogettazione del nostro sistema di compilazione, stavo affrontando un problema difficile. Vale a dire, non riuscivo a liberarmi di .vcproj (e della famiglia) perché tutti usavamo VS per aggiornare i file, le impostazioni e le configurazioni del progetto. Quindi, senza un'enorme duplicazione e un processo soggetto a errori, non potremmo basare il nostro sistema di generazione su un nuovo set di file.
Per questo motivo, ho deciso di mantenere i file 'proj' di VS e usare MSBuild (sono file MSBuild, almeno VS2005 e VS2008 usano file di progetto MSBuild). Per tutto il resto (configurazione personalizzata, unit testing, packaging, preparazione della documentazione ...) ho usato NAnt.
Per un'integrazione continua, ho usato CruiseControl. Quindi avevamo script CC che attivavano i lavori NAnt, che per la costruzione usavano MSBuild.
Un'ultima nota: MSBuild NON supporta i progetti di installazione! Quindi sei bloccato con la chiamata a DevEnv.com o l'utilizzo diretto di Visual Studio. Questo è quello che ho finito per fare, ma ho disabilitato il progetto di installazione per impostazione predefinita da tutte le configurazioni della soluzione, dal momento che gli sviluppatori normalmente non avrebbero bisogno di costruirli e, se lo fanno, possono selezionare manualmente per costruirli.
Di recente sono passato da NAnt a MSBuild per la sua capacità di creare soluzioni VS. Comunque uso ancora NAnt di tanto in tanto.
Puoi anche dare un'occhiata alle attività della community di MSBuild che è come NAntContrib.
La documentazione e le esercitazioni disponibili per NAnt semplificano l'apprendimento degli script di build con NAnt. Dopo aver appreso NAnt e aver creato gli script di build, ho iniziato a tradurre quella conoscenza in MSBuild (ho fatto X in NAnt, come posso fare X in MSBuild?). La documentazione di Microsoft di solito presuppone un livello piuttosto elevato di conoscenza prima che sia utile.
Il motivo per passare da NAnt a MSBuild è perché MSBuild è più attuale. Sfortunatamente l'ultima versione di NAnt risale all'8 dicembre 2007, mentre MSBuild 4.0 (.NET 4.0) non è lontano. Sembra che il progetto NAnt sia morto.
Se trovi una buona documentazione per qualcuno che sta appena iniziando a imparare a creare script di compilazione usando MSBuild, salta NAnt e vai direttamente a MSBuild. Se mai NAnt uscisse con una nuova versione, prenderei in considerazione l'idea di restare con NAnt, ma ora sono in ritardo.
Usiamo entrambi. NAnt è responsabile di tutte le cose di "scripting", come la copia, la distribuzione su IIS , la creazione di pacchetti e MSBuild è responsabile della creazione della soluzione. Quindi possiamo evitare problemi con .NET 4.0 non supportato da una nuova versione di NAnt.
NAnt è anche più scalabile. Se vogliamo migrare gli script di distribuzione sui server di produzione, copiamo solo il file build e installiamo una versione corretta di .NET - nessun problema di Visual Studio con i file csproj :)
YDeliver di Manoj è un framework di build basato su PSake. Ha un ricco set di funzioni di libreria, capacità di definire flussi di lavoro e l'abbiamo usato per consegnare alla produzione oltre sei progetti aziendali.
Usalo insieme a TeamCity , CruiseControl o qualsiasi altra cosa che possa eseguire PowerShell .
Usiamo FlubuCore. È una libreria C # open source per la creazione di progetti e l'esecuzione di script di distribuzione utilizzando il codice C #.
Semplice esempio di come viene utilizzato flubu:
protected override void ConfigureTargets(ITaskContext session)
{
var compile = session.CreateTarget("compile")
.SetDescription("Compiles the solution.")
.AddTask(x => x.CompileSolutionTask())
.DependsOn("generate.commonassinfo");
}Puoi trovare maggiori informazioni su flubu e su come iniziare qui: scelta-per-costruire-strumento-msbuild-nant-o-qualcos'altro