Tidak atau MSBuild, mana yang harus dipilih dan kapan?


160

Saya sadar ada pertanyaan lain yang terkait dengan NAnt dan MSBuild di Stack Overflow, tapi saya tidak bisa menemukan perbandingan langsung antara keduanya dan jadi inilah pertanyaannya.

Kapan seseorang harus memilih TIDAK daripada MSBuild? Mana yang lebih baik untuk apa? Apakah NAnt lebih cocok untuk proyek rumah / sumber terbuka dan MSBuild untuk proyek kerja? Apa pengalaman dengan salah satu dari keduanya?

Jawaban:


97

Saya sudah melakukan penyelidikan serupa minggu ini. Inilah yang saya dapat menentukan:

TIDAK:

  • Cross-platform (mendukung Linux / Mono). Mungkin berguna untuk menginstal situs web ke beberapa target (yaitu, Linux Apache dan Windows IIS), misalnya.
  • 95% mirip dalam sintaksis dengan Ant (mudah diambil oleh pengguna Ant atau pembuat Java saat ini)
  • Integrasi dengan NUnit untuk menjalankan unit test sebagai bagian dari build, dan dengan NDoc untuk dokumentasi produksi.

MSBuild:

  • Built-in ke .NET.
  • Terintegrasi dengan Visual Studio
  • Mudah untuk memulai dengan MSBuild di Visual Studio - semuanya ada di belakang layar. Jika Anda ingin lebih dalam, Anda dapat mengedit file dengan tangan.

Perbedaan Subyektif: (YMMV)

  • Dokumentasi NAnt sedikit lebih mudah. Misalnya, Referensi Tugas MSBuild mencantumkan "Tugas Csc - Menjelaskan tugas Csc dan parameternya." (Terima kasih atas "bantuan"?), Vs Referensi Tugas NAnt "csc - Mengkompilasi program C #." UPDATE: Saya perhatikan dokumentasi MSBuild telah ditingkatkan dan jauh lebih baik sekarang (mungkin setara dengan NAnt).
  • Tidak mudah untuk mengetahui cara mengedit sumber skrip build (*. * File proj) langsung dari dalam Visual Studio. Dengan NAnt saya hanya punya Visual Studio memperlakukan skrip .build sebagai file XML.
  • Rupanya, di Visual Studio, Proyek Aplikasi Web tidak mendapatkan file proj *. * Secara default, jadi saya mengalami kesulitan besar mencari tahu bagaimana bahkan membuat MSBuild berjalan di tambang untuk membuat skrip penerapan.
  • NAnt tidak terintegrasi dengan Visual Studio dan harus ditambahkan, baik dengan Add-In, atau sebagai "Alat Eksternal". Ini agak merepotkan.
  • (Sunting :) Salah satu rekan kerja saya membawa ini - jika Anda ingin menyiapkan mesin build menggunakan CruiseControl untuk integrasi berkelanjutan, CruiseControl terintegrasi dengan NAnt dengan baik di luar kotak. PEMBARUAN: CruiseControl juga memiliki tugas MSBuild .
  • Silakan lihat komentar di bawah ini untuk diskusi penuh dan terbaru tentang perbedaan subjektif.

Anda dapat mengedit file .proj tetapi setelah Anda membongkar proyek (harus ada opsi "Bongkar" dalam menu konteks untuk proyek)
Yordan Pavlov

18
@Yordan: atau hanya menempatkan kustomisasi Anda ke file .build yang terpisah (atau apa pun) dan impor + jalankan itu dari file .csproj Anda. Maka Anda hanya perlu mengedit .csproj sekali, dan dapat menambahkan file .build ke solusi Anda. Klik dua kali dan Anda sedang mengedit seperti file lainnya. Dapat memetakan file .build ke editor XML di opsi Anda.
Kent Boogaart

9
Ada tugas MSBuild CCNet - Detailnya dapat ditemukan di: confluence.public.thoughtworks.org/display/CCNET/MsBuild+Task
Gavin Miller

2
Perlu dicatat bahwa Anda tidak perlu memodifikasi file .csproj sendiri. Anda dapat menggunakan file MyProject.csproj.user untuk melakukan modifikasi tersebut, membuat file .csproj Anda bersih dan murni. MSBuild tahu untuk mencari file-file .user tersebut dan akan mengimpornya ke dalam proses build secara otomatis. Lihat: ahmed0192.blogspot.com/2006/11/…
CleverPatrick

