it-swarm-vi.com

Mono thường được sử dụng để nói "Có, .NET là đa nền tảng". Yêu cầu đó có giá trị như thế nào?

Trong Bạn sẽ chọn gì cho dự án của mình giữa .NET và Java tại thời điểm này? Tôi nói rằng tôi sẽ xem xét "Bạn sẽ luôn triển khai lên Windows chứ? "Quyết định kỹ thuật quan trọng nhất để tạo ra mặt trước trong một dự án web mới và nếu câu trả lời là" không ", tôi sẽ khuyên dùng Java thay vì .NET.

Một đối số rất phổ biến là "Nếu chúng ta muốn chạy trên Linux/OS X/Dù thế nào, chúng ta sẽ chỉ chạy Mono"1, đó là một lập luận rất hấp dẫn trên bề mặt, nhưng tôi không đồng ý vì nhiều lý do.

  • OpenJDK và tất cả các nhà cung cấp do JVM cung cấp đã thông qua Sun TCK chính thức để đảm bảo mọi thứ hoạt động chính xác. Tôi không biết về việc Mono vượt qua Microsoft TCK.
  • Mono theo dõi các bản phát hành .NET. Cấp độ .NET nào hiện đang được hỗ trợ đầy đủ?
  • Có phải tất cả các thành phần GUI (WinForms?) Hoạt động chính xác trong Mono?
  • Các doanh nghiệp có thể không muốn phụ thuộc vào các khung nguồn mở như là kế hoạch chính thức B.

Tôi biết rằng với quản trị mới Java của Oracle, tương lai không an toàn, nhưng ví dụ IBM cung cấp JDK cho nhiều nền tảng , kể cả Linux. mở nguồn.

Vậy, trong trường hợp nào Mono là một chiến lược kinh doanh hợp lệ cho các ứng dụng .NET?


1Mark H đã tóm tắt nó là : "Nếu khiếu nại là " Tôi có một ứng dụng windows được viết bằng .NET, nó sẽ chạy trên mono ", thì không, đó không phải là một yêu cầu hợp lệ - nhưng Mono đã nỗ lực để làm cho việc chuyển các ứng dụng đó trở nên đơn giản hơn. "

171
user1249

Câu trả lời của Sparkie hiểu rồi, hãy để tôi bổ sung một chút.

".NET là nền tảng chéo" là một tuyên bố mơ hồ vì cả khuôn khổ và thế giới mà nó được tạo ra ban đầu đã thay đổi và phát triển.

Câu trả lời ngắn gọn là:

Công cụ cơ bản hỗ trợ .NET và các dẫn xuất của nó, Tiêu chuẩn cơ sở hạ tầng ngôn ngữ chung, là nền tảng chéo và như thể bạn muốn làm cho mã của mình chuyển sang nhiều nền tảng, bạn cần lên kế hoạch sử dụng API phù hợp trên nền tảng phù hợp để mang lại trải nghiệm tốt nhất trên mỗi nền tảng.

Gia đình CLI đã không thử cách tiếp cận "Viết một lần, chạy mọi nơi", vì sự khác biệt từ điện thoại đến máy tính lớn là quá lớn. Thay vào đó, một vũ trụ gồm các tính năng API và thời gian chạy dành riêng cho nền tảng đã xuất hiện để cung cấp cho các nhà phát triển công cụ phù hợp để tạo trải nghiệm tuyệt vời trong mỗi nền tảng.

Hãy nghĩ về nó: các lập trình viên không còn nhắm mục tiêu PC Windows hoặc Máy chủ Unix. Thế giới, hơn bao giờ hết được bao quanh bởi các nền tảng hấp dẫn từ PC, đến máy chơi game, điện thoại mạnh mẽ, hộp giải mã, máy chủ lớn và cụm máy phân tán. Một kích thước phù hợp trên tất cả các nền tảng sẽ chỉ cảm thấy cồng kềnh trên các thiết bị nhỏ và cảm thấy không đủ sức mạnh trên các hệ thống lớn .

