سؤال

لقد استخدمت لغة C# في Visual Studio مع .NET، ولقد جربت قليلًا مع Mono على نظام openSUSE Linux، لكنني لا أفهم حقًا كيف يعمل.

إذا قمت بكتابة تطبيق في Windows على .NET، فكيف يرتبط ذلك بـ Mono؟لا يمكنني تنفيذ ملف Windows .exe على Linux بدون Wine، لذلك لا يساعدني ذلك في تنفيذ التطبيقات التي تم تطويرها في Windows.

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

هل كانت مفيدة؟

المحلول

يحتوي Windows EXE على "أجزاء" متعددة. مبسط, ، رمز .net (=MSIL) هو مجرد جزء من EXE، ويوجد أيضًا جزء Windows أصلي "حقيقي" داخل EXE يعمل كنوع من المشغل لـ .net Framework الذي يقوم بعد ذلك بتنفيذ MSIL.

سيأخذ Mono MSIL وينفذه، متجاهلاً عناصر Windows Launcher الأصلية.

مرة أخرى، هذه نظرة عامة مبسطة.

يحرر: أخشى أن فهمي للتفاصيل العميقة ليس جيدًا بما يكفي للحصول على الكثير من التفاصيل (أعرف تقريبًا ما هو رأس PE، ولكن ليس التفاصيل حقًا)، لكنني وجدت هذه الروابط مفيدة:

هيكل تجميع NET – الجزء الثاني

أسس .NET - بنية تجميع .NET

نصائح أخرى

هذا سؤال قديم (مع إجابة محددة بالفعل) ولكني لا أعتقد أنه تمت الإجابة على السؤال بشكل جيد بالفعل.

أولا، خلفية صغيرة ...

كيف يعمل .NET؟

ملف Windows .EXE التقليدي هو ملف ثنائي يمثل سلسلة من تعليمات لغة الآلة التي يفهمها جهاز الكمبيوتر الخاص بك والتي تقوم بإجراء مكالمات إلى Win32 API وهي أجزاء من Windows تقدم خدمات يمكن للتطبيقات الاستفادة منها.لغة الآلة المستخدمة خاصة جدًا بنوع جهاز الكمبيوتر الخاص بك واستدعاءات Win32 تجعل الملف القابل للتنفيذ يعتمد بشكل كبير على نظام التشغيل Windows.الملف القابل للتنفيذ .NET ليس هكذا.

من المهم أن ندرك أن الملف القابل للتنفيذ ‎.NET (ملف ‎.EXE) ليس في الواقع تطبيق Windows أصليًا.لا يفهم Windows نفسه كيفية تشغيل التعليمات البرمجية في ملف .NET قابل للتنفيذ.جهاز الكمبيوتر الخاص بك لا يفهم ذلك أيضًا.

مثل Java، يتكون تطبيق .NET من تعليمات بلغة تسمى CIL (اللغة الوسيطة المشتركة) والتي يمكنك اعتبارها لغة الآلة لجهاز كمبيوتر مثالي غير موجود بالفعل.في .NET، يُطلق على تنفيذ البرنامج لهذا الجهاز المثالي اسم Common Language Runtime (CLR).يُطلق على المعادل في عالم Java اسم Java Virtual Machine (JVM).في Java، يسمى المعادل لـ CIL Java bytecode.يُطلق على CIL أحيانًا اسم MSIL (لغة Microsoft المتوسطة).

تم تصميم CIL ليعمل على CLR (جهاز مثالي) ولكنه بخلاف ذلك مستقل عن النظام الأساسي، مما يعني أن CIL لا يهتم بنوع الكمبيوتر لديك أو نظام التشغيل الذي تستخدمه.

مثلما تحتاج إلى إصدار أصلي من Java JVM على كل نظام أساسي تريد تشغيل Java عليه، فإنك تحتاج إلى إصدار أصلي من CLR لتشغيل ملفات .NET CIL القابلة للتنفيذ.يعد CLR تطبيق Windows أصليًا تمامًا مثل ملفات Win32 EXE التقليدية الموضحة أعلاه.إن CLR نفسه خاص بتطبيق Windows وبنية الكمبيوتر التي تم تصميمه للتشغيل عليها.

