Mono đã sẵn sàng cho thời gian chính? [đóng cửa]

Có ai đã sử dụng Mono, triển khai .NET nguồn mở trên một dự án lớn hoặc vừa chưa? Tôi tự hỏi nếu nó đã sẵn sàng cho thế giới thực, môi trường sản xuất. Nó có ổn định, nhanh, tương thích, ... đủ để sử dụng không? Có phải mất rất nhiều nỗ lực để chuyển các dự án sang thời gian chạy Mono hay nó thực sự, thực sự đủ tương thích để chỉ lấy và chạy mã đã được viết cho thời gian chạy của Microsoft?

Có một vài tình huống cần xem xét: (a) nếu bạn đang chuyển một ứng dụng hiện có và tự hỏi liệu Mono có đủ tốt cho nhiệm vụ này không; (b) bạn đang bắt đầu viết một số mã mới và bạn muốn biết liệu Mono đã đủ trưởng thành chưa.

Đối với trường hợp đầu tiên, bạn có thể sử dụng công cụ Phân tích di chuyển Mono (Moma) để đánh giá ứng dụng của bạn chạy được bao xa trên Mono. Nếu đánh giá trở lại với màu sắc bay, bạn nên bắt đầu thử nghiệm và QA của mình và sẵn sàng giao hàng.

Nếu đánh giá của bạn trở lại với một tính năng làm nổi bật báo cáo bị thiếu hoặc khác biệt đáng kể về ngữ nghĩa của chúng trong Mono, bạn sẽ phải đánh giá xem mã có thể được điều chỉnh, viết lại hoặc trong trường hợp xấu nhất là ứng dụng của bạn có thể hoạt động với chức năng giảm hay không.

Theo thống kê Moma của chúng tôi dựa trên nội dung gửi của người dùng (đây là từ bộ nhớ), khoảng 50% ứng dụng hoạt động tốt, khoảng 25% yêu cầu công việc trị giá khoảng một tuần (tái cấu trúc, điều chỉnh) 15% khác yêu cầu cam kết nghiêm túc làm lại các đoạn mã của bạn và phần còn lại không đáng để làm phiền việc chuyển vì chúng rất gắn liền với Win32. Tại thời điểm đó, hoặc bạn bắt đầu từ số không, hoặc một quyết định kinh doanh sẽ thúc đẩy nỗ lực làm cho mã của bạn có thể mang theo được, nhưng chúng tôi đang nói về công việc đáng giá hàng tháng (ít nhất là từ các báo cáo chúng tôi có).

Nếu bạn đang bắt đầu từ đầu, tình hình sẽ đơn giản hơn rất nhiều, vì bạn sẽ chỉ sử dụng các API có trong Mono. Miễn là bạn ở lại với ngăn xếp được hỗ trợ (khá nhiều .NET 2.0, cộng với tất cả các nâng cấp cốt lõi trong 3.5 bao gồm LINQ và System.Core, cộng với bất kỳ API đa nền tảng Mono nào), bạn sẽ ổn.

Thỉnh thoảng bạn có thể gặp phải các lỗi trong Mono hoặc các giới hạn và bạn có thể phải làm việc xung quanh chúng, nhưng điều đó không khác so với bất kỳ hệ thống nào khác.

Về tính di động: Các ứng dụng ASP.NET là những ứng dụng dễ dàng hơn để chuyển, vì chúng không phụ thuộc nhiều vào Win32 và thậm chí bạn có thể sử dụng máy chủ SQL hoặc các cơ sở dữ liệu phổ biến khác (có rất nhiều nhà cung cấp cơ sở dữ liệu đi kèm với Mono).

Việc chuyển Windows.Forms đôi khi khó khăn hơn vì các nhà phát triển muốn thoát khỏi hộp cát .NET và P / Gọi bộ não của họ ra để cấu hình mọi thứ hữu ích như thay đổi tốc độ nhấp nháy của con trỏ được biểu thị dưới dạng hai điểm bezier được mã hóa dưới dạng BCD trong wParam. Hoặc một số rác như thế.

