it-swarm-id.com

Mono sering digunakan untuk mengatakan "Ya, .NET adalah cross-platform". Seberapa valid klaim itu?

Dalam Apa yang akan Anda pilih untuk proyek Anda antara .NET dan Java pada saat ini? Saya mengatakan bahwa saya akan mempertimbangkan "Akankah Anda selalu menggunakan ke Windows? "satu-satunya keputusan teknis terpenting untuk menjadi yang terdepan dalam proyek web baru, dan jika jawabannya" tidak ", saya akan merekomendasikan Java daripada .NET.

Argumen kontra yang sangat umum adalah bahwa "Jika kita ingin menjalankan Linux/OS X/Terserah, kita hanya akan menjalankan Mono"1, yang merupakan argumen yang sangat meyakinkan di permukaan, tetapi saya tidak setuju karena beberapa alasan.

  • OpenJDK dan semua vendor yang disediakan JVM telah melewati Sun TCK resmi yang memastikan semuanya berjalan dengan benar. Saya tidak mengetahui Mono mengoper Microsoft TCK.
  • Mono mengikuti rilis .NET. Apa .NET-level saat ini didukung penuh?
  • Apakah semua elemen GUI (WinForms?) Berfungsi dengan benar di Mono?
  • Bisnis mungkin tidak ingin bergantung pada kerangka kerja Sumber Terbuka sebagai rencana resmi B.

Saya sadar bahwa dengan tata kelola baru Java oleh Oracle, masa depan tidak aman, tetapi mis. IBM menyediakan JDK untuk banyak platform , termasuk Linux. Mereka hanya tidak open source.

Jadi, dalam keadaan apa Mono strategi bisnis yang valid untuk .NET-aplikasi?


1Mark H meringkasnya sebagai : "Jika klaimnya adalah " Saya punya aplikasi windows yang ditulis dalam .NET, itu harus berjalan pada mono ", maka tidak, itu bukan klaim yang valid - tetapi Mono telah melakukan upaya untuk membuat porting aplikasi seperti itu lebih sederhana. "

171
user1249

jawaban Sparkie mengerti, izinkan saya melengkapi sedikit.

".NET adalah lintas platform" terlalu banyak pernyataan yang ambigu karena kerangka kerja dan dunia yang semula diciptakan untuknya telah berubah dan berevolusi.

Jawaban singkatnya adalah:

Mesin yang mendasari yang menggerakkan .NET dan turunannya, Common Language Infrastructure Standard, adalah lintas-platform dan seolah-olah Anda ingin membuat kode Anda masuk ke berbagai platform, Anda perlu merencanakan untuk menggunakan API yang tepat di platform yang tepat untuk memberikan pengalaman terbaik di setiap platform.

Keluarga CLI belum mencoba pendekatan "Write Once, Run Anywhere", karena perbedaan dari ponsel ke mainframe terlalu besar. Alih-alih semesta API dan fitur runtime yang khusus untuk platform telah muncul untuk memberikan pengembang alat yang tepat untuk membuat pengalaman hebat di setiap platform.

Pikirkan: pemrogram tidak lagi menargetkan PC Windows atau Server Unix. Dunia, sekarang lebih dari sebelumnya dikelilingi oleh platform yang menarik dari PC, ke konsol game, ke ponsel yang kuat, ke kotak set-top, ke server besar dan mendistribusikan kelompok mesin. Satu ukuran cocok untuk semua platform hanya akan merasa kembung pada perangkat kecil, dan merasa kurang bertenaga pada sistem besar .

Produk .NET Framework Microsoft tidak lintas platform, hanya berjalan di Windows. Ada variasi .NET Framework dari Microsoft yang berjalan di sistem lain seperti Windows Phone 7, XBox360 dan browser melalui Silverlight, tetapi semuanya adalah profil yang sedikit berbeda.