3
@CleverHuman, bukankah file .user itu biasanya berisi mod khusus pengguna untuk proyek yang biasanya tidak Anda setujui bersama dengan sisa proyek? Saya telah menggunakan saran Kent selama bertahun-tahun dan itu bekerja dengan sangat baik. Anda mod file PROJ sekali untuk memasukkan file PROJ kedua, lalu tambahkan file PROJ kedua untuk proyek Anda. Sejak saat itu, Anda dapat dengan mudah menyesuaikan file PROJ kedua tanpa harus melalui proses Bongkar / muat ulang. Saya cenderung condong ke arah MSBuild hanya karena alasan ini.
DarinH

77

Salah satu kelebihan utama dari MSBuild untuk saya (pada platform Windows) adalah bahwa ia datang sebagai bagian dari .NET itu sendiri. Itu berarti bahwa setiap mesin Windows yang mutakhir dengan Pembaruan Windows akan memiliki MSBuild tersedia. Tambahkan ke fakta ini bahwa kompiler C # juga merupakan bagian dari .NET itu sendiri dan Anda memiliki platform yang dapat membangun proyek pada mesin bersih. Tidak perlu menginstal raksasa Visual Studio. NAnt, di sisi lain, harus diinstal secara eksplisit sebelum membangun dapat dipicu.

Sebagai catatan, saya telah menggunakan NMake, Make, Ant, Rake, NAnt dan MSBuild pada build non-sepele di masa lalu (dalam urutan itu). Favorit saya adalah MSBuild, tangan ke bawah (dan saya tidak mendukungnya karena "itulah yang digunakan Visual Studio"). IMHO, ini adalah alat build yang sangat tidak dihargai.

Saya akan membandingkan NAnt vs MSBuild dengan perbedaan antara pemrograman prosedural dan fungsional. Tidak cukup mudah dan Anda-mendapatkan-apa-yang-Anda lihat. MSBuild di sisi lain membutuhkan sedikit lebih banyak pemikiran. Kurva pembelajaran lebih curam. Tetapi begitu Anda "mengerti", Anda dapat melakukan beberapa hal menakjubkan dengannya.

Jadi saya akan merekomendasikan melihat MSBuild jika Anda juga tertarik pada pemrograman gaya fungsional atau logis - jika Anda bersedia menginvestasikan sedikit waktu dan usaha sebelum melihat hasil yang nyata (tentu saja, saya juga sangat percaya bahwa investasi akhirnya terbayar dan Anda dapat melakukan hal yang lebih kuat dengan lebih efisien).


11
Wow! Tidak tahu bahwa MSBuild datang bersama runtime. Itu sangat keren dan saya pasti bisa melihat manfaatnya di sana. Namun, saya tidak mengerti perbandingan antara fungsional / prosedural. Akan menarik untuk mendengar apa yang membuat MSBuild jauh lebih kuat ketika seseorang "mendapatkannya".
Scott Saad

2
Msbuild sebenarnya memiliki sejumlah dependensi pada file dari berbagai sdks yang hanya menjadi jelas selama doa target tertentu. Jadi, meskipun msbuild tersedia di luar kotak, itu mungkin tidak berjalan.
Sam Shiles

6
satu hal yang harus ditambahkan: tidak hanya mungkin untuk memanggil .NET assemblies dari dalam msbuild yang memberikan satu akses ke banyak fungsi yang sangat berguna (mis. Segala sesuatu di Systme.IO.Path dapat berguna dalam membangun skrip) , juga dimungkinkan untuk menulis kode C # biasa dalam file msbuild dan menjalankannya. Yang hanya aswesome. msdn.microsoft.com/en-us/library/dd722601.aspx Dan jika semuanya menjadi terlalu rumit, menulis tugas kustom juga mudah.
stijn

1
Dari Wikipedia: " MSBuild sebelumnya dibundel dengan .NET Framework; dimulai dengan Visual Studio 2013, namun, itu dibundel dengan Visual Studio."
DavidRR

MSBuild (Microsoft Build Tools 2013) juga dapat diunduh secara independen dari Visual Studio 2013 di sini .
DavidRR

45

Secara pribadi, saya menggunakan keduanya - untuk proyek yang sama.

MSBuild hebat dalam membangun solusi dan proyek Visual Studio - itulah tujuan dibuatnya.