لا يهم لغة .NET التي تبدأ بها (C#، VisualBasic، F#، IronPython، IronRuby، Boo، وما إلى ذلك)، حيث يتم تجميعها جميعًا وصولاً إلى كود CIL الثانوي.يمكنك بسهولة "تفكيك" برنامج CIL إلى شكل من أشكال لغة التجميع الموجهة للكائنات والتي يمكن للبشر قراءتها بسهولة.يمكنك كتابة برنامج في CIL مباشرة بنفسك ولكن القليل من الناس يفعلون ذلك.

في نظام التشغيل Windows، يقوم CLR بتجميع رمز CIL هذا في الوقت المناسب (JIT) مباشرة عند تشغيل الملف القابل للتنفيذ - قبل تشغيل التعليمات البرمجية فعليًا.وهذا يعني أنه يتم تحويل (تجميع) رمز بايت CIL إلى رمز الجهاز الفعلي الذي يتم تشغيله أصلاً على جهاز الكمبيوتر الخاص بك.يُسمى هذا الجزء من CLR مترجم JIT أو غالبًا JIT فقط.

حتى الآن، أصدرت Microsoft أربعة إصدارات من CLR:1.0، 1.1، 2.0، و 4.0.يجب أن يكون لديك الإصدار الصحيح من CLR مثبتًا على جهازك إذا كنت تريد تشغيل ملفات .NET التنفيذية التي تستهدف وقت التشغيل هذا.يدعم CLR 2.0 تطبيقات .NET 2.0 و3.0 و3.5.بالنسبة للإصدارات الأخرى من .NET، يتم تعيين إصدار .NET بشكل واضح إلى إصدار CLR.

بالإضافة إلى JIT/CLR، يوفر .NET مجموعة من المكتبات (التجميعات) التي تشكل بقية إطار عمل .NET والتي توفر مجموعة من الإمكانيات والخدمات التي يمكن لتطبيقات .NET الاتصال بها.الغالبية العظمى من هذه التجميعات عبارة عن كود CIL خالص يعمل على CLR.على نظام التشغيل Windows، يقوم البعض بإجراء مكالمات إلى Win32 API أيضًا.عندما تقوم بتثبيت .NET، فإنك تقوم بتثبيت CLR ومكتبات الفئات (إطار العمل) ومجموعة من أدوات التطوير.يتطلب كل إصدار من CLR عمومًا مجموعة كاملة من تجميعات "إطار العمل" هذه.بعض إصدارات .NET (على سبيل المثال.3.0 و3.5) أضافت تجميعات إطار عمل إضافية دون تحديث CLR أو التجميعات الموجودة المرتبطة بذلك CLR.

يحتوي تنسيق الملف القابل للتنفيذ (PE) الذي يتم تسليم ملف Windows .EXE فيه على رأس يصف الملف القابل للتنفيذ ويحدد الملف كملف .NET أو ملف Win32 أصلي.عندما يحاول Windows تشغيل ملف ‎.NET، فإنه يرى هذا الرأس ويستدعي CLR تلقائيًا نيابةً عنك.ولهذا السبب تظهر ملفات ‎.NET EXE وكأنها تعمل أصلاً على نظام التشغيل Windows.

حسنًا، كيف يعمل مونو؟

تقوم Mono بتنفيذ CLR على Linux وMac والأنظمة الأساسية الأخرى.يعد وقت التشغيل Mono (CLR) تطبيقًا أصليًا مكتوبًا في الغالب بلغة C ويتم تجميعه إلى كود لغة الآلة لنظام الكمبيوتر المصمم للتشغيل عليه.كما هو الحال في نظام التشغيل Windows، يكون وقت التشغيل Mono خاصًا بنظام التشغيل ونوع الجهاز الذي تستخدمه.

تمامًا كما هو الحال في Windows، يقوم وقت التشغيل Mono (CLR) بتجميع كود CIL الثانوي في .NET القابل للتنفيذ في الوقت المناسب إلى التعليمات البرمجية الأصلية التي يمكن لجهاز الكمبيوتر الخاص بك فهمها وتنفيذها.بهذه الطريقة، يكون ملف .NET "أصليًا" لنظام التشغيل Linux كما هو الحال بالنسبة لنظام التشغيل Windows.

لنقل Mono إلى بنية جديدة، تحتاج إلى توصيل JIT/CLR.وهذا يشبه تمامًا نقل أي تطبيق أصلي إلى نظام أساسي جديد.

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

بالإضافة إلى CLR، توفر Mono معظم المكتبات (التجميعات) المتبقية التي تشكل إطار عمل .NET.تمامًا كما هو الحال مع إصدار Microsoft من .NET (في الواقع أكثر من ذلك) يتم توفير التجميعات الأحادية كرمز ثانوي لـ CIL.وهذا يجعل من الممكن أخذ ملف *.dll أو *.exe من Mono وتشغيله دون تعديل على أنظمة التشغيل Windows أو Mac أو Linux لأن CIL هي اللغة "الأصلية" لتطبيقات CLR على هذه الأنظمة.

تمامًا كما هو الحال في نظام التشغيل Windows، يدعم Mono إصدارات متعددة من CLR والتجميعات المرتبطة به:

الإصدارات المبكرة جدًا من Mono (قبل 1.2؟) تدعم فقط CLR 1.0 أو 1.1.لم يدعم Mono أجزاء كبيرة من إطار العمل 2.0 حتى الإصدار 2.0 الخاص به.

تدعم الإصدارات الأحادية حتى الإصدار 2.4 كلاً من تطبيقات CLR 1.1 وCLR 2.0.

بدءًا من Mono 2.6، تمت إضافة CLR 4.0 ولكن ظل CLR 2.0 هو الإصدار الافتراضي.

بدءًا من Mono 2.8، أصبح CLR 4.0 هو الإصدار الافتراضي ولم يعد CLR 1.1 مدعومًا.

يستمر Mono 2.10 في استخدام CLR 4.0 كإعداد افتراضي وأيضًا لدعم CLR 2.0.

تمامًا مثل .NET الحقيقي (ولكن في حالات أقل بكثير) هناك بعض التجميعات الأحادية التي تستدعي المكتبات الأصلية.من أجل جعل تجميع System.Drawing يعمل على Mono، كتب فريق Mono برنامج Linux لمحاكاة جزء GDI+ من Win32 API على Linux.هذه المكتبة تسمى "libgdiplus".إذا قمت بتجميع Mono من المصدر، ستلاحظ أنك بحاجة إلى إنشاء ملف "libgdiplus" هذا قبل أن تتمكن من إنشاء "mono".لا تحتاج إلى "libgdiplus" على نظام التشغيل Windows لأن جزء GDI+ من Win32 API هو بالفعل جزء من Windows.يتطلب المنفذ الكامل لـ Mono إلى الأنظمة الأساسية الجديدة نقل مكتبة "libgdiplus" هذه أيضًا.

في المناطق التي يتأثر فيها تصميم مكتبة .NET بشكل مفرط بتصميم Windows، ويكون غير مناسب لأنظمة مثل Mac أو Linux، قام فريق Mono بكتابة امتدادات لإطار عمل .NET.تعد امتدادات Mono أيضًا مجرد رمز ثانوي لـ CIL وتعمل بشكل جيد بشكل عام على .NET.

على عكس نظام التشغيل Windows، لا يكتشف Linux عمومًا الملفات التنفيذية لـ .NET ويقوم بتشغيل CLR افتراضيًا.يجب على المستخدم عادةً تشغيل CLR مباشرةً عن طريق كتابة "mono appname.exe" أو شيء مشابه.هنا "mono" هو التطبيق الذي ينفذ CLR و"appname.exe" هو ملف EXE الذي يحتوي على كود .NET المطلوب تنفيذه.

لتسهيل الأمور على المستخدمين، غالبًا ما يتم تضمين تطبيقات Mono في برنامج نصي Shell يقوم بتشغيل CLR.وهذا يخفي حقيقة أن CLR يتم استخدامه تمامًا كما هو الحال في Windows.من الممكن أيضًا إخبار Linux بتشغيل CLR عند مواجهة ملف يستخدم تنسيق ملف PE.لا يتم ذلك عادةً حيث يتم استخدام تنسيق ملف PE أيضًا للملفات التنفيذية Win32 Windows الأصلية والتي بالطبع لا يدعمها CLR (Mono).

لا يوجد سبب تقني يمنع Linux من استخدام مشغل PE الذي يقوم بعد ذلك بتشغيل إما نظام يفهم كود Windows الأصلي (مثل Wine) أو CLR (Mono) حسب الاقتضاء.وهذا ببساطة لم يتم على حد علمي.

ذهابا وايابا

أي كود .NET يلتزم بالرمز "المُدار بالكامل"، مما يعني أنه لا يستدعي تعليمات برمجية غير تابعة لـ .NET، يجب أن يعمل بشكل جيد على Mono على كافة الأنظمة الأساسية.أستخدم بشكل روتيني تجميعات .NET المترجمة من Windows (والتي لا أملك رمزًا لها) على Linux وMac.

يمكنني أيضًا أخذ أي كود أقوم بتجميعه على Mono وتشغيله على .NET على Windows.يمكنني أن أقدم للعميل بعض التعليمات البرمجية التي قمت بتجميعها باستخدام Mono ولا تقلق إذا كان يعمل بنظام Windows 32 بت أو 64 بت على سبيل المثال.يحتاج العميل إلى تثبيت الإصدار الصحيح من .NET (CLR الصحيح) بالطبع.لقد كان CLR 2.0 موجودًا منذ فترة طويلة جدًا ويمكنك المراهنة على أن جميع مستخدمي Windows تقريبًا قد قاموا بتثبيته.تعد برامج التحويل البرمجي Mono والأكواد الأخرى أيضًا مجرد ملفات CIL قابلة للتنفيذ وبالتالي فهي تعمل بشكل جيد على Windows إذا أردت.

يعد التوافق الأحادي جيدًا بما يكفي بحيث يمكن أخذ أجزاء كبيرة من أكواد Microsoft الفعلية، مثل ASP.NET MVC، (حيث يكون ذلك قانونيًا) من إصدار MS الفعلي لـ .NET وتشغيلها على Mac أو Linux.بشكل عام، قام فريق Mono بعمل رائع في تنفيذ كل من CLR وبقية إطار العمل (مكتبات/تجميعات الفئة).

أسب.نت

في نظام التشغيل Windows، يعرف خادم معلومات الإنترنت (IIS) كيفية الاتصال بـ CLR لتنفيذ .NET كجزء من تطبيق ويب.توجد على Linux/Mac وحدة Apache (mod_mono) التي توفر إمكانات مشابهة لخادم الويب Apache.هذا التطبيق مكتوب بلغة C ويجب أيضًا نقله إلى بنيات جديدة.

بورتينغ مونو

لقد حددت هذه المناقشة أجزاء من Mono التي تم إنشاؤها كملفات تنفيذية "أصلية" ويجب أن تكون موجودة على النظام الذي تريد تشغيل تطبيقات .NET عليه.

  • CLR (بما في ذلك مترجم JIT) - المعروف عمومًا باسم Mono
  • libgdiplus (للأنظمة التي لا تدعم واجهة برمجة تطبيقات GDI+‎ أصلاً [فقط نظام التشغيل Windows يدعمها])
  • mod_mono (للسماح لـ Apache باستدعاء CLR لتطبيقات الويب .NET)

توفر هذه المكونات الثلاثة، بالإضافة إلى مكتبات الفئات، بيئة .NET تبدو "أصلية" لملفات .NET القابلة للتنفيذ التي تحتاج إلى تشغيلها.

هذه هي الطريقة التي يعمل بها مونو.

ويمكنك في الواقع تشغيل ملف إكس. NET مع مونو على لينكس. هذا لا يتطلب النبيذ. في الواقع، مونو يجمع برامج إكس الملفات التي يمكن تشغيلها إما مع مونو على لينكس أو قابل للتنفيذ على ويندوز.

ومونو هو تنفيذ المفتوحة المصدر من مايكروسوفت. NET CLR (وقت تشغيل اللغة المشتركة). هذا هو ما يدير جزءا من برامج. NET التي ليست في التعليمات البرمجية الأصلية ولكن في CIL (عام اللغة الوسيطة)، لغة ولغة وسيطة محايدة والآلة. يأخذ وقت التشغيل هذا الرمز المتوسطة ويترجم ذلك إلى رمز الجهاز.

وفي الحالة الراهنة للمونو، يمكنك أن تأخذ البرامج. NET التي تستخدم الأجزاء الرئيسية من صافي (mscorlib.dll) وتشغيلها في كل مكان مونو يعمل، وليس فقط ويندوز.

ولكن كما ذكر أن مونو مفتوح المصدر والتي لا يمكن الاعتماد فقط أنه سيكون تنفيذ. NET الكامل، لديها بعض الضوابط التي لا تعمل، يجب أن تكون أيضا حذرا مع P / استدعاء بأن ما تتمتعون به سوف تستخدم التطبيق، على سبيل المثال لطلبك سوف التواصل مع MCI (الوسائط المتعددة وحدة تحكم واجهة) تحت Win32 و. ولكن كنت تستخدم أحادية كتابة GTK # تطبيقات أيضا، ولكن لقد استعملت أيضا تطبيقات ويندوز بلدي التي عملت دون أي إعادة تجميع كما ذكر إخواننا المبرمجين أعلاه، وهذا هو، أحادية هو بديل مفتوح المصدر من مايكروسوفت .NET، وافتراضيا إذا كنت بناء إما WinForms عناصر أو جتك # التطبيقات أحادية وتجميع وسوف إنشاء تجميع إكس لكل ملف، وبالطبع إذا كنت تريد ذلك سيتم إنشاء مكتبة الارتباط الحيوي (DLL)، تقريبا كما هو الحال في .NET. مجرد اقتراح محاولة كتابة بعض جتك # (مع مونو ديفيلوب IDE التي لديها المدمج في واجهة المستخدم الرسومية مصمم دعا stetic). وبالطبع أحادية يمكن أن يكون بديلا رائعا لخدمات الويب التي يمكن أن تخلق لهم على صافي ويمكنك تستضيفهم على اباتشي (لينكس استضافة هذه الأيام هي أكثر رخيصة من تلك يندوز) وخدمات الويب وغيرها من التطبيقات asp.net العمل تحت اباتشي مع وحدة mod_mono التي يجب تضمينها في اباتشي.

وقليلا من الموضوع ولكن أردت فقط أن أقول لكم لقطات سريعة من واقع خبرتي.

وكما يمكنك إلقاء نظرة على متحف الفن الحديث (إذا كان هدفك هو لتطبيقات الميناء من فوز للين).

<اقتباس فقرة>   

ومحلل الهجرة مونو (متحف الفن الحديث)   أداة تساعدك على تحديد القضايا التي قد   يكون عند ترقية صافي الخاص بك   تطبيق لمونو. كما أنه يساعد على تحديد   منصة دعوات محددة (P / استدعاء) و   المناطق غير معتمدة حتى الآن من قبل   مشروع مونو.

متحف الفن الحديث

وهنا هو تطبيق الويب الذي يقارن أنواع من BCL تنفيذها بالفعل مونو و .NET Framework 3.5

http://mono.ximian.com/class -status / 2.0 مقابل 3.5 و / index.html

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

وبالإضافة إلى ذلك، يفترض مونو 1.9 ليكون كاملا الصافي 2.0 متوافقة. من المفترض أحادية الزيتون وضوء القمر لإضافة Framework 3.0 (أقل WPF) وظيفة سيلفرلايت.

ربما يساعدك، كيف يعمل مترجم Mono C#؟ وكذلك فهم مترجم Mono C# كتاب.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top