Nó có phạm vi bảo hiểm khá rộng lên đến .NET 4.0 và thậm chí bao gồm một số tính năng từ API .NET 4.5, nhưng có một số lĩnh vực chúng tôi đã chọn không triển khai do các API bị phản đối, các lựa chọn thay thế mới được tạo ra hoặc phạm vi quá lớn. Các API sau không có sẵn trong Mono:

• Windows Presentation Foundation
• Windows Workflow Foundation (cả hai phiên bản)
• Khuôn khổ thực
• "Tiện ích" WSE1 / WSE2 cho ngăn xếp Dịch vụ Web tiêu chuẩn

Ngoài ra, việc triển khai WCF của chúng tôi bị giới hạn ở những gì Silverlight hỗ trợ.

Cách dễ nhất để kiểm tra dự án cụ thể của bạn là chạy Trình phân tích di chuyển Mono (MoMA) . Lợi ích là nó sẽ thông báo cho nhóm Mono về các vấn đề sẽ ngăn bạn sử dụng Mono (nếu có), cho phép họ ưu tiên công việc của họ.

Gần đây tôi đã chạy MoMA trên SubSonic và chỉ tìm thấy một vấn đề - một cách sử dụng kỳ lạ các loại Nullable. Đó là một cơ sở mã lớn, nên độ phủ sóng ở đó khá ấn tượng.

Mono đang được sử dụng tích cực trong một số sản phẩm thương mại cũng như nguồn mở . Nó được sử dụng trong một số ứng dụng lớn, như Wikipedia và Mozilla Developer Center , và đã được sử dụng trong các ứng dụng nhúng như máy nghe nhạc Sansa MP3 và cung cấp cho hàng ngàn trò chơi được xuất bản.

Ở cấp độ ngôn ngữ, trình biên dịch Mono hoàn toàn tuân thủ đặc tả ngôn ngữ C # 5.0 .

Về phía máy tính để bàn, Mono hoạt động rất tốt nếu bạn cam kết sử dụng GTK #. Việc triển khai Windows.Forms vẫn còn một chút lỗi (ví dụ: KhayIcon không hoạt động) nhưng nó đã đi được một chặng đường dài. Bên cạnh đó, GTK # là một bộ công cụ tốt hơn so với Windows Forms.

Về phía web, Mono đã triển khai đủ ASP.NET để chạy hầu hết các trang web một cách hoàn hảo. Khó khăn ở đây là tìm một máy chủ có cài đặt mod_mono trên apache hoặc tự làm nếu bạn có quyền truy cập shell vào máy chủ của mình.

Dù bằng cách nào, Mono là tuyệt vời và ổn định.

Những điều quan trọng cần nhớ khi tạo một chương trình đa nền tảng:

• Sử dụng GTK # thay vì Windows.Forms
• Đảm bảo đúng trường hợp tên tệp của bạn
• Sử dụng Path.Separatorthay vì mã hóa "\", cũng sử dụng Environment.NewLinethay vì "\n".
• Không sử dụng bất kỳ cuộc gọi P / được gọi nào tới API Win32.
• Không sử dụng Windows Registry.

Cá nhân tôi sử dụng Mono trong một env thời gian đầu. Tôi chạy các máy chủ đơn xử lý các giga-byte của các tác vụ liên quan đến xử lý dữ liệu udp / tcp và không thể hạnh phúc hơn.

Có những điểm đặc biệt và một trong những điều khó chịu nhất là bạn không thể "xây dựng" các tệp msbuild của mình do trạng thái hiện tại của Mono:

