Dovrei passare da nant a msbuild?

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

Domanda

Attualmente utilizzo nant, ccnet (cruise control), svn, mbunit.Utilizzo msbuild per eseguire la build sln solo perché era più semplice da sborsare.

Ci sono vantaggi nel trasferire l'intero script di compilazione in MSBuild?Devo essere in grado di eseguire test, test in stile watir, distribuzione xcopy.È più facile?

Aggiornamento:Qualche caratteristica interessante che mi potrebbe indurre a passare da nant a msbuild?

È stato utile?

Soluzione

Mi piace MSBuild.Uno dei motivi è che i file .csproj sono file msbuild e la creazione in VS è proprio come la creazione dalla riga di comando.Un altro motivo è il buon supporto di TeamCity, il server CI che utilizzo.Se inizi a utilizzare MSBuild e desideri eseguire operazioni più personalizzate nel processo di creazione, scarica il file Attività della community MSBuild.Ti danno un sacco di bei compiti extra.Non uso NAnt ormai da diversi anni e non me ne sono pentito.

Inoltre, come menziona Ruben, ci sono i Compiti della DSC attività su CodePlex.

Per un divertimento ancora maggiore, c'è il Pacchetto di estensione MSBuild su CodePlex, che include un'attività Twitter.

Altri suggerimenti

Il mio consiglio è esattamente l'opposto: evita MSBuild come la peste.NANT è molto più semplice da configurare per eseguire test automatici, distribuire in più ambienti di produzione, integrarsi con il cruisecontrol per un ambiente di ingresso, integrarsi con il controllo del codice sorgente.Abbiamo affrontato così tante difficoltà con TFS/MSBuild (usando TFSDeployer, script PowerShell personalizzati, ecc.) per fargli fare ciò che eravamo in grado di fare con NANT immediatamente.Non perdere tempo.

Il motivo più convincente per utilizzare MSBuild (almeno in .NET 3.5 e versioni successive) è che il motore di compilazione può essere creato contemporaneamente.

Ciò significa un'enorme velocità nelle tue build se hai più core/processori.

Prima della versione 3.5, MSBuild non eseguiva build parallele.

Sento che MSBuild e Nant sono abbastanza comparabili.Se utilizzi uno di questi, generalmente non passerei da uno all'altro a meno che non ci fosse una funzionalità interessante che mancava nel prodotto che avevi selezionato.

Personalmente utilizzo MSBuild per qualsiasi nuovo progetto, ma il tuo chilometraggio può variare.

Spero che aiuti!

Modificare: @ChanChan - @Jon afferma che Nant non crea applicazioni .NET 3.5.Questo potrebbe essere un motivo sufficiente per cambiarli o almeno usarli in parallelo.Dato che mi sono spostato maggiormente verso MSBuild, probabilmente non sono la persona più informata per evidenziare eventuali altri ostacoli con entrambe le tecnologie.

Modificare: Sembra che Nant ora crei applicazioni .NET 3.5.

NAnt è in circolazione da più tempo ed è un prodotto considerevolmente più maturo e anche IMO più facile da usare.C'è molto know-how della community a cui attingere ed è anche multipiattaforma, se sei interessato a creare app che possono essere eseguite su Mono, .NET e Silverlight.Fuori dagli schemi, fa molto di più di quanto fa MSBuild.Oh sì, e puoi chiamare MSBuild da NAnt (OK, da NAntContrib) :-)

Sul lato negativo, NAnt e il suo progetto gemello NAntContrib sembrano essere rimasti stagnanti, con l'aggiornamento più recente della fine del 2007.

Il vantaggio principale che vedo in MSBuild è che viene fornito con .NET Framework, quindi è un prodotto in meno da installare;e c'è uno sviluppo più attivo in corso (anche se in alcuni punti per raggiungere il vecchio NAnt).

Personalmente, trovo la sua sintassi un po' più difficile da imparare, ma sono sicuro che una continua esposizione a ti renderebbe le cose più facili.

Conclusione?Se stai lavorando con script NAnt esistenti, mantienili, non vale la pena di eseguire il porting.Se stai iniziando un nuovo progetto e ti senti avventuroso, prova MSBuild.

Siamo anche passati da nant a msbuild.Se la tua build è piuttosto standard, non avrai molti problemi a configurarla, ma se hai molte attività di build specifiche, dovrai scrivere attività di build ms personalizzate, poiché ci sono molte meno attività personalizzate per msbuild.

Se vuoi visualizzare risultati di compilazione ragionevoli, dovrai pasticciare con logger personalizzati, ecc.L'intera struttura del team non è matura come lo è Nant.

