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:
Saya sudah melakukan penyelidikan serupa minggu ini. Inilah yang saya dapat menentukan:
TIDAK:
MSBuild:
Perbedaan Subyektif: (YMMV)
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).
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.)
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:
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.
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:
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.
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:
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 .
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.
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.
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.
Saya telah beralih dari NAnt ke MSBuild baru-baru ini karena kemampuannya untuk membangun solusi VS. Saya masih menggunakan NAnt sesekali.
Anda mungkin juga ingin memeriksa Tugas Komunitas MSBuild yang seperti NAntContrib.
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.
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 :)
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 .
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