NAnt lebih mudah diedit dengan tangan, menurut saya - terutama jika Anda sudah tahu Ant. NAnt dapat memanggil MSBuild dengan sangat mudah dengan NAntContrib. Jadi, saya membuat skrip NAnt untuk melakukan hal-hal seperti menyalin file yang dibuat, membersihkan dll - dan memanggil MSBuild untuk melakukan bagian "ubah kode sumber C # saya menjadi rakitan" yang sebenarnya.

Jika Anda menginginkan contohnya, lihat file Buffer Protocol saya . (Saya tidak akan mengklaim itu adalah skrip NAnt yang luar biasa, tetapi ini berfungsi dengan baik.)


1
Dan itu mendukung Mono. Dukungan MSBuild Mono jelek.
Mehrdad Afshari

@Mehrdad: Ya, pada titik tertentu saya benar-benar harus mencoba untuk membuat Protokol Buffer untuk dikompilasi pada Mono ... saat ini ada bug gmcs yang menghentikannya bekerja :( Idenya adalah selalu pada akhirnya akan bekerja pada Mono.
Jon Skeet

1
Guys, mono menggunakan XBuild dan mudah untuk port MSBuild ke XBuild. Lihat ini: mono-project.com/Porting_MSBuild_Projects_To_XBuild .
fyasar

20

NAnt memiliki lebih banyak fitur di luar kotak, tetapi MSBuild memiliki struktur dasar yang jauh lebih baik (item metadata rocks) yang membuatnya lebih mudah untuk membangun skrip MSBuild yang dapat digunakan kembali.

MSBuild butuh waktu untuk mengerti, tetapi begitu Anda melakukannya, itu sangat bagus.

Materi pembelajaran:


38
Hei, saya pernah mendengar buku-buku itu :)
Sayed Ibrahim Hashimi

19

KISS = Gunakan MSBuild.

Mengapa menambahkan sesuatu yang lain ke dalam campuran ketika Anda memiliki sesuatu yang akan melakukan pekerjaan yang wajar di luar kotak? Ketika MSBuild tiba, NAnt meninggal. Dan Mono akan memiliki implementasi MSBuild, ( xbuild ).

KERING = Gunakan MSBuild.

Tanyakan pada diri sendiri apa yang Anda inginkan dari sistem build? Saya ingin sistem build yang juga digunakan oleh IDE saya daripada mempertahankan dua konfigurasi yang berbeda.

Secara pribadi, saya ingin mendengar beberapa argumen nyata untuk NAnt, karena saya tidak bisa memikirkan yang benar-benar menahan air.


2
"Ketika msbuild arived, nant meninggal" - saya pikir ini adalah penentu, bahkan tanpa VS (yang tidak saya gunakan).
harpo

Saya setuju. DotNet 1.1 tidak memiliki msbuild.exe. Jadi kami kacau saat itu. Sejak 2.0, msbuild.exe dan pustaka tambahan melakukan banyak hal. Dan menulis kustom MsBuild-Task memiliki kurva belajar, tetapi saya telah menulis sekitar 10 dari mereka selama bertahun-tahun.
granadaCoder

1
Saya harus setuju, Anda harus menggunakan alat yang sama untuk membangun sebagai pengembang karena server build akan menggunakan yang memungkinkan Anda gagal lebih cepat.
kehormatan krystan

14

Satu hal yang saya perhatikan beberapa poster menyebutkan harus mengedit tangan file .csproj (atau .vbproj, dll.).

MSBuild memungkinkan kustomisasi file-file ini. * Proj melalui penggunaan file .user. Jika saya memiliki proyek bernama MyCreativelyNamedProject.csproj dan ingin menyesuaikan tugas MSBuild di dalamnya, saya dapat membuat file bernama MyCreativelyNamedProject.csproj.user dan menggunakan CustomBeforeMicrosoftCommonTarget dan CustomAfterMicrosoftCommonTarget untuk menyesuaikan file-file itu.

Juga, baik NAnt dan MSBuild dapat disesuaikan dengan isi hati melalui tugas MSBuild khusus dan melalui ekstensi NantContrib.

Jadi, menggunakan NAnt atau MSBuild benar-benar menjadi akrab:

  • Jika Anda sudah terbiasa dengan Ant, gunakan NAnt. Kurva belajar akan sangat mudah.
  • Jika Anda tidak terbiasa dengan alat apa pun, MSBuild sudah terintegrasi dengan Visual Studio dan tidak memerlukan alat tambahan.

Perlu juga ditambahkan bahwa MSBuild dijamin untuk bekerja dengan semua versi baru . NET dan Visual Studio segera setelah dirilis, sedangkan NAnt mungkin memiliki beberapa kelambatan.