• MonoDevelop (IDE) có một số hỗ trợ msbuild một phần, nhưng về cơ bản sẽ hỗ trợ cho bất kỳ bản dựng "THỰC SỰ" nào ngoài thế giới đơn giản (tác vụ xây dựng tùy chỉnh, "thuộc tính động" như $ (SolutionDir), cấu hình thực để đặt tên cho một số người chết -ends)
• xbuild mà NÊN đã là hệ thống xây dựng tương thích hoàn toàn đơn cung cấp msbuild thậm chí còn kinh khủng hơn, do đó, xây dựng từ dòng lệnh thực sự là một trải nghiệm tồi tệ hơn so với sử dụng GUI, một trạng thái rất "không chính thống" của liên minh cho môi trường Linux ...

Một lần / Trong khi nhận được công cụ của bạn thực sự BUILT, bạn có thể thấy một số vùng hoang dã ngay cả đối với mã NÊN được hỗ trợ như:

• trình biên dịch bị borked trên các cấu trúc nhất định
• và một số lớp .NET nâng cao / mới hơn nhất định ném vào bạn những thứ không mong đợi (XLinq có ai không?)
• một số "tính năng" thời gian chạy chưa trưởng thành (giới hạn heap 3 GB TRÊN x64 ... WTF!)

nhưng ông nói rằng nói chung mọi thứ bắt đầu hoạt động rất nhanh và giải pháp / cách giải quyết rất phong phú .

Khi bạn đã vượt qua những rào cản ban đầu đó, kinh nghiệm của tôi là ROCKS đơn điệu và tiếp tục tốt hơn với mỗi lần lặp .

Tôi đã có các máy chủ chạy với mono, xử lý 300GB dữ liệu mỗi ngày, với hàng tấn p / invoke và nói chung là thực hiện RẤT NHIỀU công việc và duy trì UP trong 5-6 tháng, ngay cả với đơn âm "chảy máu".

Hi vọng điêu nay co ich.

Các khuyến nghị cho câu trả lời được chấp nhận là một chút lỗi thời bây giờ.

• Các hình thức cửa sổ thực hiện là khá tốt bây giờ. (Xem Paint-Mono cho một cổng của Paint.net, một ứng dụng biểu mẫu Windows có liên quan khá nhiều. Tất cả những gì được yêu cầu là một lớp mô phỏng cho một số cuộc gọi hệ thống P-Invoke và không được hỗ trợ).
• Path.Combine cũng như Path.Seperator để tham gia các đường dẫn và tên tệp.
• Windows Registry vẫn ổn, miễn là bạn chỉ sử dụng nó để lưu trữ và truy xuất dữ liệu từ các ứng dụng của mình (tức là bạn không thể lấy bất kỳ thông tin nào về Windows từ nó, vì về cơ bản nó là một sổ đăng ký cho các ứng dụng Mono).

Nếu bạn muốn sử dụng WPF, bạn không gặp may, Mono hiện không có kế hoạch triển khai nó.

http://www.mono-project.com/WPF

Chà, mono là tuyệt vời, nhưng theo như tôi thấy, nó không ổn định. Nó hoạt động, nhưng lỗi khi bạn đưa ra quy trình đơn sắc một công việc nghiêm túc phải làm.

TL; DR - Không sử dụng đơn âm nếu bạn:

• sử dụng AppDomains (Tải hội \ Unload) trong môi trường đa luồng
• Không thể duy trì mô hình 'let-it-fail'
• Trải nghiệm các sự kiện tải nặng thường xuyên trong quá trình chạy

Vì vậy, sự thật.

Chúng tôi sử dụng mono-2.6.7 (.net v 3.5) trên RHEL5, Ubuntu và theo quan điểm của tôi, đây là phiên bản ổn định nhất được chế tạo bởi Novell. Nó có vấn đề với Unloading AppDomains (segfaults), tuy nhiên, nó rất hiếm khi xảy ra và điều này, cho đến nay, có thể chấp nhận được (bởi chúng tôi).

Được chứ. Nhưng nếu bạn muốn sử dụng các tính năng của .net 4.0, bạn phải chuyển sang phiên bản 2.10.x hoặc 3.x và đó là nơi bắt đầu có vấn đề.