Ma il vero vantaggio è l'integrazione con il controllo del codice sorgente e i servizi di reporting TFS.Se non utilizzi TFS come sistema di controllo del codice sorgente, non ne vale la pena.

  • Non cambiare a meno che tu non abbia una ragione molto convincente (almeno).
  • NAnt è open source e se non lo fosse non sarei in grado di personalizzare il nostro sistema di compilazione, MSBuild no.
  • NAnt può facilmente eseguire MSBuild, non sono sicuro del contrario.
  • Gli script MSBuild sono già scritti per te se usi VS2005 o versioni successive (i file di progetto Sono File MSBuild.)
  • Se usi NAnt e usi VS per modificare file di progetto, impostazioni e configurazioni, dovrai scrivere uno strumento di conversione/sincronizzazione per aggiornare i tuoi file NAnt dai file di progetto VS.

@Brad Leach

Generalmente non passerei da uno all'altro a meno che non mancasse una caratteristica interessante

quali sono i motivi convincenti per utilizzare msbuild?ci sono dei contro?

Finora ho ottenuto un buon "no, non preoccuparti" dalla tua risposta.

Penso che siano relativamente comparabili sia nelle funzionalità che nella facilità d'uso.Semplicemente essendo basato su C#, trovo che sia più facile lavorare con msbuild rispetto a nants, anche se questo non è certo un motivo convincente per cambiare.

Cosa non sta facendo esattamente per te?O speri solo che ci sia qualche funzionalità interessante che potresti perdere?:)

Una cosa molto bella di C# è che se hai il framework .net, hai tutto il necessario per eseguire msbuild.Questo è fantastico quando lavori su team/progetti di grandi dimensioni e hai un turnover di persone/hardware.

Personalmente preferisco SCons ad entrambi :)

Il motivo principale per cui utilizzo ancora nAnt su msbuild per le mie build automatizzate è che ho un controllo più granulare sulle mie build.Poiché msbuild che utilizza csproj ha il suo file di build, tutto il codice sorgente in quel progetto viene compilato in un unico assembly.Il che mi fa avere molti progetti nella mia soluzione per progetti di grandi dimensioni in cui separo la logica.Bene, con nant, posso organizzare la mia build in cui posso compilare ciò che desidero in più assiemi da un progetto.

Questo percorso mi piace perché mi impedisce di avere troppi file di progetto nella mia soluzione.Posso avere un progetto con cartelle che dividono i livelli e quindi utilizzare nant per creare ciascun livello nel proprio assieme.

Tuttavia, utilizzo sia nant che msbuild insieme per alcune attività di compilazione, come la creazione di applicazioni WPF.È semplicemente molto più semplice compilare un'applicazione WPF con il target msbuild all'interno di nant.

Per concludere, il punto della mia risposta è che mi piace usarli fianco a fianco, ma quando uso msbuild in questa configurazione, di solito è per la compilazione diretta, non per eseguire attività di automazione della compilazione come copiare file in una directory, generare la documentazione della guida o, ad esempio, eseguendo i miei test unitari.

In realtà sto ancora cercando di risolvere questa domanda da solo, ma qui c'è un grande vantaggio per MSBuild:utilizzando lo stesso file di build per l'integrazione continua locale chiamando direttamente msbuild.exe, pur essendo in grado di utilizzare l'integrazione continua lato server di VSTS con lo stesso file di build (anche se molto probabilmente proprietà/impostazioni diverse).

cioè.rispetto al supporto di TeamCity per gli script MSBuild, VSTS soltanto supporta gli script MSBuild!In passato ho risolto il problema eseguendo NAnt da MSBuild;Ho visto altri raccomandare questa pratica così come il contrario, ma mi sembra semplicemente goffo, quindi cerco di non farlo se posso evitarlo.Pertanto, quando utilizzi "lo stack Microsoft completo" (VSTS e TFS), suggerirei semplicemente di attenersi agli script MSBuild.

Nant ha più funzionalità pronte all'uso, ma MSBuild ha una struttura fondamentale molto migliore (i metadati degli elementi sono eccezionali) che rende molto più semplice la creazione di script MSBuild riutilizzabili.

MSBuild richiede un po' di tempo per essere compreso, ma una volta fatto è molto carino.

Materiali didattici:

Non vedo alcun motivo per cambiare.MsBuild stesso ti blocca nel framework che stai utilizzando.Se usi NAnt, puoi usarlo su molti framework e sborsare a msbuild per svolgere effettivamente l'attività di creazione per te.

Sono un fan di NAnt in questo senso, perché ti disaccoppia un po' dalla struttura.

