هل مونو جاهز لوقت الذروة؟[مغلق]

https://stackoverflow.com/questions/18450

09-06-2019
|

سؤال

هل استخدم أحد تطبيق Mono، وهو تطبيق .NET مفتوح المصدر، في مشروع كبير أو متوسط الحجم؟أتساءل عما إذا كان جاهزًا للعالم الحقيقي وبيئات الإنتاج.هل هو مستقر، سريع، متوافق، ...يكفي للاستخدام؟هل يتطلب الأمر الكثير من الجهد لنقل المشاريع إلى وقت التشغيل Mono، أم أن الأمر كذلك حقًا؟ حقًا هل أنت متوافق بما يكفي لأخذ التعليمات البرمجية المكتوبة بالفعل وتشغيلها لوقت تشغيل Microsoft؟

المحلول

هناك بضعة سيناريوهات يجب مراعاتها:(أ) إذا كنت تقوم بتحديث تطبيق موجود وتتساءل عما إذا كان Mono جيدًا بما يكفي لهذه المهمة؛(ب) لقد بدأت في كتابة بعض التعليمات البرمجية الجديدة، وتريد معرفة ما إذا كان Mono ناضجًا بدرجة كافية.

بالنسبة للحالة الأولى، يمكنك استخدام أداة محلل الهجرة الأحادية (Moma) لتقييم مدى بعد تطبيقك عن التشغيل على Mono.إذا عاد التقييم بنجاح، فيجب عليك البدء في الاختبار وضمان الجودة والاستعداد للشحن.

إذا عاد تقييمك بتقرير يسلط الضوء على الميزات المفقودة أو التي تختلف بشكل كبير في دلالاتها في Mono، فسيتعين عليك تقييم ما إذا كان من الممكن تعديل التعليمات البرمجية أو إعادة كتابتها أو في أسوأ الحالات ما إذا كان تطبيقك يمكنه العمل بوظائف منخفضة.

وفقًا لإحصائيات Moma الخاصة بنا استنادًا إلى عمليات إرسال المستخدم (هذه من الذاكرة) فإن حوالي 50% من التطبيقات تعمل خارج الصندوق، ويتطلب حوالي 25% منها حوالي أسبوع من العمل (إعادة البناء والتكيف) و15% أخرى تتطلب التزامًا جادًا بـ قم بإعادة أجزاء من التعليمات البرمجية الخاصة بك، والباقي لا يستحق عناء النقل نظرًا لأنها مرتبطة بشكل لا يصدق بـ Win32.عند هذه النقطة، إما أن تبدأ من الصفر، أو أن قرار العمل سيدفع الجهود لجعل الكود الخاص بك قابلاً للحمل، ولكننا نتحدث عن أشهر من العمل (على الأقل من التقارير المتوفرة لدينا).

إذا كنت تبدأ من الصفر، فسيكون الوضع أبسط كثيرًا، لأنك ستستخدم فقط واجهات برمجة التطبيقات الموجودة في Mono.طالما بقيت مع المكدس المدعوم (وهو إلى حد كبير .NET 2.0، بالإضافة إلى جميع الترقيات الأساسية في 3.5 بما في ذلك LINQ وSystem.Core، بالإضافة إلى أي من واجهات برمجة التطبيقات أحادية النظام الأساسي) ستكون بخير.

قد تواجه بين الحين والآخر أخطاءً في Mono أو قيودًا، وقد يتعين عليك التغلب عليها، لكن هذا لا يختلف عن أي نظام آخر.

أما بالنسبة لقابلية النقل:تعد تطبيقات ASP.NET هي الأسهل في النقل، حيث أن تلك التطبيقات لديها القليل من التبعيات على Win32 أو لا تعتمد عليها على الإطلاق، ويمكنك أيضًا استخدام خادم SQL أو قواعد البيانات الشائعة الأخرى (يوجد الكثير من موفري قواعد البيانات المجمعة مع Mono).