Hari ini Anda dapat menargetkan setiap OS utama, telepon, perangkat seluler, sistem dan server tertanam dengan teknologi .NET. Berikut adalah daftar yang menunjukkan implementasi CLI mana yang akan Anda gunakan dalam setiap kasus (daftar ini tidak komprehensif, tetapi harus mencakup 99% dari kasus):

  • komputer PC berbasis x86 dan x86-64:
    • menjalankan Windows -> Biasanya Anda menjalankan .NET atau Silverlight tetapi Anda juga dapat menggunakan Mono lengkap di sini.
    • menjalankan Linux, BSD atau Solaris -> Anda menjalankan Mono atau Silverlight penuh
    • menjalankan MacOS X -> Anda menjalankan Mono atau Silverlight penuh
    • menjalankan Android -> Anda menjalankan subset Mono/Android
  • Komputer ARM:
    • Menjalankan Windows Phone 7: Anda menjalankan Compact Framework 2010
    • Menjalankan Windows 6.5 dan yang lebih lama: Anda menjalankan Compact Framework lama
    • Perangkat Android: Anda menjalankan Mono/Android
  • Komputer PowerPC:
    • Anda menjalankan Mono penuh untuk sistem operasi Linux, BSD atau Unix penuh
    • Anda menjalankan embedded Mono untuk PS3, Wii atau sistem embedded lainnya.
    • Di XBox360, Anda menjalankan CompactFramework
  • S390, S390x, Itanium, SPARC komputer:
    • Anda menjalankan Mono penuh
  • Sistem operasi tertanam lainnya:
    • Anda menjalankan .NET MicroFramework atau Mono dengan profil seluler.

Tergantung pada kebutuhan Anda di atas mungkin cukup atau tidak. Anda tidak akan mendapatkan kode sumber yang sama untuk dijalankan di mana-mana. Misalnya, kode XNA tidak akan berjalan di setiap desktop, sedangkan perangkat lunak .NET Desktop tidak akan berjalan di XNA atau telepon. Anda biasanya perlu membuat perubahan pada kode Anda untuk dijalankan di profil lain dari .NET Framework. Berikut adalah beberapa profil yang saya ketahui:

  • Profil .NET 4.0
  • Profil Silverlight
  • Profil Windows Phone 7
  • Profil XBox360
  • Profil inti Mono - mengikuti profil .NET dan tersedia di Linux, MacOS X, Solaris, Windows dan BSD.
  • .NET Micro Framework
  • Mono di profil iPhone
  • Mono pada Android Profil
  • Mono di Profil PS3
  • Mono di Profil Wii
  • Profil Cahaya Bulan (kompatibel dengan Silverlight)
  • Moonlight extended profile (Silverlight + full .NET 4 API access)

Jadi masing-masing profil itu sebenarnya sedikit berbeda, dan ini bukan hal yang buruk. Setiap profil dirancang agar sesuai dengan platform Host-nya dan mengekspos API yang masuk akal, dan menghapus yang tidak masuk akal.

Misalnya, API Silverlight untuk mengontrol browser Host tidak masuk akal di telepon. Dan shader di XNA tidak masuk akal pada perangkat keras PC yang tidak memiliki dukungan setara untuk itu.

Semakin cepat Anda menyadari bahwa .NET bukan solusi untuk mengisolasi pengembang dari kemampuan yang mendasari perangkat keras dan platform asli, semakin baik Anda.

Itu mulai berkata, beberapa API dan tumpukan tersedia dalam beberapa platform, misalnya ASP.NET dapat digunakan pada Windows, Linux, pada Solaris, pada MacOS X karena API tersebut ada di .NET dan Mono. ASP.NET tidak tersedia pada beberapa platform yang didukung Microsoft seperti XBox atau Windows Phone 7 dan tidak didukung pada platform lain yang Mono dukung seperti Wii atau iPhone.

Informasi berikut ini hanya benar pada 21 November, dan banyak hal di dunia Mono kemungkinan akan berubah.