So với 2.6.7, các phiên bản mới không được chấp nhận để sử dụng. Tôi đã viết một ứng dụng kiểm tra căng thẳng đơn giản để kiểm tra cài đặt đơn.

Nó ở đây, với hướng dẫn sử dụng: https://github.com/head-thrash/stress_test_mono

Nó sử dụng Thread Pool Worker Themes. Công nhân tải dll vào AppDomain và cố gắng thực hiện một số công việc toán học. Một số công việc là nhiều luồng, một số là độc thân. Hầu như tất cả các công việc đều bị ràng buộc bởi CPU, mặc dù có một số lần đọc các tệp từ đĩa.

Kết quả không tốt lắm. Trên thực tế, đối với phiên bản 3.0.12:

• quá trình phân tách sgen GC gần như ngay lập tức
• mono với boehm sống lâu hơn (từ 2 đến 5 giờ), nhưng cuối cùng segfaults

Như đã đề cập ở trên, sgen gc chỉ không hoạt động (mono được xây dựng từ nguồn):

* Assertion: should not be reached at sgen-scan-object.h:111

Stacktrace:


Native stacktrace:

    mono() [0x4ab0ad]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0]
    /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425]
    /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b]
    mono() [0x62b49d]
    mono() [0x62b5d6]
    mono() [0x5d4f84]
    mono() [0x5cb0af]
    mono() [0x5cb2cc]
    mono() [0x5cccfd]
    mono() [0x5cd944]
    mono() [0x5d12b6]
    mono(mono_gc_collect+0x28) [0x5d16f8]
    mono(mono_domain_finalize+0x7c) [0x59fb1c]
    mono() [0x596ef0]
    mono() [0x616f13]
    mono() [0x626ee0]
    /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a]
    /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd]

Đối với boehm segfauls - ví dụ (Ubuntu 13.04, mono được xây dựng từ nguồn):

mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed.
Stacktrace:
at <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264
at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222
at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto
Config.cs:582
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo
nfig.cs:473
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492

Hoặc (RHEL5, mono được lấy từ rpm đây ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5 )