يكون نقل Windows.Forms أكثر تعقيدًا في بعض الأحيان لأن المطورين يحبون الهروب من صندوق الحماية .NET وP/استدعاء أدمغتهم لتكوين أشياء مفيدة مثل تغيير معدل وميض المؤشر المعبر عنه بنقطتين بيزيير مشفرتين في نموذج BCD في wParam.أو بعض غير المرغوب فيه من هذا القبيل.

نصائح أخرى

يتمتع بتغطية واسعة جدًا تصل إلى .NET 4.0 ويتضمن أيضًا بعض الميزات من .NET 4.5 APIs، ولكن هناك بعض المجالات التي اخترنا عدم تنفيذها بسبب إهمال واجهات برمجة التطبيقات أو إنشاء بدائل جديدة أو النطاق أيضًا كبير.واجهات برمجة التطبيقات التالية غير متوفرة في Mono:

مؤسسة عرض ويندوز
Windows Workflow Foundation (أي من الإصدارين)
إطار كيان
"الوظائف الإضافية" WSE1/WSE2 لمجموعة خدمات الويب القياسية

بالإضافة إلى ذلك، يقتصر تطبيق WCF الخاص بنا على ما يدعمه Silverlight.

أسهل طريقة للتحقق من مشروعك المحدد هي تشغيل ملف محلل الهجرة الأحادية (MoMA).وتتمثل الفائدة في أنه سيتم إخطار فريق Mono بالمشكلات التي ستمنعك من استخدام Mono (إن وجدت)، مما يتيح لهم تحديد أولويات عملهم.

لقد قمت مؤخرًا بتشغيل MoMA على SubSonic ووجدت مشكلة واحدة فقط - الاستخدام الغريب للأنواع Nullable.إنها قاعدة بيانات كبيرة، لذا كانت التغطية هناك رائعة جدًا.

Mono قيد الاستخدام النشط في العديد من المنتجات التجارية وكذلك مفتوحة المصدر.يتم استخدامه في بعض التطبيقات الكبيرة، مثل ويكيبيديا ومركز مطوري موزيلا, ، وقد تم استخدامه في التطبيقات المضمنة مثل مشغلات Sansa MP3 وتشغيل آلاف الألعاب المنشورة.

على مستوى اللغة، المترجم Mono متوافق تمامًا مع مواصفات لغة C# 5.0.

على جانب سطح المكتب، يعمل Mono بشكل رائع إذا كنت ملتزمًا باستخدام GTK#.لا يزال تنفيذ Windows.Forms به بعض الأخطاء (على سبيل المثال، TrayIcon's لا يعمل) ولكنه قطع شوطًا طويلًا.إلى جانب ذلك، GTK# هي مجموعة أدوات أفضل من Windows Forms كما هي.

على جانب الويب، قامت Mono بتنفيذ ما يكفي من ASP.NET لتشغيل معظم المواقع بشكل مثالي.تكمن الصعوبة هنا في العثور على مضيف مثبت عليه mod_mono على Apache، أو القيام بذلك بنفسك إذا كان لديك حق الوصول إلى مضيفك.

وفي كلتا الحالتين، Mono رائع ومستقر.

الأشياء الأساسية التي يجب تذكرها عند إنشاء برنامج متعدد المنصات:

استخدم GTK# بدلاً من Windows.Forms
تأكد من حالة أسماء الملفات الخاصة بك بشكل صحيح
يستخدم Path.Separator بدلاً من الترميز الثابت "\", ، أيضا استخدام Environment.NewLine بدلاً من "\n".
لا تستخدم أي استدعاءات P/Invoced لـ Win32 API.
لا تستخدم سجل ويندوز.

أنا شخصياً أستخدم Mono في أوقات الذروة.أقوم بتشغيل خوادم أحادية تتعامل مع جيجا بايت من المهام المتعلقة بمعالجة بيانات udp/tcp ولا يمكن أن أكون أكثر سعادة.