Prinsip yang sama dapat diterapkan pada tumpukan lain, daftar lengkap akan membutuhkan tabel yang tepat, yang saya tidak tahu bagaimana menyajikan di sini, tetapi di sini adalah daftar teknologi yang mungkin tidak ada pada platform tertentu. Anda dapat mengasumsikan bahwa apa pun yang tidak tercantum di sini tersedia (jangan ragu untuk mengirim saya suntingan untuk hal-hal yang saya lewatkan):

Core Runtime Engine [di mana-mana]

  • Reflection.Emit Support [di mana-mana, kecuali WP7, CF, Xbox, MonoTouch, PS3]
  • Dukungan SIMD CPU [Linux, BSD, Solaris, MacOS X; Segera PS3, MonoTouch dan MonoDroid]
  • Lanjutan - Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
  • Assembly Unloading [Khusus Windows]
  • Injeksi VM [Linux, BSD, MacOS X, Solaris]
  • DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
  • Generik [beberapa batasan pada PS3 dan iPhone].

Bahasa

  • C # 4 [di mana-mana]
  • C # Compiler sebagai Layanan (Linux, MacOS, Solaris, BSD, Android)
  • IronRuby [di mana-mana, execpt WP7, CF, Xbox, MonoTouch, PS3]
  • IronPython [di mana-mana, execpt WP7, CF, Xbox, MonoTouch, PS3]
  • F # [di mana-mana, execpt WP7, CF, Xbox, MonoTouch, PS3]

Tumpukan Server

  • ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
  • ADO.NET [di mana-mana]
  • LINQ ke SQL [di mana-mana]
  • Kerangka Entitas [di mana-mana]
  • Core XML stack [di mana-mana]
    • Serialisasi XML [di mana-mana, kecuali WP7, CF, Xbox)
  • LINQ ke XML (di mana-mana)
  • System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
  • System.Messaging [Windows; di Linux, MacOS dan Solaris membutuhkan RabbitMQ]
  • .NET 1 Layanan Perusahaan [Khusus Windows]
  • WCF [lengkap tentang Windows; subset kecil di Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid]
  • Windows Workflow [Khusus Windows]
  • Identitas Cardspace [khusus Windows]

Tumpukan GUI

  • Silverlight (Windows, Mac, Linux - dengan Moonlight)
  • WPF (hanya Windows)
  • Gtk # (Windows, Mac, Linux, BSD)
  • Windows.Forms (Windows, Mac, Linux, BSD)
  • MonoMac - Native Mac Integration (hanya Mac)
  • MonoTouch - Integrasi iPhone Asli (khusus iPhone/iPad)
  • MonoDroid - Asli Android Integrasi (khusus Android)
  • API Media Center - Hanya Windows
  • Clutter (Windows dan Linux)