1
+1 untuk menunjukkan jeda antara rilis .net dan rilis nant. Saya ingat ketika .net 3.5 keluar dan harus menggunakan nant.exe.config yang diretas dari jaring untuk membuat semuanya berfungsi. Tidak menyenangkan.
mmacaulay

9
Menurut banyak postingan di sekitar sini, file .USER tersebut berisi + info spesifik pengguna + yang tidak boleh diperiksa, jadi itu akan menjadi tempat terakhir yang saya inginkan untuk membuat kustomisasi build ... Setiap kustomisasi build menurut definisi seharusnya tidak lebih spesifik untuk pengguna, dan seharusnya tidak masuk dalam file
.user itu

1
Setuju dengan drventure; .user-file adalah seperti namanya menyarankan pengguna pr dan mereka bahkan tidak harus diperiksa ke repositori kontrol sumber Anda. Ini BUKAN tempat untuk mengotomatisasi pembuatan.
Kjetil Klaussen

10

Saya menggunakan keduanya dalam skrip NAnt saya memanggil MSBuild. Alasan utama saya untuk tetap dengan NAnt adalah isolasi . Biarkan saya jelaskan mengapa saya merasa ini penting:

  1. Menambahkan dependensi ke proyek Anda. Berkas build NAnt adalah asing bagi Visual Studio (dalam kasus saya saya anggap ini pro) sehingga Visual Studio tidak berupaya melakukan apa pun dengannya. Tugas MSBuild tertanam jadi bagian dari solusi dan dapat merujuk ke tugas MSBuild lainnya. Saya telah menerima kode sumber dari orang lain hanya untuk mengetahui saya tidak dapat membangun, karena tugas komunitas MSBuild tidak diinstal. Apa yang saya temukan sangat membuat frustrasi adalah bahwa Visual Studio tidak akan membangun dan melemparkan banyak kesalahan yang membuat saya kehilangan waktu debugging. Ini, terlepas dari fakta bahwa build yang diminta bisa saja berjalan (sebagai debug misalnya) tanpa beberapa tambahan dari tugas MSBuild. Singkatnya: Saya tidak suka menambahkan dependensi ke proyek saya jika saya bisa menghindarinya .

  2. Saya tidak percaya Visual Studio sejauh yang saya bisa melemparkan tim pengembangannya. Ini berasal dari hari-hari awal Visual Studio ketika akan membantai HTML saya. Saya masih tidak menggunakan desainer misalnya (di sebuah konferensi baru-baru ini saya menemukan rekan kerja melakukan hal yang sama). Saya telah menemukan bahwa Visual Studio dapat mengacaukan dependensi dan nomor versi dalam file DLL (saya tidak dapat mereplikasi ini, tetapi hal itu terjadi dalam sebuah proyek secara konsisten dan menyebabkan banyak kesedihan dan kehilangan waktu). Saya telah menggunakan prosedur pembangunan yang menggunakan Visual Studio untuk membangun hanya dalam mode debug. Untuk produksi, saya menggunakan NAnt sehingga saya mengontrol semuanya secara eksternal . Visual Studio tidak dapat mengganggu lagi jika saya membangun menggunakan NAnt.

PS: Saya seorang pengembang web dan tidak melakukan pengembangan Formulir Windows.


6

Meskipun saya tidak terlalu mengenal MsBuild, saya mendapat kesan bahwa beberapa perbedaan utama di kedua sisi dapat ditambah dengan penambahan:

Baru-baru ini saya harus membangun proyek Silverlight di Nant. Saya menemukan bahwa hidup akan lebih mudah jika saya hanya melakukan ini dengan MsBuild - Saya akhirnya memanggil tugas MsBuild dari dalam skrip Nant jadi saya kira itu tidak terlalu luar biasa untuk mencampur dan mencocokkan keduanya.

Selain itu, saya kira itu akan menjadi pertanyaan tentang preferensi pribadi - jelas Anda dapat mengelola sebagian / sebagian besar fungsi MsBuild dari dalam Visual Studio, jika itu yang Anda inginkan. Nant tampaknya lebih fleksibel dan lebih cocok jika Anda lebih suka menulis skrip dengan tangan, dan jika Anda berasal dari dunia Jawa, Anda mungkin akan betah menggunakannya.


Poin yang bagus. Kedua solusi dapat dengan mudah diperluas dan disesuaikan dengan cara apa pun yang diinginkan.
CleverPatrick

2