هناك بعض الخصائص، وأحد أكثر الأشياء المزعجة هو أنه لا يمكنك "إنشاء" ملفات msbuild الخاصة بك بسبب الوضع الحالي لـ Mono:

يتمتع MonoDevelop (IDE) ببعض الدعم الجزئي لـ msbuild، ولكنه سيتعامل بشكل أساسي مع أي تكوين بناء "حقيقي" يتجاوز عالم الترحيب البسيط (مهام بناء مخصصة، و"خصائص" ديناميكية مثل $(SolutionDir)، والتكوين الحقيقي على سبيل المثال لا الحصر -ينتهي)
xbuild الذي كان ينبغي أن يكون يعد نظام البناء المتوافق بالكامل مع mono-supplied-msbuild أكثر فظاعة، لذا فإن البناء من سطر الأوامر هو في الواقع تجربة أسوأ من استخدام واجهة المستخدم الرسومية، وهي حالة "غير تقليدية" جدًا لاتحاد بيئات Linux. ..

بمجرد/أثناء إنشاء العناصر الخاصة بك فعليًا، قد ترى بعض الأخطاء حتى بالنسبة للتعليمات البرمجية التي يجب دعمها مثل:

المترجم ينزعج من بنيات معينة
وبعض فئات .NET الأكثر تقدمًا/الجديدة التي تلقي عليك حماقات غير متوقعة (هل هناك أحد في XLinq؟)
بعض "ميزات" وقت التشغيل غير الناضجة (حد الكومة 3 جيجابايت على نظام التشغيل x64...ماهذا الهراء!)

لكن قال إن الأمور بشكل عام تبدأ في العمل بسرعة كبيرة، والحلول/الحلول البديلة وفيرة.

بمجرد تجاوز تلك العقبات الأولية، تجربتي هي أن الصخور الأحادية، وتستمر في التحسن مع كل تكرار.

لقد كان لدي خوادم تعمل باستخدام mono، وتعالج 300 جيجابايت من البيانات يوميًا، مع الكثير من p/الاستدعاءات وبشكل عام تقوم بالكثير من العمل وتظل مستيقظًا لمدة 5-6 أشهر، حتى مع أحادية "الحافة النازفة".

أتمنى أن يساعدك هذا.

التوصيات الخاصة بالإجابة المقبولة قديمة بعض الشيء الآن.

تنفيذ نماذج Windows جيد جدًا الآن.(يرى الطلاء الأحادي لمنفذ Paint.net وهو تطبيق نماذج Windows مشترك جدًا.كل ما هو مطلوب هو طبقة مضاهاة لبعض استدعاءات P-Invine واستدعاءات النظام غير المدعومة).
Path.Combine وكذلك Path.Seperator لربط المسارات وأسماء الملفات.
سجل windows على ما يرام، طالما أنك تستخدمه فقط لتخزين واسترداد البيانات من تطبيقاتك (أي.لا يمكنك الحصول على أي معلومات حول Windows منه، لأنه في الأساس سجل لتطبيقات Mono).

إذا كنت تريد استخدام WPF، فلن يحالفك الحظ، فليس لدى Mono حاليًا أي خطط لتنفيذه.

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

حسنًا، اللون الأحادي رائع، لكن بقدر ما أستطيع رؤيته، فهو غير مستقر.إنه يعمل، ولكنه يخطئ عندما تعطي العملية الأحادية عملاً جادًا للقيام به.

TL;DR - لا تستخدم اللون الأحادي إذا كنت:

استخدم AppDomains (تحميل/إلغاء تحميل التجميع) في بيئات متعددة مؤشرات الترابط
لا يمكن الحفاظ على نموذج "السماح له بالفشل".
تجربة أحداث التحميل الثقيل العرضية أثناء تشغيل العملية