Sản phẩm .NET Framework của Microsoft không phải là nền tảng chéo, nó chỉ chạy trên Windows. Có các biến thể của .NET Framework từ Microsoft chạy trên các hệ thống khác như Windows Phone 7, XBox360 và các trình duyệt thông qua Silverlight, nhưng chúng đều là các cấu hình hơi khác nhau.

Ngày nay, bạn có thể nhắm mục tiêu mọi hệ điều hành chính, điện thoại, thiết bị di động, hệ thống nhúng và máy chủ với các công nghệ dựa trên .NET. Dưới đây là danh sách cho thấy việc triển khai CLI nào bạn sẽ sử dụng trong từng trường hợp (danh sách này không đầy đủ, nhưng sẽ bao gồm 99% các trường hợp):

  • máy tính PC dựa trên x86 và x86-64: [.__.]
    • chạy Windows -> Thông thường bạn chạy .NET hoặc Silverlight nhưng bạn cũng có thể sử dụng Mono đầy đủ tại đây.
    • chạy Linux, BSD hoặc Solaris -> Bạn chạy toàn bộ Mono hoặc Silverlight
    • chạy MacOS X -> Bạn chạy Mono hoặc Silverlight đầy đủ
    • đang chạy Android -> Bạn chạy tập hợp con Mono/Android
  • Máy tính ARM: [.__.]
    • Chạy Windows Phone 7: bạn chạy Compact Framework 2010
    • Chạy Windows 6.5 trở lên: bạn chạy Compact Framework cũ
    • Thiết bị Android: bạn chạy Mono/Android
  • Máy tính PowerPC: [.__.]
    • Bạn chạy Mono đầy đủ cho các hệ điều hành Linux, BSD hoặc Unix đầy đủ
    • Bạn chạy Mono nhúng cho PS3, Wii hoặc các hệ thống nhúng khác.
    • Trên XBox360, bạn chạy CompactFramework
  • S390, S390x, Itanium, SPARC máy tính: [.__.]
    • Bạn chạy Mono đầy đủ
  • Các hệ điều hành nhúng khác: [.__.]
    • Bạn chạy .NET MicroFramework hoặc Mono với hồ sơ di động.

Tùy thuộc vào nhu cầu của bạn, những điều trên có thể là đủ hay không. Bạn sẽ khó có được mã nguồn giống nhau để chạy ở mọi nơi. Ví dụ: mã XNA sẽ không chạy trên mọi máy tính để bàn, trong khi phần mềm .NET Desktop sẽ không chạy trên XNA hoặc điện thoại. Thông thường bạn cần thay đổi mã của mình để chạy trong các cấu hình khác của .NET Framework. Dưới đây là một số hồ sơ tôi biết:

  • Hồ sơ .NET 4.0
  • Hồ sơ Silverlight
  • Hồ sơ Windows Phone 7
  • Hồ sơ XBox360
  • Cấu hình lõi đơn - theo cấu hình .NET và có sẵn trên Linux, MacOS X, Solaris, Windows và BSD.
  • .NET Micro Framework
  • Hồ sơ cá nhân trên iPhone
  • Mono trên Android Hồ sơ
  • Mono trên hồ sơ PS3
  • Mono trên hồ sơ Wii
  • Hồ sơ ánh trăng (tương thích với Silverlight)
  • Cấu hình mở rộng của Moonlight (Truy cập API Silverlight + .NET 4 đầy đủ)

Vì vậy, mỗi một trong những hồ sơ đó thực sự hơi khác nhau, và đây không phải là một điều xấu. Mỗi cấu hình được thiết kế để phù hợp với nền tảng Máy chủ của nó và hiển thị các API có ý nghĩa và loại bỏ các API không có ý nghĩa.

Chẳng hạn, các API của Silverlight để kiểm soát trình duyệt Máy chủ không có ý nghĩa trên điện thoại. Và các shader trong XNA không có ý nghĩa gì đối với phần cứng PC thiếu sự hỗ trợ tương đương cho nó.

Bạn càng sớm nhận ra rằng .NET không phải là một giải pháp để cách ly nhà phát triển khỏi các khả năng cơ bản của phần cứng và nền tảng gốc, bạn sẽ càng có lợi.

Điều đó bắt đầu, một số API và ngăn xếp có sẵn trong nhiều nền tảng, ví dụ ASP.NET có thể được sử dụng trên Windows, trên Linux, trên Solaris, trên MacOS X vì các API đó tồn tại cả trên .NET và Mono. ASP.NET không có sẵn trên một số nền tảng được hỗ trợ của Microsoft như XBox hoặc Windows Phone 7 và không được hỗ trợ trên các nền tảng khác mà Mono hỗ trợ như Wii hoặc iPhone.

Thông tin sau chỉ chính xác vào ngày 21 tháng 11 và nhiều điều trong thế giới Mono có thể sẽ thay đổi.

Các nguyên tắc tương tự có thể được áp dụng cho các ngăn xếp khác, một danh sách đầy đủ sẽ yêu cầu một bảng thích hợp, mà tôi không biết làm thế nào để trình bày ở đây, nhưng đây là danh sách các công nghệ có thể không có trên một nền tảng cụ thể. Bạn có thể cho rằng mọi thứ không được liệt kê ở đây đều khả dụng (vui lòng gửi cho tôi các chỉnh sửa cho những thứ tôi bỏ lỡ):

Core Runtime Engine [ở mọi nơi]

  • Reflection.Emit Support [ở mọi nơi, ngoại trừ WP7, CF, Xbox, MonoTouch, PS3]
  • Hỗ trợ CPU SIMD [Linux, BSD, Solaris, MacOS X; Sắp có PS3, MonoTouch và MonoDroid]
  • Tiếp tục - Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
  • Dỡ bỏ hội [chỉ dành cho Windows]
  • VM tiêm [Linux, BSD, MacOS X, Solaris]
  • DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
  • Generics [một số hạn chế trên PS3 và iPhone].

Ngôn ngữ

  • C # 4 [ở mọi nơi]
  • Trình biên dịch C # dưới dạng dịch vụ (Linux, MacOS, Solaris, BSD, Android)
  • IronRuby [ở mọi nơi, thực hiện WP7, CF, Xbox, MonoTouch, PS3]
  • IronPython [ở mọi nơi, thực hiện WP7, CF, Xbox, MonoTouch, PS3]
  • F # [ở mọi nơi, thực hiện WP7, CF, Xbox, MonoTouch, PS3]

Ngăn xếp máy chủ

  • ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
  • ADO.NET [ở mọi nơi]
  • LINQ to SQL [ở mọi nơi]
  • Khung thực thể [ở mọi nơi]
  • Ngăn xếp XML lõi [ở mọi nơi] [.__.]
    • Tuần tự hóa XML [ở mọi nơi, ngoại trừ WP7, CF, Xbox)
  • LINQ to XML (ở mọi nơi)
  • System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
  • System.Messaging [Windows; trên Linux, MacOS và Solaris yêu cầu RabbitMQ]
  • Dịch vụ doanh nghiệp .NET 1 [chỉ dành cho Windows]
  • WCF [hoàn thành trên Windows; tập hợp nhỏ trên Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid]
  • Dòng công việc Windows [chỉ dành cho Windows]
  • Nhận dạng không gian thẻ [chỉ dành cho Windows]

Ngăn xếp GUI

  • Silverlight (Windows, Mac, Linux - với Moonlight)
  • WPF (chỉ dành cho Windows)
  • Gtk # (Windows, Mac, Linux, BSD)
  • Windows.Forms (Windows, Mac, Linux, BSD)
  • MonoMac - Tích hợp Mac gốc (chỉ dành cho máy Mac)
  • MonoTouch - Tích hợp iPhone gốc (chỉ dành cho iPhone/iPad)
  • MonoDroid - Bản địa Android (chỉ dành cho Android)
  • API trung tâm truyền thông - Chỉ dành cho Windows
  • Sự lộn xộn (Windows và Linux)

Thư viện đồ họa

  • GDI + (Windows, Linux, BSD, MacOS)
  • Thạch anh (MacOS X, iPhone, iPad)
  • Cairo (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

Thư viện Mono - Đa nền tảng, có thể được sử dụng trong .NET nhưng yêu cầu xây dựng thủ công

  • Trình biên dịch C # 4 như một dịch vụ
  • Cecil - Thao tác CIL, quy trình làm việc, thiết bị của CIL, Linker
  • Thư viện thư giãn
  • Mono.Data. * Nhà cung cấp cơ sở dữ liệu
  • Full System.Xaml (để sử dụng trong các thiết lập trong đó .NET không cung cấp ngăn xếp)

MonoTouch có nghĩa là Mono chạy trên iPhone; MonoDroid có nghĩa là Mono chạy trên Android; Cổng PS3 và Wii chỉ dành cho các nhà phát triển đủ điều kiện của Sony và Nintendo.

Tôi xin lỗi vì sự thiếu hình thức.

195
miguel.de.icaza

Trước tiên, bạn cần phân biệt giữa Cơ sở hạ tầng ngôn ngữ chung (Tiêu chuẩn mở) và .NET (triển khai tiêu chuẩn đó của Microsoft). Mono là một triển khai của CLI và chưa bao giờ được coi là ".NET di động". Ngoài ra, ngôn ngữ C # là một tiêu chuẩn mở và không bị ràng buộc chặt chẽ với .NET.

Tôi không biết liệu Microsoft có bất kỳ công cụ nào để xác thực rằng việc triển khai có tuân thủ hay không, nhưng nếu có, tôi khá chắc chắn rằng những kẻ đơn điệu có nó và sử dụng nó.

Mono đang theo sau .Net, nhưng hầu như không. Mono có thể chạy mã C # 4.0 (phiên bản .NET hiện tại). Ngoài ra, Microsoft gần đây đã biến tất cả mã DLR và thư viện thành nguồn mở (theo giấy phép Apache 2.0), cho phép mono sử dụng các ngôn ngữ như IronPython, IronRuby và F # chỉ được tạo thành nguồn mở vào tuần trước. Ngoài ra, Microsoft thường xuyên phát hành CTP các tính năng sắp tới trong .NET, cho phép các nhà phát triển đơn nhân cập nhật các phiên bản phát hành hiện tại.

Có một số công cụ và tiện ích mở rộng trong .NET, ví dụ, Hợp đồng mã. Những điều này không phải luôn luôn được thực hiện đầy đủ trong đơn. (Hiện tại, tôi nghĩ rằng có một trình xác nhận hợp đồng một phần cho các hợp đồng Yêu cầu). Chúng không được sử dụng phổ biến trong các ứng dụng .NET, nhưng nếu mức độ phổ biến của chúng tăng lên, thì tốc độ chúng sẽ được thực hiện trong đơn âm.

WinForms không (hoàn toàn) di động. Chúng là một .NET cụ thể và không phải là một phần của CLI. CLI không chỉ định bất kỳ bộ widget cụ thể nào. Có các bộ widget đa nền tảng mặc dù (GTK # và Silverlight). Nếu bạn đang viết một ứng dụng từ đầu với tính di động, bạn sẽ sử dụng một trong số đó thay vì Winforms/WPF. Ngoài ra, mono cung cấp một trình bao bọc mỏng cho API Winforms - cho phép các ứng dụng winforms hiện có được chuyển dễ dàng hơn vào GTK # (không cần viết lại toàn bộ).

Mono cung cấp một công cụ, Trình phân tích di chuyển Mono (MoMA), có thể lấy một ứng dụng .Net hiện có và cho bạn biết về tính di động của nó. (ví dụ: xác định các thư viện không thể truy cập được sử dụng, P/Gọi, v.v.).

Đối với các doanh nghiệp không muốn phụ thuộc vào Nguồn mở - mono có thể được cấp phép lại. Quyền sở hữu mã được thêm vào mono được chuyển giao cho novell, người có thể cấp phép mã theo các cách khác ngoài giấy phép LGPL thông thường (dù sao cũng có rất ít hạn chế).

Vì vậy, đối với khiếu nại ".NET là di động", tôi nghĩ rằng đây có thể là một xác nhận hợp lệ nếu bạn đang viết mã từ đầu và nhận thức được các vấn đề về tính di động với khung. Nếu tuyên bố là "Tôi có một ứng dụng windows được viết bằng .NET, thì nó nên chạy trên đơn âm", nhưng không, đó không phải là một yêu cầu hợp lệ - nhưng Mono đã nỗ lực để chuyển các ứng dụng đó đơn giản hơn.

115
Mark H

Từng điểm:

  • OpenJDK và tất cả các nhà cung cấp JVM đã cung cấp đã thông qua Sun TCK chính thức để đảm bảo mọi thứ hoạt động chính xác. Tôi không biết về việc Mono truyền Microsoft TCK.
    [.__.] Có một đặc điểm kỹ thuật mà Microsoft CLR tuân thủ. Mono không phải là một bản sao của CLR của Microsoft, mà là một triển khai của đặc điểm kỹ thuật tương tự. Một mặt, có khả năng điều này dẫn đến sự không tương thích thậm chí còn lớn hơn. Trong thực tế, điều này đã làm việc rất tốt cho mono.
  • Mono theo dõi các bản phát hành .NET. Cấp độ .NET nào hiện được hỗ trợ đầy đủ?
    [.__.] Vì tài liệu dành cho .Net có trước bản phát hành thực tế, nên mono thực sự đã hoàn thành (không phải bản beta) hỗ trợ cho .Net 4 out trước bản phát hành chính thức của Microsoft. Ngoài ra, mono làm rất tốt việc ghi lại những thứ không được hỗ trợ và họ có một vài công cụ bạn có thể chạy với dự án hiện tại để giúp bạn phát hiện ra những nơi có khả năng không tương thích.
  • Tất cả các thành phần GUI (WinForms?) Có hoạt động chính xác trong Mono không?
    [.__.] Phần lớn các winforms hoạt động tốt. WPF, không quá nhiều. Tôi đã nghe nói điều tương tự cũng đúng với Java - nhiều bộ công cụ tiện ích/gui nâng cao không được hỗ trợ tốt trên tất cả các nền tảng.
  • Các doanh nghiệp có thể không muốn phụ thuộc vào các khung nguồn mở như kế hoạch chính thức B.
    [.__.] Nếu đó là trường hợp, họ chắc chắn sẽ không đồng ý với Java, vì điều đó đặt khung công tác nguồn mở lên cao hơn nữa ở kế hoạch A.

Tóm lại, nếu bạn muốn xây dựng một ứng dụng đa nền tảng ngay bây giờ , không có gì sai khi bắt đầu với mono từ việc di chuyển và sử dụng như là khuôn khổ của bạn. Bạn thậm chí có thể triển khai mono trên Windows nếu bạn muốn.

Mặt khác, nếu bạn đang xem xét việc xây dựng một ứng dụng Windows ngày hôm nay mà bạn nghĩ có thể cần phải là nền tảng chéo tại một số điểm chưa biết trong trong tương lai, bạn có thể muốn đi với các công cụ và tiện ích Windows gốc. .Net thực hiện công việc tốt hơn nhiều so với Java và mono là một sự hoàn toàn chấp nhận được trong kịch bản này.

Nói cách khác: Có, .Net nếu đa nền tảng theo mọi cách quan trọng đối với câu hỏi của bạn. Không, mono sẽ không chạy mọi chương trình .Net, nhưng câu hỏi của bạn nằm trong bối cảnh của một dự án mới. Sẽ không mất nhiều công sức để giữ cho các dự án mới không gặp rắc rối và tránh các vấn đề tương thích, đặc biệt nếu bạn nghĩ về việc phát triển cho đơn âm hơn là phát triển cho .Net.

Hầu hết tất cả, mặc dù, tôi nghĩ rằng đây là câu hỏi sai ở nơi đầu tiên. Trừ khi bạn xây dựng một nhóm phát triển mới từ đầu, bạn sẽ bắt đầu với các lập trình viên có chuyên môn trong lĩnh vực này hoặc lĩnh vực khác. Kết quả tốt nhất của bạn sẽ đạt được bằng cách đi với những gì lập trình viên của bạn đã biết. Quan trọng như việc xây dựng một ứng dụng đa nền tảng có vẻ như, nếu bạn có một nhóm đầy đủ các lập trình viên .Net có ít kinh nghiệm Java, bạn sẽ không thể kích hoạt chúng hoặc khiến tất cả học hỏi Java cho dự án tiếp theo của bạn. Nếu bạn có một nhóm gồm đầy đủ các lập trình viên Java, bạn sẽ không yêu cầu họ học .Net cho một dự án chỉ dành cho Windows. Một trong số đó sẽ là các loại hạt.

14
Joel Coehoorn

Tôi đã làm việc với Mono và tôi sẽ nói rằng nó tốt như bạn có thể có với một nền tảng thay thế là nguồn mở và không được Microsoft hỗ trợ trực tiếp. Nếu bạn có thể thoải mái sử dụng nền tảng thay thế nguồn mở như Clojure hoặc Scala, có lẽ bạn có thể thoải mái khi sử dụng Mono.

Mức độ .NET được hỗ trợ bởi Mono luôn có thể được tìm thấy trên trang Mono Roadmap .

Tất cả các yếu tố GUI có hoạt động không? Theo như tôi biết, họ làm, mặc dù tôi chưa thử hết mọi yếu tố.

Mono có giống với .NET không? Không. Tôi nghi ngờ sẽ có những điều chỉnh nhỏ (và có thể chính) được yêu cầu ở đây và đó. Hiện tại, bạn không thể chạy Entity Framework với nó.

11
Robert Harvey

Là mục tiêu, vũ trụ .NET/mono di chuyển rất nhanh .

Cứ sau vài năm, Microsoft lại đưa ra một số thay đổi và đổi mới hấp dẫn liên quan đến ngôn ngữ, thời gian chạy và cơ sở hạ tầng xung quanh .NET. Ví dụ: Generics, LINQ, DLR, Entity Framework - với mỗi phiên bản mới của Visual Studio, nhìn chung có sự gia tăng khá đáng kể về bộ tính năng và tính hữu dụng của khung mà nó nhắm tới.

Mặc dù cải tiến liên tục trong khung được hoan nghênh, nhưng cũng có vấn đề nếu bạn muốn tương thích trên nhiều nền tảng. Các nền tảng hỗ trợ dài hạn như Red Hat Enterprise Linux di chuyển chậm chạp liên quan đến việc áp dụng công nghệ mới và tại bất kỳ thời điểm nào, sẽ có những cải tiến đáng kể trong nền tảng Mono đã xảy ra chỉ trong vài tháng qua. Vì vậy, nếu bạn muốn chạy những thứ mà những đứa trẻ tuyệt vời đang xây dựng, bạn sẽ phải biên dịch Mono từ đầu và quản lý các bản vá và cập nhật của riêng bạn. Điều đó không tuyệt.

Mặt khác, Java cũng trì trệ như một nhóm trẻ con. Đặc biệt bây giờ nó thuộc sở hữu của một công ty chỉ muốn Java cho các vụ kiện bằng sáng chế, bạn có thể khá chắc chắn rằng sẽ không có thay đổi có thể phát hiện được trong ngôn ngữ hoặc thời gian chạy trong tương lai gần. Java là nền tảng ổn định như FORTRAN. Điều đó không tốt nếu bạn hy vọng vào bất kỳ loại nào cải thiện, nhưng không tệ lắm nếu bạn đang cố gắng triển khai một ứng dụng doanh nghiệp.

9
tylerl

Từ góc độ người dùng, Mono rất thích làm cho các ứng dụng Windows .NET tương thích với Linux. Nếu bạn thực sự cố gắng chạy bất kỳ ứng dụng Windows được viết nào trong Mono thì nó sẽ không hoạt động.

Từ quan điểm của một người đóng gói (tôi đã từng làm một chút công việc tại PortableApps), .NET có thể vừa là một phước lành vừa là một lời nguyền. Nếu bạn chỉ sử dụng Windows, .NET giúp triển khai dễ dàng hơn nhiều vì nhiều thư viện hơn có nghĩa là ít phụ thuộc hệ thống hơn (đáng chú ý nhất là giữa các phiên bản Windows, tôi tin) nhưng cũng cực kỳ khó hiểu ngay cả trên Windows vì các phiên bản .NET không bị ngược tương thích hoặc tương thích chuyển tiếp. Bạn phải tải xuống các phiên bản .NET khác nhau cho các chương trình khác nhau.

Điều đó nói rằng, Mono là một điểm khởi đầu tốt để làm cho các chương trình C # đa nền tảng. Chỉ cần không đóng gói chương trình với RƯỢU mới nhất và gọi nó là xong. Hãy xem Picasa đã lấy đâu.

Cũng như sự ổn định chính trị của hai ngôn ngữ/nền tảng, RMS có thể sẽ bắt đầu ca ngợi về cách Mono đứng đầu bởi Novell, người có tuần trăng mật với Microsoft khá khét tiếng. Cả hai nền tảng có thể được coi là không ổn định về mặt chính trị ngay bây giờ .

Nếu bạn thực sự muốn đa nền tảng dễ dàng, con đường đã thử và đúng là QT khá ổn định về mặt chính trị cho đến thời điểm hiện tại, đó là một) LGPL'd, b) được thực hiện với các vấn đề cấp phép chính của nó trong nhiều năm qua và c) được Nokia hỗ trợ, nơi bán điện thoại thực sự phổ biến.

7
digitxp

Mono không phải là cổng 1: 1 của Microsoft .net. Có những công nghệ mà Mono đơn giản sẽ không thực hiện hoặc không có kế hoạch để làm điều đó (ví dụ: Workflow Foundation hoặc WPF ) trong khi mặt khác họ có một số các công nghệ của riêng họ mà Microsoft .NET không làm, ví dụ: Tiện ích mở rộng SIMD.

Trả lời ngắn: Mono và Microsoft .NET dựa trên cùng một nền tảng cơ bản - CIL và BCL - nhưng là các dự án riêng biệt.

4
Michael Stum

Bình luận nhỏ cho các tuyên bố trong bài viết gốc. Tôi sẽ lập luận rằng TCK vẫn là một công cụ lý thuyết cho phép Oracle yêu cầu Java là một tiêu chuẩn mở. Bởi vì nếu bạn chú ý, Apache Harmony đã cố gắng để được chứng nhận là "Java" trong vài năm nay, không thành công. Rõ ràng là Oracle thực sự không quan tâm đến việc triển khai nguồn mở ngoài việc họ liên kết với và kiểm soát ít nhiều (OpenJDK), mà btw. giống như Mono, chưa hoàn tất (nghĩa là không Java Hỗ trợ Bắt đầu Web) và thiếu một số tối ưu hóa có sẵn trong triển khai HotSpot nguồn đóng.

Có thể nói, như năm 2010; (hầu hết) Java là nguồn mở nhưng không phải là một tiêu chuẩn mở, trong khi (hầu hết) .NET không phải là nguồn mở mà là một tiêu chuẩn mở. Tất nhiên, có những ngoại lệ, DLR, IronPython, IronRuby và F # thực sự là nguồn mở. Mono rất thú vị vì nó cung cấp tốt nhất cả hai thế giới, triển khai nguồn mở của các tiêu chuẩn mở.

2
Casper Bang

Đặt tất cả các kỹ thuật sang một bên, một phần rất quan trọng diễn ra khi thực sự viết mã.

Như với bất kỳ công nghệ đa nền tảng nào (có thể là Java, Python, Ruby ...), nếu mã không được viết với tính di động, bạn nên cho rằng về cơ bản không có mã nào sẽ chạy đúng (ngay cả khi cơ hội như vậy là trong thực tế nhiều, cao hơn nhiều), vì hành vi sai trái kỳ quặc có thể khá nghiêm trọng. Đọc: không lấy hội ngẫu nhiên và chạy nó dưới Mono.

Tuy nhiên, đối với một dự án mới (hoặc một dự án bạn có thể tái cấu trúc một cách dễ dàng), chọn .Net/Mono làm thời gian chạy có khả năng di động có ý nghĩa, nhưng bạn tiết kiệm cho mình rất nhiều rắc rối bằng cách kiểm tra mã của bạn trên Mono từ rất sớm, ngay cả khi dự án có chỉ một thay đổi nhỏ của đi đa nền tảng. Nếu bạn sử dụng máy chủ tích hợp liên tục, việc này có thể đơn giản như thiết lập nút xây dựng Mono. Nhiều vấn đề có thể được giải quyết trong khi phát triển, chỉ bằng cách tạo thói quen từ nó (như xây dựng chuỗi đường dẫn) và một đoạn mã lớn của bạn có thể được di động và kiểm tra đơn vị trên Mono chỉ bằng cách sử dụng các thực hành lành mạnh và một chút suy nghĩ trước. Phần còn lại (nghĩa là không thử nghiệm đơn vị) sau đó là dành riêng cho nền tảng (như mã sử dụng PInvoke) nhưng phải được gói gọn đủ để có thể cung cấp triển khai thay thế cho mỗi nền tảng được nhắm mục tiêu. Bằng cách này, khi dự án cuối cùng được chuyển sang một phần tốt của công việc đã được thực hiện mà hầu như không mất phí và phần còn lại sẽ được phát triển Just In Time.

Tất nhiên, sử dụng thư viện không có sẵn (.Net) hoặc tương thích (bên thứ ba) trong Mono loại trừ bất kỳ thứ gì trong số này, nhưng trong trường của tôi điều này vẫn chưa được nhìn thấy. Đó là chiến lược chúng tôi thực sự sử dụng trong công việc và khi áp dụng nó, tôi không sợ phải tuyên bố rằng .Net + Mono là nền tảng chéo.

1
Lloeki

Nó thay đổi là câu trả lời trung thực. Tôi đã thấy các công cụ máy chủ web nhỏ được chuyển từ IIS sang Apache, chạy dưới dạng đơn điệu mà hầu như không gặp khó khăn gì. Tôi đã chạy các ứng dụng Windows .Net không thay đổi bằng Win Forms trên Linux thành công.

Tuy nhiên, trong khi nó có thể hoạt động, nếu bạn đang sử dụng lệnh gọi API không được triển khai trên đơn âm thì nó sẽ không hoạt động và các giải pháp duy nhất là viết lại ứng dụng của bạn, gắn với các cửa sổ hoặc viết các nội dung bổ sung bằng đơn.

0
Michael Shaw