Saya akhirnya menggunakan keduanya. Ketika mendesain ulang sistem build kami, saya menghadapi masalah yang rumit. Yaitu, saya tidak bisa menghilangkan .vcproj (dan keluarga) karena kami semua menggunakan VS untuk memperbarui file proyek, pengaturan, dan konfigurasi. Jadi tanpa proses duplikasi dan rawan kesalahan besar, kami tidak dapat mendasarkan sistem pembangunan kami pada set file baru.

Untuk alasan ini, saya memutuskan untuk menyimpan file 'proj' dari VS dan menggunakan MSBuild (mereka adalah file MSBuild, setidaknya VS2005 dan VS2008 menggunakan file proyek MSBuild). Untuk yang lainnya (konfigurasi khusus, pengujian unit, pengemasan, menyiapkan dokumentasi ...) Saya menggunakan NAnt.

Untuk integrasi berkelanjutan, saya menggunakan CruiseControl. Jadi kami memiliki skrip CC yang memicu pekerjaan NAnt, yang untuk membangun menggunakan MSBuild.

Satu catatan terakhir: MSBuild TIDAK mendukung proyek Pengaturan! Jadi, Anda terjebak dengan memanggil DevEnv.com atau menggunakan Visual Studio secara langsung. Itulah yang akhirnya saya lakukan, tetapi saya menonaktifkan proyek pengaturan secara default dari semua konfigurasi solusi, karena pengembang biasanya tidak perlu membangunnya, dan jika mereka melakukannya, mereka dapat memilih secara manual untuk membangunnya.



1

Dokumentasi dan tutorial yang tersedia untuk NAnt membuatnya lebih mudah untuk mulai belajar membangun skrip dengan NAnt. Setelah saya memahami NAnt dan membuat skrip build, saya mulai menerjemahkan pengetahuan itu ke MSBuild (saya melakukan X di NAnt, bagaimana saya melakukan X di MSBuild?). Dokumentasi Microsoft biasanya mengasumsikan tingkat pengetahuan yang cukup tinggi sebelum berguna.

Alasan untuk beralih dari NAnt ke MSBuild adalah karena MSBuild lebih mutakhir. Sayangnya rilis NAnt terakhir adalah pada 8 Desember 2007, sementara MSBuild 4.0 (.NET 4.0) tidak jauh. Sepertinya proyek NAnt telah mati.

Jika Anda menemukan dokumentasi yang bagus untuk seseorang yang baru mulai belajar membuat skrip build menggunakan MSBuild, lewati NAnt dan langsung menuju MSBuild. Jika NAnt pernah keluar dengan rilis baru maka saya akan mempertimbangkan tetap dengan NAnt, tapi mereka tertinggal sekarang.


1
Pada Juni 2012, versi 0.92 dari NAnt tersedia dari situs web: nant.sourceforge.net DAN mendukung .Net 4.0.
Brett Rigby

0

Kami menggunakan keduanya. NAnt bertanggung jawab untuk semua hal "scripting", seperti menyalin, menggunakan IIS , membuat paket dan MSBuild bertanggung jawab untuk membangun solusi. Kemudian kita dapat menghindari masalah dengan .NET 4.0 yang tidak didukung oleh versi baru NAnt.

Tidak juga lebih skalabel. Jika kami ingin memigrasikan skrip penerapan ke server produksi, kami hanya menyalin file build dan menginstal versi .NET yang tepat - tidak ada masalah Visual Studio dengan file csproj :)


0

YDeliver oleh Manoj adalah kerangka kerja yang dibangun di atas PSake. Ini memiliki serangkaian fungsi perpustakaan, kemampuan untuk menentukan alur kerja, dan kami telah menggunakannya untuk mengirimkan lebih dari enam proyek perusahaan ke produksi.

Gunakan bersama dengan TeamCity , CruiseControl , atau apa pun yang dapat menjalankan PowerShell .


0

Kami menggunakan FlubuCore. Ini adalah perpustakaan C # sumber terbuka untuk membangun proyek dan menjalankan skrip penerapan menggunakan kode C #.

Contoh sederhana tentang bagaimana flubu digunakan:

protected override void ConfigureTargets(ITaskContext session)
{           

    var compile = session.CreateTarget("compile")
        .SetDescription("Compiles the solution.")
        .AddTask(x => x.CompileSolutionTask())
        .DependsOn("generate.commonassinfo");
}

Anda dapat menemukan informasi lebih lanjut tentang flubu dan cara memulai di sini: choice-for-build-tool-msbuild-nant-or-something-else

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.