إذن الحقائق.

نحن نستخدم mono-2.6.7 (.net v 3.5) على RHEL5 وUbuntu، ومن وجهة نظري، فهو الإصدار الأكثر استقرارًا الذي صممته Novell.لديها مشكلة في تفريغ AppDomains (segfaults)، ومع ذلك، فهي تفشل نادرًا جدًا وهذا مقبول حتى الآن (من جانبنا).

تمام.ولكن إذا كنت تريد استخدام ميزات .net 4.0، فيجب عليك التبديل إلى الإصدارات 2.10.x أو 3.x، وهنا تبدأ المشاكل.

بالمقارنة مع 2.6.7، الإصدارات الجديدة غير مقبولة للاستخدام.لقد كتبت تطبيقًا بسيطًا لاختبار التحمل لاختبارات التركيبات الأحادية.

ومن هنا مع تعليمات الاستخدام: https://github.com/head-thrash/stress_test_mono

يستخدم مؤشرات ترابط عامل تجمع الخيط.يقوم العامل بتحميل ملف dll إلى AppDomain ويحاول القيام ببعض العمليات الحسابية.بعض الأعمال متعددة الخيوط، وبعضها فردي.ترتبط جميع الأعمال تقريبًا بوحدة المعالجة المركزية (CPU)، على الرغم من وجود بعض عمليات قراءة الملفات من القرص.

النتائج ليست جيدة جدا.في الواقع، بالنسبة للإصدار 3.0.12:

تتم معالجة segfaults sgen GC على الفور تقريبًا
أحادية مع boehm يعيش لفترة أطول (من 2 إلى 5 ساعات)، ولكن segfaults في نهاية المطاف

كما ذكر أعلاه، sgen gc لا يعمل (أحادي تم إنشاؤه من المصدر):

* 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]

أما بالنسبة لـ boehm segfauls - على سبيل المثال (Ubuntu 13.04، mono مبني من المصدر):

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