Assertion at mini.c:3783, condition `code' not met
Stacktrace:
at <unknown> <0xffffffff>
at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394
at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429
at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271
at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346
at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog
raphy/CryptoConfig.cs:475
at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457
at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495
at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484
at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59
at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53
at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483
at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356
at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329
at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363

Cả hai lỗi đều được kết nối với logic AppDomains, vì vậy, bạn nên tránh xa chúng trong chế độ đơn âm.

BTW, chương trình đã thử nghiệm hoạt động 24 giờ trên máy Windows trong MS .NET 4.5 env mà không gặp sự cố nào.

Vì vậy, để kết luận, tôi muốn nói - sử dụng mono một cách thận trọng. Nó hoạt động từ cái nhìn đầu tiên, nhưng có thể dễ dàng thất bại bất cứ khi nào. Bạn sẽ bị bỏ lại với một loạt các bãi rác cốt lõi và mất niềm tin lớn trong các dự án nguồn mở.

MoMA là một công cụ tuyệt vời cho việc này, như một người khác đề xuất. Các nguồn không tương thích lớn nhất hiện nay là các ứng dụng DLLImport (hoặc P / Invoke) vào các thư viện Win32. Một số hội đồng không được triển khai, nhưng hầu hết trong số chúng chỉ dành cho Windows và thực sự không có ý nghĩa gì với Linux. Tôi nghĩ khá an toàn khi nói rằng hầu hết các ứng dụng ASP.NET có thể chạy trên Mono với các sửa đổi hạn chế.

(Tiết lộ: Tôi đã đóng góp cho chính Mono, cũng như các ứng dụng bằng văn bản chạy trên nó.)

Trong nhiều trường hợp, bạn có thể lấy mã hiện có và chỉ chạy nó trên Mono, đặc biệt nếu bạn đang chuyển một ứng dụng ASP.NET.

Trong một số trường hợp, bạn có thể yêu cầu toàn bộ các phần mã mới để làm cho nó hoạt động. Ví dụ: nếu bạn sử dụng System.Windows.Forms, ứng dụng sẽ không hoạt động. Tương tự như vậy nếu bạn sử dụng bất kỳ mã cụ thể nào của Windows (ví dụ mã truy cập đăng ký). Nhưng tôi nghĩ người phạm tội tồi tệ nhất là mã UI. Điều đó đặc biệt tệ trên các hệ thống Macintosh.

Chúng tôi đã sử dụng nó cho một dự án ở đây tại nơi làm việc cần chạy trên Linux nhưng sử dụng lại một số thư viện .NET mà chúng tôi xây dựng trong Managed C ++. Tôi đã rất ngạc nhiên về việc nó đã hoạt động tốt như thế nào. Phần thực thi chính của chúng tôi đang được viết bằng C # và chúng tôi chỉ có thể tham khảo các tệp nhị phân Managed C ++ của mình mà không gặp vấn đề gì. Sự khác biệt duy nhất trong mã C # giữa Windows và Linux là mã cổng nối tiếp RS232.

Vấn đề lớn duy nhất tôi có thể nghĩ đến đã xảy ra khoảng một tháng trước. Bản dựng Linux có rò rỉ bộ nhớ không thấy trên bản dựng Windows. Sau khi thực hiện một số gỡ lỗi thủ công (các trình biên dịch cơ bản cho Mono trên Linux không giúp được gì nhiều), chúng tôi đã có thể thu hẹp vấn đề xuống một đoạn mã cụ thể. Chúng tôi cuối cùng đã vá một cách giải quyết, nhưng tôi vẫn cần tìm một chút thời gian để quay lại và tìm hiểu nguyên nhân gốc rễ của sự rò rỉ là gì.

Bạn có biết hỗ trợ xem trước Mono 2.0 tốt như thế nào cho Windows Forms 2.0 không?

Từ một chút mà tôi đã chơi với nó, nó dường như tương đối hoàn chỉnh và gần như có thể sử dụng được. Nó chỉ không nhìn đúng ở một số nơi và vẫn còn một chút hoặc bỏ lỡ tổng thể. Nó làm tôi ngạc nhiên rằng nó hoạt động tốt như nó đã làm với một số hình thức của chúng tôi, mặc dù trung thực.

Vâng, chắc chắn là vậy (nếu bạn cẩn thận) Chúng tôi hỗ trợ Mono trong Ra-Ajax (thư viện Ajax được tìm thấy tại http://ra-ajax.org ) và chúng tôi hầu như không gặp vấn đề gì. Bạn cần cẩn thận với một số "điều điên rồ nhất" từ .Net như WSE, v.v. và cũng có thể một số dự án hiện tại của bạn sẽ không tương thích 100% với Mono, nhưng các dự án mới nếu bạn thử nghiệm chúng trong quá trình phát triển sẽ chủ yếu tương thích mà không gặp vấn đề với Mono. Và lợi ích từ việc hỗ trợ Linux, v.v. thông qua việc sử dụng Mono thực sự rất tuyệt;)

Một phần lớn bí mật của việc hỗ trợ Mono tôi nghĩ là sử dụng đúng công cụ ngay từ đầu, ví dụ như ActiveRecord, log4net, ra-ajax, v.v.

Đối với loại ứng dụng chúng tôi đang xây dựng, Mono không may dường như chưa sẵn sàng để sản xuất. Chúng tôi đã rất ấn tượng với tổng thể và ấn tượng với hiệu suất của nó trên cả Windows và trên các máy EC2, tuy nhiên, chương trình của chúng tôi bị lỗi liên tục với các lỗi thu gom rác trên cả Windows và linux.

Thông báo lỗi là: "lỗi nghiêm trọng trong GC: quá nhiều phần heap", đây là một liên kết đến người khác gặp vấn đề theo một cách hơi khác:

http://ormszilla.novell.com/show_orms.cgi?id=435906

Đoạn mã đầu tiên chúng tôi chạy trong Mono là một thử thách lập trình đơn giản mà chúng tôi đã phát triển ... Mã này tải khoảng 10mb dữ liệu vào một số cấu trúc dữ liệu (ví dụ HashSets), sau đó chạy 10 truy vấn đối với dữ liệu. Chúng tôi đã chạy các truy vấn 100 lần để tính thời gian cho chúng và lấy trung bình.

Mã bị lỗi xung quanh truy vấn thứ 55 trên Windows. Trên linux nó hoạt động, nhưng ngay khi chúng tôi chuyển sang một tập dữ liệu lớn hơn, nó cũng sẽ bị sập.

Mã này rất đơn giản, ví dụ: đặt một số dữ liệu vào HashSets và sau đó truy vấn các HashSets đó, v.v., tất cả c # gốc, không có gì không an toàn, không có lệnh gọi API. Trên Microsoft CLR, nó không bao giờ gặp sự cố và chạy trên bộ dữ liệu khổng lồ 1000 lần rất tốt.

Một trong những người của chúng tôi đã gửi email cho Miguel và bao gồm mã gây ra vấn đề, chưa có phản hồi. :

Có vẻ như nhiều người khác đã gặp phải vấn đề này mà không có giải pháp - một giải pháp đã được đề xuất để biên dịch lại Mono với các cài đặt GC khác nhau nhưng điều đó dường như làm tăng ngưỡng trước khi nó gặp sự cố.

Chỉ cần kiểm tra www.platicscm.com. Mọi thứ (máy khách, máy chủ, GUI, công cụ hợp nhất) được viết trên đơn sắc.

Nó thực sự phụ thuộc vào không gian tên và các lớp mà bạn đang sử dụng từ .NET framework. Tôi đã quan tâm đến việc chuyển đổi một trong các dịch vụ windows của mình để chạy trên máy chủ email của mình, đó là Suse, nhưng chúng tôi đã gặp phải một số trở ngại lớn với các API chưa được triển khai hoàn toàn. Có một biểu đồ ở đâu đó trên trang web Mono liệt kê tất cả các lớp và mức độ hoàn thành của chúng. Nếu ứng dụng của bạn được bảo hiểm, sau đó đi cho nó.

Giống như bất kỳ ứng dụng nào khác, tất nhiên hãy tạo mẫu và thử nghiệm trước khi bạn cam kết đầy đủ.

Một vấn đề khác mà chúng tôi gặp phải là phần mềm được cấp phép: nếu bạn đang tham khảo DLL của người khác, bạn không thể mã hóa theo cách không tương thích được chôn vùi trong hội đồng đó.

Tôi sẽ tưởng tượng sau đó nếu bạn có một ứng dụng với một số thành phần bên thứ 3, bạn có thể bị nhồi. Tôi nghi ngờ rất nhiều nhà cung cấp sẽ phát triển với Mono trong tâm trí

Ví dụ: http : //community.deve े. Com / forums / p / 505085 / 185853.aspx

Không, mono chưa sẵn sàng cho công việc nghiêm túc. Tôi đã viết một vài chương trình trên Windows bằng F # và chạy chúng trên Mono. Những chương trình đó sử dụng đĩa, bộ nhớ và cpu khá chuyên sâu. Tôi thấy các sự cố trong các thư viện đơn âm (mã được quản lý), sự cố trong mã gốc và sự cố trong máy ảo. Khi mono hoạt động, các chương trình chậm hơn ít nhất hai lần so với .Net trong Windows và sử dụng nhiều bộ nhớ hơn. Tránh xa mono cho công việc nghiêm túc.