Perpustakaan Grafik

  • GDI + (Windows, Linux, BSD, MacOS)
  • Kuarsa (MacOS X, iPhone, iPad)
  • Kairo (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

Mono Libraries - Cross Platform, dapat digunakan dalam. NET tetapi membutuhkan pembangunan secara manual

  • C # 4 Compiler sebagai Layanan
  • Cecil - Manipulasi CIL, alur kerja, instrumentasi CIL, Linker
  • Perpustakaan RelaxNG
  • Mono.Data. * Penyedia basis data
  • Full System.Xaml (untuk digunakan dalam pengaturan di mana .NET tidak menawarkan stack)

MonoTouch berarti Mono berjalan di iPhone; MonoDroid berarti Mono berjalan di Android; Port PS3 dan Wii hanya tersedia untuk pengembang yang memenuhi syarat Sony dan Nintendo.

Saya minta maaf karena kurangnya formalitas.

195
miguel.de.icaza

Pertama, Anda perlu membuat perbedaan antara Common Language Infrastructure (Standar terbuka), dan .NET (Microsoft menerapkan standar itu). Mono adalah implementasi dari CLI, dan tidak pernah mengklaim sebagai "portable .NET". Juga, bahasa C # adalah standar terbuka, dan tidak sepenuhnya terikat dengan .NET.

Saya tidak tahu apakah Microsoft memiliki alat untuk memvalidasi bahwa suatu implementasi sesuai, tetapi jika mereka melakukannya, saya cukup yakin para mono memilikinya, dan menggunakannya.

Mono tertinggal di belakang. Net, tetapi nyaris tidak. Mono dapat menjalankan kode C # 4.0 (versi .NET saat ini). Juga, Microsoft baru-baru ini membuat semua kode DLR dan pustaka sumber terbuka (di bawah lisensi Apache 2.0), yang telah memungkinkan mono untuk menggunakan bahasa seperti IronPython, IronRuby, dan F # telah dibuat open source hanya minggu lalu. Selain itu, Microsoft secara teratur merilis CTP fitur mendatang di .NET, yang memungkinkan pengembang mono untuk tetap mengikuti perkembangan dengan versi rilis saat ini.

Ada sejumlah alat dan ekstensi di .NET, misalnya, Kontrak Kode. Ini tidak selalu dilaksanakan sepenuhnya dalam mono. (Saat ini, saya pikir ada validator kontrak parsial untuk Membutuhkan kontrak). Ini tidak umum digunakan dalam aplikasi .NET, tetapi jika popularitas mereka meningkat, demikian juga tingkat penerapannya di mono.

WinForms tidak (sepenuhnya) portabel. Mereka adalah. NET spesifik dan bukan bagian dari CLI. CLI tidak menentukan set widget tertentu. Ada set widget lintas platform (GTK # dan Silverlight). Jika Anda menulis aplikasi dari bawah ke atas dengan mempertimbangkan portabilitas, Anda akan menggunakan salah satunya daripada WinForms/WPF. Selain itu, mono menyediakan pembungkus tipis untuk API Winforms - yang memungkinkan aplikasi winforms yang ada untuk lebih mudah porting ke GTK # (tanpa seluruh penulisan ulang).

Mono menyediakan alat, Mono Migration Analyzer (MoMA), yang dapat mengambil aplikasi .Net yang ada dan memberi tahu Anda tentang portabilitasnya. (misalnya, mengidentifikasi perpustakaan yang tidak dapat diakses yang digunakan, P/Panggil dll).

Untuk bisnis yang tidak ingin bergantung pada Open Source - mono dapat dilisensikan ulang. Kepemilikan kode yang ditambahkan ke mono diserahkan ke novell, yang dapat melisensikannya dengan cara alternatif selain lisensi LGPL biasa (yang memiliki sedikit batasan).

Jadi untuk klaim ". NET portable", saya pikir ini bisa menjadi pernyataan yang valid jika Anda menulis kode dari bawah ke atas dan menyadari masalah portabilitas dengan kerangka kerja. Jika klaimnya adalah "Saya punya aplikasi windows yang ditulis dengan .NET, itu harus berjalan pada mono", maka tidak, itu bukan klaim yang valid - tetapi Mono telah berupaya membuat porting aplikasi semacam itu lebih sederhana.

115
Mark H

Poin demi poin:

  • OpenJDK dan semua vendor yang disediakan JVM telah melewati Sun TCK resmi yang memastikan semuanya berfungsi dengan benar. Saya tidak mengetahui Mono melewati Microsoft TCK.
    Ada spesifikasi yang sesuai dengan Microsoft CLR. Mono bukan tiruan dari CLR Microsoft, melainkan implementasi dari spesifikasi yang sama. Di satu sisi, ada kemungkinan hal ini menghasilkan ketidakcocokan yang lebih besar. Dalam praktiknya, ini bekerja sangat baik untuk mono.
  • Mono melacak rilis .NET. Apa .NET-level saat ini didukung sepenuhnya?
    Karena dokumentasi untuk .Net mendahului rilis aktual, mono sebenarnya telah menyelesaikan (bukan rilis beta) dukungan untuk .Net 4 out sebelumnya rilis resmi Microsoft. Selain itu, mono melakukan pekerjaan yang sangat baik dalam mendokumentasikan hal-hal yang tidak didukung, dan mereka memiliki beberapa alat yang dapat Anda jalankan melawan proyek yang ada untuk membantu Anda melihat tempat-tempat dengan potensi ketidakcocokan.
  • Apakah semua elemen GUI (WinForms?) Berfungsi dengan benar di Mono?
    Sebagian besar winform berfungsi dengan baik. WPF, tidak banyak. Saya pernah mendengar bahwa hal yang sama berlaku untuk Java - banyak dari widget/gui toolkit canggih tidak didukung dengan baik di semua platform.
  • Bisnis mungkin tidak ingin bergantung pada kerangka kerja Sumber Terbuka seperti rencana resmi B.
    Jika itu masalahnya, mereka pasti tidak akan pergi dengan Java, maka, karena itu menempatkan kerangka kerja open source lebih tinggi pada rencana A.

Singkatnya, jika Anda ingin membangun aplikasi lintas platform sekarang , tidak ada yang salah dengan memulai dengan mono dari awal dan menggunakannya sebagai kerangka kerja Anda. Anda bahkan dapat menggunakan mono di Windows jika diinginkan.

Di sisi lain, jika Anda ingin membangun aplikasi Windows hari ini yang menurut Anda mungkin perlu dilakukan lintas platform di beberapa titik yang tidak diketahui di di masa depan, Anda mungkin ingin menggunakan widget dan alat Windows asli. .Net melakukan pekerjaan yang jauh lebih baik di sini daripada di Jawa, dan mono dapat diterima kembali dalam skenario ini.

Dengan kata lain: Ya, .Net jika lintas platform dalam segala hal yang penting bagi pertanyaan Anda. Tidak, mono tidak akan hanya menjalankan setiap program .Net di luar kotak, tetapi pertanyaan Anda adalah dalam konteks proyek baru. Tidak butuh banyak usaha untuk menjaga proyek baru dari masalah dan menghindari masalah kompatibilitas, terutama jika Anda berpikir dalam hal mengembangkan untuk mono daripada mengembangkan untuk. Net.

Namun yang paling penting, saya pikir ini adalah pertanyaan yang salah. Kecuali jika Anda membangun tim pengembangan baru dari awal, Anda mulai dengan programmer yang memiliki keahlian di satu bidang atau yang lain. Hasil terbaik Anda akan dicapai dengan mengikuti apa yang sudah diketahui oleh programmer Anda. Sama pentingnya dengan membangun aplikasi lintas platform, jika Anda memiliki tim yang penuh dengan programmer .Net dengan sedikit pengalamanJava, Anda tidak akan memecat mereka atau membuat mereka semua belajar Java untuk proyek Anda berikutnya. Jika Anda memiliki tim yang penuh dengan programmer Java, Anda tidak akan meminta mereka untuk belajar .Net untuk proyek khusus Windows. Salah satu dari mereka akan menjadi gila.

14
Joel Coehoorn

Saya telah bekerja dengan Mono, dan saya akan mengatakan itu sebaik yang Anda bisa dapatkan dengan platform alternatif yang bersifat open-source, dan tidak secara langsung didukung oleh Microsoft. Jika Anda merasa nyaman menggunakan platform open-source alternatif seperti Clojure atau Scala, Anda mungkin bisa merasa nyaman menggunakan Mono.

Level .NET yang didukung oleh Mono selalu dapat ditemukan di halaman Mono Roadmap .

Apakah semua elemen GUI berfungsi? Sejauh yang saya tahu, mereka melakukannya, meskipun saya belum mencoba semua elemen secara mendalam.

Apakah Mono identik dengan .NET? Tidak. Saya menduga akan ada perubahan kecil (dan mungkin besar) yang diperlukan di sana-sini. Anda tidak bisa, saat ini, menjalankan Entity Framework dengannya, misalnya.

11
Robert Harvey

Sebagai target, .NET/mono universe bergerak sangat cepat .

Setiap beberapa tahun, Microsoft keluar dengan beberapa perubahan menarik dan inovasi mengenai bahasa, runtime, dan infrastruktur seputar .NET. Sebagai contoh: Generik, LINQ, DLR, Entity Framework - dengan setiap revisi baru dari Visual Studio, secara umum ada peningkatan yang cukup signifikan dalam set fitur dan kegunaan kerangka yang ditargetkan.

Meskipun perbaikan konstan dalam kerangka ini disambut baik, itu juga bermasalah jika Anda ingin kompatibilitas di berbagai platform. Platform dukungan jangka panjang seperti Red Hat Enterprise Linux bergerak sangat lambat dalam hal mengadopsi teknologi baru, dan pada titik tertentu, akan ada peningkatan signifikan dalam platform Mono yang telah terjadi hanya dalam beberapa bulan terakhir. Jadi jika Anda ingin menjalankan hal-hal yang sedang dibuat oleh anak-anak keren, Anda harus mengkompilasi Mono dari awal dan mengelola tambalan dan pembaruan Anda sendiri. Itu tidak keren.

Java, di sisi lain, sama stagnannya dengan kolam kiddie. Apalagi sekarang milik perusahaan yang hanya ingin Java untuk tuntutan hukum paten, Anda dapat cukup yakin bahwa tidak akan ada perubahan yang terdeteksi dalam bahasa atau runtime di masa mendatang. Java adalah platform yang stabil seperti FORTRAN. Itu tidak begitu baik jika Anda berharap untuk segala jenis perbaikan, tetapi tidak terlalu buruk jika Anda mencoba untuk menggunakan aplikasi perusahaan.

9
tylerl

Dari perspektif pengguna, Mono payah dalam membuat aplikasi Windows .NET yang kompatibel dengan Linux. Jika Anda benar-benar mencoba menjalankan aplikasi Windows yang ditulis dengan sopan di Mono, itu tidak akan berhasil.

Dari perspektif pengemasan (saya dulu melakukan sedikit pekerjaan di PortableApps), .NET bisa menjadi berkah sekaligus kutukan. Jika Anda hanya menggunakan Windows, .NET membuat penempatan jauh lebih mudah karena lebih banyak pustaka berarti lebih sedikit ketergantungan sistem (terutama antara versi Windows, saya percaya) tetapi juga sangat membingungkan bahkan di Windows karena. Versi NET tidak mundur -kompatibel atau kompatibel ke depan. Anda harus mengunduh berbagai versi .NET untuk berbagai program.

Yang mengatakan, Mono adalah titik awal yang baik untuk membuat program C # lintas-platform. Hanya saja jangan mengemas program dengan WINE terbaru dan menyebutnya selesai. Lihat di mana itu mengambil Picasa.

Seperti dengan dua bahasa/platform stabilitas politik, RMS mungkin akan mulai mengomel tentang bagaimana Mono dipimpin oleh Novell, yang berbulan madu dengan Microsoft cukup terkenal. Kedua platform dapat dianggap tidak stabil secara politis saat ini. .

Jika Anda benar-benar menginginkan cross-platform yang mudah, jalur yang dicoba dan benar adalah QT yang cukup stabil secara politis hingga saat ini adalah a) LGPL, b) dilakukan dengan masalah perizinan utama tahun lalu, dan c) didukung oleh Nokia, yang menjual ponsel yang sangat populer.

7
digitxp

Mono bukan port 1: 1 dari .net Microsoft. Ada teknologi yang Mono tidak akan menerapkan atau tidak memiliki rencana untuk melakukannya (misalnya, Workflow Foundation atau WPF ) sementara di sisi lain mereka memiliki beberapa teknologi mereka sendiri yang tidak dilakukan Microsoft .NET, mis., Ekstensi SIMD.

Jawaban Singkat: Mono dan Microsoft .NET didasarkan pada fondasi dasar yang sama - CIL dan BCL - tetapi merupakan proyek yang terpisah.

4
Michael Stum

Komentar kecil untuk pernyataan di posting asli. Saya akan berpendapat bahwa TCK tetap menjadi alat teoritis yang memungkinkan Oracle mengklaim Java adalah standar terbuka. Karena jika Anda perhatikan, Apache Harmony telah mencoba untuk mendapatkan sertifikasi sebagai "Java" selama beberapa tahun sekarang, tidak berhasil. Jelas bahwa Oracle benar-benar tidak tertarik pada implementasi open source selain dari yang mereka berafiliasi dengan dan lebih atau kurang kontrol (OpenJDK), yang btw. seperti Mono, tidak lengkap (mis. tidak ada Java dukungan Mulai Web) dan kehilangan beberapa optimasi yang tersedia dalam implementasi HotSpot sumber tertutup.