أو (RHEL5، أحادية مأخوذة من دورة في الدقيقة هنا 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

يرتبط كلا الفشلين بطريقة ما بمنطق AppDomains، لذا، يجب عليك الابتعاد عنهما بشكل أحادي.

راجع للشغل، البرنامج الذي تم اختباره يعمل لمدة 24 ساعة على جهاز يعمل بنظام Windows في بيئة MS .NET 4.5 دون أي فشل.

لذا، في الختام، أود أن أقول - استخدم أحادية بحذر.إنه يعمل من الوهلة الأولى، ولكن يمكن أن يفشل بسهولة في أي وقت.سيتم تركك مع مجموعة من المقالب الأساسية وفقدان الثقة الكبير في المشاريع مفتوحة المصدر.

MoMA هو أداة عظيمة لهذا، كما اقترح شخص آخر.أكبر مصادر عدم التوافق هذه الأيام هي التطبيقات التي تقوم باستيراد DllImport (أو P/Invoc) إلى مكتبات Win32.لم يتم تنفيذ بعض التجميعات، ولكن معظمها يعمل بنظام Windows فقط ولن يكون لها أي معنى على Linux.أعتقد أنه من الآمن أن نقول إن معظم تطبيقات ASP.NET يمكن تشغيلها على Mono مع تعديلات محدودة.

(إفشاء:لقد ساهمت في Mono نفسه، بالإضافة إلى التطبيقات المكتوبة التي تعمل فوقه.)

في العديد من الحالات، يمكنك أخذ التعليمات البرمجية الموجودة وتشغيلها على Mono، خاصة إذا كنت تقوم بنقل تطبيق ASP.NET.

في بعض الحالات، قد تحتاج إلى أقسام جديدة بالكامل من التعليمات البرمجية حتى تعمل.إذا كنت تستخدم System.Windows.Forms، على سبيل المثال، فلن يعمل التطبيق بدون تعديل.وبالمثل، إذا كنت تستخدم أي رمز خاص بنظام Windows (رمز الوصول إلى السجل، على سبيل المثال).لكنني أعتقد أن أسوأ الجاني هو رمز واجهة المستخدم.وهذا أمر سيء بشكل خاص على أنظمة ماكنتوش.

لقد كنا نستخدمه في مشروع هنا في العمل كان يحتاج إلى التشغيل على Linux ولكننا نعيد استخدام بعض مكتبات .NET التي أنشأناها في Managed C++.لقد فوجئت جدًا بمدى نجاح الأمر.تتم كتابة ملفنا التنفيذي الرئيسي بلغة C# ويمكننا فقط الرجوع إلى ثنائيات C++ المُدارة دون أي مشكلة.الاختلاف الوحيد في رمز C# بين Windows وLinux هو رمز المنفذ التسلسلي RS232.

المشكلة الكبيرة الوحيدة التي يمكنني التفكير فيها حدثت منذ شهر تقريبًا.كان لدى إصدار Linux تسرب للذاكرة لم يتم رؤيته في إصدار Windows.بعد إجراء بعض التصحيح اليدوي (لم تساعد ملفات التعريف الأساسية لـ Mono على Linux كثيرًا)، تمكنا من تضييق المشكلة إلى جزء محدد من التعليمات البرمجية.لقد انتهى بنا الأمر إلى تصحيح الحل البديل، ولكن ما زلت بحاجة إلى إيجاد بعض الوقت للعودة ومعرفة السبب الجذري للتسرب.

هل تعرف مدى جودة دعم معاينة Mono 2.0 لنظام التشغيل Windows Forms 2.0؟

من القليل الذي لعبت به، بدا مكتملًا نسبيًا وقابل للاستخدام تقريبًا.لم يكن الأمر يبدو صحيحًا تمامًا في بعض الأماكن ولا يزال يتعرض للضرب أو الفشل بشكل عام.لقد أذهلني أنها نجحت كما فعلت مع بعض أشكالنا، على الرغم من صدقها.

نعم ، إنه بالتأكيد (إذا كنت حريصًا على الرغم من ذلك) ، فإننا ندعم Mono في RA-Ajax (تم العثور على مكتبة Ajax في http://ra-ajax.org) ونحن في الغالب لا نواجه مشاكل على الإطلاق.يجب أن تكون حذرًا مع بعض "الأشياء الأكثر جنونًا" من .Net مثل WSE وما إلى ذلك، ومن المحتمل أيضًا أن بعض مشاريعك الحالية لن تكون متوافقة بنسبة 100٪ مع Mono، ولكن المشاريع الجديدة إذا قمت باختبارها أثناء التطوير ستكون في الغالب تكون متوافقة دون مشاكل مع مونو.والمكاسب من دعم Linux وما إلى ذلك من خلال استخدام Mono أمر رائع حقًا؛)

أعتقد أن جزءًا كبيرًا من سر دعم Mono هو استخدام الأدوات الصحيحة من البداية، على سبيل المثال.ActiveRecord وlog4net وra-ajax وما إلى ذلك...

بالنسبة لنوع التطبيق الذي نبنيه Mono، للأسف، لا يبدو جاهزًا للإنتاج.لقد أعجبنا به بشكل عام، وأعجبنا بأدائه على كل من Windows وأجهزة EC2، ومع ذلك، فقد تعطل برنامجنا باستمرار بسبب أخطاء جمع البيانات المهملة على كل من Windows وLinux.

رسالة الخطأ هي:"أخطاء فادحة في GC:هناك عدد كبير جدًا من أقسام الكومة"، فيما يلي رابط لشخص آخر يواجه المشكلة بطريقة مختلفة قليلاً:

http://bugzilla.novell.com/show_bug.cgi?id=435906

الجزء الأول من التعليمات البرمجية التي قمنا بتشغيلها في Mono كان تحديًا برمجيًا بسيطًا قمنا بتطويره...يقوم الكود بتحميل حوالي 10 ميجابايت من البيانات في بعض هياكل البيانات (على سبيل المثال.HashSets)، ثم يقوم بتشغيل 10 استعلامات على البيانات.لقد أجرينا الاستعلامات 100 مرة لتحديد توقيتها والحصول على المتوسط.

تعطل الرمز حول الاستعلام الخامس والخمسين على نظام التشغيل Windows.لقد نجح الأمر على نظام التشغيل Linux، ولكن بمجرد انتقالنا إلى مجموعة بيانات أكبر، فإنه سيتعطل أيضًا.

هذا الرمز بسيط جدًا، على سبيل المثال.ضع بعض البيانات في HashSets ثم استعلم عن تلك HashSets وما إلى ذلك، وكلها أصلية c#، ولا شيء غير آمن، ولا توجد مكالمات API.في Microsoft CLR، لا يتعطل أبدًا، ويعمل على مجموعات بيانات ضخمة آلاف المرات بشكل جيد.

أرسل أحد رجالنا بريدًا إلكترونيًا إلى ميغيل وأدرج الرمز الذي تسبب في المشكلة، ولم يتم الرد بعد.:(

يبدو أيضًا أن العديد من الأشخاص الآخرين قد واجهوا هذه المشكلة دون حل - فقد تم اقتراح حل واحد لإعادة ترجمة Mono بإعدادات GC مختلفة ولكن يبدو أن هذا يؤدي إلى زيادة الحد الذي يتعطل قبله.

فقط تحقق من www.plasticscm.com.كل شيء (العميل، الخادم، واجهة المستخدم الرسومية، أدوات الدمج) مكتوب على صورة أحادية.

يعتمد الأمر حقًا على مساحات الأسماء والفئات التي تستخدمها من إطار عمل .NET.لقد كنت مهتمًا بتحويل إحدى خدمات Windows الخاصة بي لتعمل على خادم البريد الإلكتروني الخاص بي، وهو Suse، لكننا واجهنا العديد من العوائق الصعبة مع واجهات برمجة التطبيقات التي لم يتم تنفيذها بالكامل.يوجد مخطط في مكان ما على موقع Mono الإلكتروني يسرد جميع الفصول الدراسية ومستوى إكمالها.إذا تم تغطية طلبك، فاذهب إليه.

مثل أي تطبيق آخر، قم بإجراء النماذج الأولية والاختبار قبل الالتزام الكامل بالطبع.

هناك مشكلة أخرى واجهناها وهي البرامج المرخصة:إذا كنت تشير إلى ملف DLL خاص بشخص آخر، فلن تتمكن من كتابة التعليمات البرمجية للتغلب على حالات عدم التوافق المدفونة في هذا التجميع.

أتصور أنه إذا كان لديك تطبيق يحتوي على بعض مكونات الطرف الثالث، فقد تكون ممتلئًا.أشك في أن الكثير من البائعين سوف يتطورون مع وضع Mono في الاعتبار

مثال: http://community.devexpress.com/forums/p/55085/185853.aspx

لا، مونو ليس جاهزًا للعمل الجاد.لقد كتبت بعض البرامج على Windows باستخدام F# وقمت بتشغيلها على Mono.استخدم هذا البرنامج القرص والذاكرة ووحدة المعالجة المركزية بشكل مكثف للغاية.لقد رأيت أعطالًا في المكتبات الأحادية (التعليمات البرمجية المُدارة)، وأعطالًا في التعليمات البرمجية الأصلية، وأعطالًا في الجهاز الظاهري.عندما كان برنامج mono يعمل، كانت البرامج أبطأ مرتين على الأقل من برامج .Net في نظام التشغيل Windows، وكانت تستخدم ذاكرة أكبر بكثير.ابتعد عن الأحادية للعمل الجاد.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow