Ar trebui să trec de la nant la msbuild?

În prezent folosesc nant, ccnet (cruise control), svn, mbunit. Eu folosesc msbuild pentru a-mi construi soarele doar pentru că era mai simplu să scot.

Există merite pentru a schimba tot scriptul meu de a construi la MSBuild? Trebuie să fie capabil să ruleze teste, teste de stil watir, implementare xcopy. Este mai ușor?

Actualizare: orice caracteristici convingătoare care ar determina trecerea de la nant la msbuild?

0
fr hi bn
webwesen a descoperit o gaură recursivă în acest univers, așezând o referință la o întrebare care nu a existat, nu ar trebui să fie altfel?
adăugat autor DevelopingChris, sursa
adăugat autor webwesen, sursa

8 răspunsuri

@Brad Leach

În general, nu aș schimba între ele dacă nu există o caracteristică convingătoare care lipsea

care sunt motivele convingatoare pentru utilizarea msbuild? sunt acolo contra?

Până acum, mă pricep destul de bine, "nu te deranja" de răspunsul tău.

0
adăugat

Eu folosesc MSBuild alături de Nant, deoarece versiunea curentă a lui Nant nu poate compila încă aplicații .NET 3.5 (aceeași a fost adevărată când .NET 2.0 a ieșit pentru prima dată).

0
adăugat

Îmi place MSBuild. Unul dintre motive este că fișierele .csproj sunt fișiere msbuild, iar construirea în VS este la fel ca și construirea la linia de comandă. Un alt motiv este suportul bun din partea TeamCity, care este serverul CI pe care l-am folosit. Dacă începeți să utilizați MSBuild și doriți să faceți mai multe lucruri personalizate în procesul dvs. de construire, obțineți MSBuild Community Tasks . Ele vă dau o grămadă de sarcini extraordinare. Nu am mai folosit NAnt de mai mulți ani și nu am regretat asta.

De asemenea, după cum menționează Ruben, există activități Sarcini SDC pe CodePlex.

Pentru mai multă distracție, pachetul de extensii MSBuild pe CodePlex , care include o sarcină de tip twitter.

0
adăugat
De asemenea, există sarcinile SDC. Și cartea Hashimi.
adăugat autor Ruben Bartelink, sursa

Cred că MSBuild și Nant sunt destul de comparabile. Dacă utilizați una dintre acestea, în general nu aș schimba între ele dacă nu există o caracteristică convingătoare care lipsea în produsul pe care l-ați selectat.

Eu personal folosesc MSBuild pentru orice proiect nou, dar kilometrajul dvs. poate varia.

Sper că vă ajută!

Edit: @ChanChan - @Jon mentions that Nant doesn't build .NET 3.5 applications. This may be enough of a reason to either change, or at least use them in parallel. As I've moved more towards MSBuild, I am probably not the most informed person to highlight any other showstoppers with either technology.

Edit: It appears Nant now builds .NET 3.5 Applications.

0
adăugat
NANT dezvoltă acum aplicații .net 3.5.
adăugat autor Sandeep Datta, sursa

Cred că sunt relativ comparabile atât în ​​ceea ce privește caracteristicile, cât și ușurința de utilizare. Doar de la a fi bazat pe C#, mi se pare mai usor sa lucrezi cu msbuild decat cu nants, desi nu este un motiv convingator pentru a comuta.

Ce nu trebuie să faci pentru tine? Sau sperați doar că există o caracteristică interesantă pe care ați putea să o pierdeți? :)

Un lucru foarte frumos despre C# este că, dacă aveți cadrul .net, aveți tot ce aveți nevoie pentru a rula msbuild. Acest lucru este fantastic atunci când lucrați la echipe mari/proiecte și aveți cifra de afaceri pentru oameni/hardware.

Personal prefer Skons peste ambele :)

0
adăugat
NAnt scris în C #
adăugat autor Artem Tikhomirov, sursa

Singurul motiv pentru care pot vedea pentru utilizarea msbuild este dacă doriți să utilizați un server automatizat de construcție cum ar fi controlul vitezei de croazieră. Dacă nu veți schimba, atunci l-aș lăsa în pace.

0
adăugat
cruisecontrol.net are sarcini pentru nant și msbuild din cutie
adăugat autor Hamish Smith, sursa

Motivul cel mai convingător de a utiliza MSBuild (cel puțin în .NET 3.5 și mai departe) - construirea motorului poate construi concomitent.

Aceasta înseamnă o viteză imensă în clădirile voastre în care aveți mai multe nuclee/procesoare.

Înainte de 3.5, MSBuild nu a construit paralel.

0
adăugat

Sfatul meu este exact opusul - Evitați MSBuild ca ciuma. NANT este mult mai ușor de configurat pentru a face testarea automată, a implementa în mai multe medii de producție, a integra cu cruisecontrol pentru un mediu de intrare, a se integra cu controlul sursei. Am trecut prin durere atât de mult cu TFS/MSBuild (Utilizând TFSDeployer, script-uri personalizate, etc.) pentru a face ca ceea ce am putut să facem cu NANT a ieșit din cutie. Nu pierdeți timpul.

0
adăugat
Am folosit atât pe scară largă, cât și pe discuri asemănătoare cu modul în care Microsoft a copiat în mod normal NAnt, MSBuild este mai ușor să dezvolte sarcini personalizate și, dacă combinați MSBuild Community Tasks cu MSBuild Extension Pack, aveți o gamă largă de instrumente. MSBuild câștigă pentru că este integrat în proiectele MS.
adăugat autor si618, sursa
MSBuild este diferit, dar la fel de ușor și puternic de utilizat ca Nant, mai ales cu extensia. De asemenea, este util să cunoașteți instrumentul care vă permite să începeți cu fișierul csproj .. și vă puteți scufunda într-o schimbare a modului cum funcționează constructorii pentru toți dezvoltatorii (prin schimbarea csproj-ului) și după ce a avut loc fiecare construcție. Este, de asemenea, un lucru mai puțin de instalat, și nant pare destul de mort în acest moment.
adăugat autor Andy, sursa
Si, te-ai gresit. 1) CustomTasks în NANT la fel de simplu cum devine - o subclasă a Task 2) NANT are NANTContrib, precum și mult mai mult sprijin comunitar decât MSBuild 3) Am integra NANT în proiectele mele MS scris un fișier batch pentru a rula NANT.exe. Aceasta este o operație de construcție, nu de rachete.
adăugat autor Jim, sursa
+1 MSBuild are loc, dar NAnt este mult mai puternic. Nu am găsit niciun motiv convingător pentru a comuta mai ales atunci când există o sarcină în NAntContrib.
adăugat autor Scott Saad, sursa