Ho creato un framework che inserisce convenzioni in build automatizzate e l'ho creato su NAnt.Si chiama UppercuT ed è il Build Framework incredibilmente facile da usare.

Costruzioni automatizzate facili quanto (1) nome della soluzione, (2) percorso di controllo del codice sorgente, (3) nome dell'azienda per la maggior parte dei progetti!

http://code.google.com/p/uppercut/

Alcune buone spiegazioni qui: UppercuT

L'integrazione di MSBuild con Visual Studio offre ai programmatori meno ostacoli nell'utilizzo del sistema di compilazione.Dipende principalmente dal fatto che devono solo andare su "Crea soluzione" e tutto funziona, invece di dover utilizzare passaggi di creazione personalizzati e altre cose simili o, peggio, costringere gli sviluppatori a creare lanciando una sorta di script esterno.

Ora, per lo più tendo a preferire MSBuild a NAnt perché è più semplice.Certo, NAnt ha molte più funzionalità, è più potente, ecc., ma può rapidamente sfuggire di mano.Se tu e i tuoi ingegneri di costruzione avete la disciplina necessaria per mantenere semplici gli script NAnt, allora va tutto bene.Tuttavia, ho visto troppi sistemi basati su NAnt andare a sud fino al punto in cui nessuno capisce più cosa sta facendo, e non esiste un modo reale per eseguirne il debug oltre a fare l'equivalente di un buon vecchio printf.Nel momento in cui inizi a utilizzare un'istruzione if/else o un ciclo for, è lì che, IMHO, inizia a puzzare.

D'altra parte, MSBuild ha una solida base basata sui metadati e una sintassi meno dettagliata.La sua semplicità (o mancanza di funzionalità...a seconda di come la vedi) ti costringe a scrivere la logica nel codice .NET tramite nuove attività, invece di scrivere la logica nel markup XML.Ciò incoraggia la riutilizzabilità e, soprattutto, ti consente di eseguire effettivamente il debug del tuo sistema di compilazione in un vero debugger.

L'unico problema con MSBuild è il bug non così occasionale (soprattutto nella prima versione) o il comportamento oscuro (anche se documentato).E, se questo è il genere di cose che ti dà davvero fastidio, essere legato a Microsoft.

Sono passato da NANT a MSBuild.Il progetto è in esecuzione in .Net 4.0.

La mia esperienza a Nant è stata positiva.Il progetto è morto.E quando è arrivato .Net 4.0, era giunto il momento di rivalutare il processo di creazione.

Dall'ultima volta che Nant è stato rilasciato, MSBuild ha fatto passi da gigante.A questo punto, MSBuild è la strada da percorrere.È facile da usare, ha molte estensioni.Ho riscritto le mie sceneggiature di Nant in un giorno e mezzo.Lo script MSBuild ha una dimensione pari a 1/3 degli script Nant.

Gran parte del lavoro nella sceneggiatura di Nant consisteva nell'allestire i diversi ambienti.In MsBuild/.Net 4.0 è integrato.

Utilizzo MSBuild accanto Nant, perché la versione corrente di Nant non può ancora compilare applicazioni .NET 3.5 (lo stesso valeva quando uscì per la prima volta .NET 2.0).

L'unico motivo che vedo per l'utilizzo di msbuild è se desideri utilizzare un server di build automatizzato come il cruise control.Se non hai intenzione di cambiare, lo lascerei stare.

Io uso Nant e lo adoro.Ho usato MSBuild e lo odiavo a causa di questi:

  1. Microsoft ti obbliga a seguire la propria procedura di compilazione che è così intrinseca alle loro azioni che almeno non sono riuscito a farla funzionare (ho dovuto compilare NET1.1 quindi ho dovuto mescolare Nant e MSbuild).So che puoi creare il tuo file MSBuild, ma ho pensato che fosse complesso da comprendere e mantenere.

  2. Gli ItemType per eseguire operazioni sui file sono semplicemente troppo difficili da seguire.Puoi fare in modo che Nant faccia le stesse identiche cose e in modo molto più semplice e diretto (ho dovuto creare un elenco ItemType e quindi passare alle operazioni sui file).

  3. In MsBuild devi creare la tua dll delle attività, in Nant puoi farlo oppure puoi incorporare il codice C# all'interno del tuo script, quindi è molto più semplice avanzare e creare semplicemente l'intero progetto.

  4. Nant funziona con Net1.1, MsBuild no.

  5. Per installare nant, posso anche decomprimerlo e localizzarlo nel mio repository per eseguirlo.Installare MsBuild è molto più difficile poiché dipende da molte cose da Visual Studio, ecc.(forse mi sbaglio qui, ma sembra essere la verità).

Beh, queste sono le mie opinioni...

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