Jadi bisa dibilang, pada 2010; (sebagian besar) Java adalah open source tetapi bukan standar terbuka, sementara (sebagian besar) .NET bukan open source tetapi standar terbuka. Tentu saja ada pengecualian, DLR, IronPython, IronRuby dan F # sebenarnya open source. Mono menarik karena memberikan yang terbaik dari kedua dunia, implementasi open source dari standar terbuka.

2
Casper Bang

Mengesampingkan semua teknis, bagian yang sangat penting terjadi ketika benar-benar menulis kode.

Seperti halnya teknologi lintas-platform (baik itu Java, Python, Ruby ...), jika kode tidak ditulis dengan mudah dibawa dalam pikiran, Anda harus mengasumsikan pada dasarnya tidak ada peluang kode akan berjalan dengan baik (bahkan jika ada kemungkinan seperti itu) pada kenyataannya jauh, jauh lebih tinggi), karena perilaku aneh bisa sangat kritis. Baca: jangan mengambil Majelis acak dan menjalankannya di bawah Mono.

Namun untuk proyek baru (atau yang dapat Anda refactor dengan mudah), memilih .Net/Mono sebagai runtime portabel yang masuk akal, tetapi Anda menghemat banyak kerepotan dengan menguji kode Anda pada Mono sejak awal, bahkan jika proyek tersebut memiliki hanya sedikit perubahan dari multiplatform. Jika Anda menggunakan server integrasi kontinu, ini bisa sesederhana mengatur node Mono build. Banyak masalah dapat diselesaikan sambil berkembang, hanya dengan membiasakan diri (seperti membangun string jalan) dan sebagian besar kode Anda dapat dibawa-bawa dan diuji unit pada Mono hanya dengan menggunakan praktik yang waras dan sedikit pemikiran ke depan. Sisanya (yaitu unit test gagal) kemudian spesifik platform (seperti kode menggunakan PInvoke) tetapi harus dirangkum cukup agar dapat memberikan implementasi alternatif per platform yang ditargetkan. Dengan cara ini ketika proyek akhirnya menjadi porting, sebagian besar pekerjaan telah dilakukan tanpa biaya dan sisanya akan dikembangkan Just In Time.

Tentu saja, menggunakan perpustakaan yang tidak tersedia (.Net) atau yang kompatibel (pihak ketiga) di Mono menghalangi semua ini, tetapi di bidang saya ini belum terlihat. Itulah strategi yang sebenarnya kami gunakan di tempat kerja, dan ketika menerapkannya saya tidak takut mengklaim bahwa .Net + Mono adalah lintas platform.

1
Lloeki

Bervariasi adalah jawaban jujur. Saya telah melihat hal-hal server web kecil dipindahkan dari IIS ke Apache, berjalan di bawah mono dengan hampir tanpa kesulitan. Saya telah menjalankan aplikasi Windows .Net yang tidak berubah menggunakan Win Forms di Linux dengan sukses.

Namun, sementara itu bisa bekerja, jika Anda menggunakan panggilan API yang tidak diimplementasikan pada mono maka itu tidak akan berfungsi, dan satu-satunya solusi adalah dengan menulis ulang aplikasi Anda, tetap menggunakan windows atau menulis hal-hal tambahan dalam mono.

0
Michael Shaw