.net - क्या मोनो प्राइम टाइम के लिए तैयार है?




open-source mono (12)

क्या आप जानते हैं कि विंडोज फॉर्म 2.0 के लिए मोनो 2.0 पूर्वावलोकन का समर्थन कितना अच्छा है?

मैंने जो कुछ भी खेला है, उससे अपेक्षाकृत पूर्ण और लगभग उपयोग योग्य लग रहा था। यह कुछ जगहों पर बिल्कुल सही नहीं दिख रहा था और अभी भी थोड़ा हिट या मिस है। यह मुझे आश्चर्यचकित करता है कि यह हमारे कुछ रूपों के साथ-साथ ईमानदारी से काम करता है।

क्या किसी ने मोनो, ओपन सोर्स .NET कार्यान्वयन को बड़े या मध्यम आकार के प्रोजेक्ट पर इस्तेमाल किया है? मैं सोच रहा हूं कि यह असली दुनिया, उत्पादन वातावरण के लिए तैयार है या नहीं। क्या यह स्थिर, तेज़, संगत, ... उपयोग करने के लिए पर्याप्त है? क्या यह मोनो रनटाइम में बंदरगाह परियोजनाओं के लिए बहुत मेहनत करता है, या वास्तव में, वास्तव में माइक्रोसॉफ्ट के रनटाइम के लिए पहले ही लिखित कोड लेने और चलाने के लिए पर्याप्त संगत है?


आवेदन के प्रकार के लिए हम मोनो बना रहे हैं दुर्भाग्यवश उत्पादन के लिए तैयार नहीं लग रहा है। हम इसे समग्र रूप से प्रभावित हुए, और विंडोज और ईसी 2 मशीनों पर इसके प्रदर्शन से प्रभावित हुए, हालांकि, हमारे कार्यक्रम विंडोज और लिनक्स दोनों पर कचरा संग्रहण त्रुटियों के साथ लगातार क्रैश हो गए।

त्रुटि संदेश यह है: "जीसी में घातक त्रुटियां: बहुत सारे ढेर खंड", यहां किसी अन्य व्यक्ति को समस्या का सामना करने का एक अलग तरीका है:

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

मोनो में हमारे द्वारा चलाए गए कोड का पहला टुकड़ा एक साधारण प्रोग्रामिंग चुनौती थी जिसे हमने विकसित किया था ... कोड कुछ डेटा संरचनाओं (जैसे हैशसेट्स) में लगभग 10 एमबी डेटा लोड करता है, फिर डेटा के खिलाफ 10 प्रश्न चलाता है। हमने उन्हें समय देने और औसत प्राप्त करने के लिए 100 बार प्रश्नों को चलाया।

कोड विंडोज़ पर 55 वें प्रश्न के आसपास दुर्घटनाग्रस्त हो गया। लिनक्स पर यह काम करता था, लेकिन जैसे ही हम एक बड़े डेटा सेट में चले गए, यह भी क्रैश हो जाएगा।

यह कोड बहुत आसान है, उदाहरण के लिए हैशसेट्स में कुछ डेटा डालें और फिर उन हैशसेट्स आदि से पूछें, सभी देशी सी #, कुछ भी असुरक्षित नहीं, कोई एपीआई कॉल नहीं। माइक्रोसॉफ्ट सीएलआर पर यह कभी भी दुर्घटनाग्रस्त नहीं होता है, और विशाल डेटा सेट पर चलता है और बार-बार ठीक है।

हमारे लोगों में से एक ने मिगुएल को ईमेल किया और उस कोड को शामिल किया जिसने समस्या उत्पन्न की, अभी तक कोई प्रतिक्रिया नहीं है। :(

ऐसा लगता है कि कई अन्य लोगों को समाधान के बिना इस समस्या का सामना करना पड़ा है - विभिन्न समाधानों के साथ मोनो को दोबारा बनाने के लिए एक समाधान का सुझाव दिया गया है, लेकिन यह उस सीमा को बढ़ाने के लिए प्रतीत होता है, इससे पहले कि यह दुर्घटनाग्रस्त हो जाए।


एमओएमए इस के लिए एक महान उपकरण है, जैसा कि किसी और ने सुझाव दिया था। इन दिनों असंगतता का सबसे बड़ा स्रोत वे अनुप्रयोग हैं जो Win32 पुस्तकालयों में DllImport (या P / Invoke) हैं। कुछ असेंबली लागू नहीं की जाती हैं, लेकिन उनमें से अधिकांश केवल विंडोज़ हैं और वास्तव में लिनक्स पर समझ नहीं पाएंगे। मुझे लगता है कि यह कहना सुरक्षित है कि अधिकांश एएसपी.NET अनुप्रयोग सीमित संशोधनों के साथ मोनो पर चल सकते हैं।

(प्रकटीकरण: मैंने मोनो में योगदान दिया है, साथ ही लिखित ऐप्स जो इसके शीर्ष पर चलते हैं।)


कई मामलों में, आप मौजूदा कोड ले सकते हैं और इसे मोनो पर चला सकते हैं, खासकर यदि आप एएसपी.NET एप्लिकेशन पोर्ट कर रहे हैं।

कुछ मामलों में, आपको इसे काम करने के लिए कोड के पूरे नए अनुभागों की आवश्यकता हो सकती है। यदि आप System.Windows.Forms का उपयोग करते हैं, उदाहरण के लिए, एप्लिकेशन असम्बद्ध काम नहीं करेगा। इसी प्रकार यदि आप किसी भी विंडोज-विशिष्ट कोड (उदाहरण के लिए रजिस्ट्री एक्सेस कोड) का उपयोग करते हैं। लेकिन मुझे लगता है कि सबसे खराब अपराधी यूआई कोड है। यह मैकिंतोश सिस्टम पर विशेष रूप से खराब है।


डेस्कटॉप पक्ष पर, यदि आप GTK # का उपयोग करने के लिए प्रतिबद्ध हैं तो मोनो बहुत अच्छा काम करता है। Windows.Forms कार्यान्वयन अभी भी एक छोटी छोटी गाड़ी है (उदाहरण के लिए, ट्रेएकॉन काम नहीं करता है) लेकिन यह एक लंबा सफर तय किया है। इसके अलावा, जीटीके # विंडोज फॉर्म की तुलना में एक बेहतर टूलकिट है जैसा कि यह है।

वेब तरफ, मोनो ने अधिकांश साइटों को पूरी तरह से चलाने के लिए पर्याप्त एएसपी.NET लागू किया है। यहां कठिनाई एक होस्ट को ढूंढ रही है जिसमें apache पर mod_mono इंस्टॉल है, या यदि आपके होस्ट में शैल पहुंच है तो इसे स्वयं कर लें।

किसी भी तरह से, मोनो महान और स्थिर है।

एक क्रॉस प्लेटफॉर्म प्रोग्राम बनाते समय याद रखने के लिए महत्वपूर्ण चीजें:

  • Windows.Forms के बजाय GTK # का उपयोग करें
  • अपने फ़ाइल नामों को ठीक से ठीक करने के लिए सुनिश्चित करें
  • "\" हार्डकोडिंग के बजाय Path.Separator प्रयोग करें, "\n" बजाय Environment.NewLinePath.Separator का भी उपयोग करें।
  • Win32 API में किसी भी पी / आमंत्रण कॉल का उपयोग न करें।
  • विंडोज रजिस्ट्री का प्रयोग न करें।

नहीं, मोनो गंभीर काम के लिए तैयार नहीं है। मैंने एफ # का उपयोग कर विंडोज पर कुछ कार्यक्रम लिखे और उन्हें मोनो पर चलाया। उन कार्यक्रमों ने डिस्क, मेमोरी और सीपीयू का काफी गहन उपयोग किया। मैंने मोनो पुस्तकालयों (प्रबंधित कोड) में क्रैश देखा, देशी कोड में क्रैश और वर्चुअल मशीन में क्रैश। जब मोनो ने कार्यक्रमों को काम किया था, तो विंडोज़ में नेट की तुलना में कम से कम दो गुना धीमी थी और अधिक मेमोरी का इस्तेमाल किया गया था। गंभीर काम के लिए मोनो से दूर रहें।


मैं तब कल्पना करूंगा कि यदि आपके पास कुछ तृतीय पक्ष घटकों के साथ कोई एप्लिकेशन है तो आपको भर दिया जा सकता है। मुझे संदेह है कि मोनो के साथ बहुत से विक्रेता विकसित होंगे

उदाहरण: http://community.devexpress.com/forums/p/55085/185853.aspx


मैं व्यक्तिगत रूप से एक प्राइम-टाइम env में मोनो का उपयोग करता हूं। मैं udp / tcp डेटा प्रोसेसिंग से संबंधित कार्यों के गीगा-बाइट्स से निपटने वाले मोनो सर्वर चलाता हूं और खुश नहीं हो सकता।

विशिष्टताएं हैं, और सबसे कष्टप्रद चीजों में से एक यह है कि आप मोनो की वर्तमान स्थिति के कारण अपनी एमएसबिल्ड फाइलों को "निर्माण" नहीं कर सकते हैं:

  • मोनो डेवेल (आईडीई) में कुछ आंशिक एमएसबिल्ड समर्थन है, लेकिन मूल रूप से किसी भी "असली" निर्माण को एक साधारण हैलो-वर्ल्ड (कस्टम बिल्ड कार्य, गतिशील "गुण" जैसे $ (SolutionDir) से परे, कुछ मृतकों के नाम पर वास्तविक कॉन्फ़िगरेशन -ends)
  • xbuild जो मोनो-सप्लाई-एमएसबिल्ड-पूरी तरह से संगत-निर्माण प्रणाली होनी चाहिए , और भी भयानक है, इसलिए कमांड लाइन से निर्माण वास्तव में जीयूआई का उपयोग करने से भी एक बुरा अनुभव है, जो कि "बहुत ही अपरंपरागत" स्थिति है लिनक्स वातावरण के लिए संघ ...

एक बार / वास्तव में अपनी सामग्री प्राप्त करने के दौरान, आप कुछ जंगल भी कोड के लिए देख सकते हैं जो समर्थित होना चाहिए:

  • संकलक कुछ संरचनाओं पर borked हो रही है
  • और कुछ और उन्नत / नए .NET कक्षाएं आप पर अप्रत्याशित बकवास फेंक रही हैं (XLinq कोई भी?)
  • कुछ अपरिपक्व रनटाइम "फीचर्स" (3 जीबी ढेर सीमा x64 ... डब्ल्यूटीएफ!)

लेकिन हेविंग ने कहा कि आमतौर पर बोलने वाली चीजें बहुत जल्दी काम करना शुरू कर देती हैं, और समाधान / कामकाज प्रचुर मात्रा में होते हैं

एक बार जब आप उन प्रारंभिक बाधाओं पर चले गए, तो मेरा अनुभव मोनो रॉक्स है, और हर पुनरावृत्ति के साथ बेहतर हो रहा है

मेरे पास मोनो के साथ चलने वाले सर्वर हैं, प्रति दिन 300 जीबी डेटा प्रोसेसिंग करते हैं, जिनमें बहुत से पी / इनवॉक्स होते हैं और आमतौर पर काम के बहुत सारे काम करते हैं और 5-6 महीने तक यूपी रहते हैं, यहां तक ​​कि "खून बहने वाले किनारे" मोनो के साथ भी।

उम्मीद है की यह मदद करेगा।


यह वास्तव में नामस्थान और कक्षाओं पर निर्भर करता है जिनका उपयोग आप .NET ढांचे से कर रहे हैं। मुझे अपने विंडोज सर्वर पर चलने के लिए मेरी विंडोज सेवाओं में से एक को बदलने में दिलचस्पी थी, जो सूज़ है, लेकिन हम एपीआई के साथ कई हार्ड रोडब्लॉक में भाग गए जो पूरी तरह लागू नहीं हुए थे। मोनो वेबसाइट पर कहीं एक चार्ट है जो सभी वर्गों और उनके पूरा होने के स्तर को सूचीबद्ध करता है। यदि आपका आवेदन कवर किया गया है, तो इसके लिए जाएं।

किसी भी अन्य आवेदन की तरह, निश्चित रूप से पूर्ण प्रतिबद्धता करने से पहले प्रोटोटाइपिंग और परीक्षण करें।

एक और समस्या जो हमने भागी है वह लाइसेंस प्राप्त सॉफ़्टवेयर है: यदि आप किसी और के डीएलएल का संदर्भ दे रहे हैं, तो आप उस असेंबली में दफन की गई असंगतताओं के आसपास अपना रास्ता कोड नहीं कर सकते हैं।


विचार करने के लिए कुछ परिदृश्य हैं: (ए) यदि आप मौजूदा एप्लिकेशन को पोर्ट कर रहे हैं और सोच रहे हैं कि क्या मोनो इस कार्य के लिए पर्याप्त है; (बी) आप कुछ नया कोड लिखना शुरू कर रहे हैं, और आप जानना चाहते हैं कि मोनो पर्याप्त परिपक्व है या नहीं।

पहले मामले के लिए, आप मोनो माइग्रेशन एनालिज़र टूल (मोमा) का उपयोग यह मूल्यांकन करने के लिए कर सकते हैं कि आपका एप्लिकेशन मोनो पर कितना दूर चल रहा है। यदि मूल्यांकन उड़ान रंगों के साथ वापस आता है, तो आपको अपने परीक्षण और क्यूए पर शुरू करना चाहिए और जहाज के लिए तैयार होना चाहिए।

यदि आपका मूल्यांकन मोनो में उनके अर्थशास्त्र में अनुपलब्ध सुविधाओं या सुविधाओं में भिन्नता को प्रदर्शित करने वाली एक रिपोर्ट के साथ आता है, तो आपको मूल्यांकन करना होगा कि कोड को अनुकूलित किया जा सकता है, फिर से लिखा जा सकता है या सबसे खराब स्थिति में आपका एप्लिकेशन कम कार्यक्षमता के साथ काम कर सकता है या नहीं।

उपयोगकर्ता सबमिशन (यह स्मृति से है) के आधार पर हमारे मोमा आंकड़ों के मुताबिक लगभग 50% आवेदन बॉक्स के बाहर काम करते हैं, लगभग 25% के लिए एक हफ्ते के लायक (रिफैक्टरिंग, एडैपटिंग) की आवश्यकता होती है, 15% को गंभीर प्रतिबद्धता की आवश्यकता होती है अपने कोड के दोबारा भाग, और शेष पोर्टिंग को परेशान करने के लायक नहीं हैं क्योंकि वे Win32 से बहुत अविश्वसनीय रूप से बंधे हैं। उस बिंदु पर, या तो आप शून्य से शुरू करते हैं, या एक व्यावसायिक निर्णय आपके कोड को पोर्टेबल बनाने के प्रयास को चलाएगा, लेकिन हम महीने के काम के बारे में बात कर रहे हैं (कम से कम हमारे पास रिपोर्ट से)।

यदि आप खरोंच से शुरू कर रहे हैं, तो स्थिति बहुत आसान है, क्योंकि आप केवल मोनो में मौजूद एपीआई का उपयोग करेंगे। जब तक आप समर्थित स्टैक के साथ रहें (जो कि बहुत अधिक .NET 2.0 है, साथ ही 3.5 में सभी मूल उन्नयन LINQ और System.Core, साथ ही मोनो क्रॉस-प्लेटफ़ॉर्म एपीआई सहित) आप ठीक होंगे।

हर बार एक बार आप मोनो या सीमाओं में बग में भाग सकते हैं, और आपको उनके आसपास काम करना पड़ सकता है, लेकिन यह किसी भी अन्य सिस्टम से अलग नहीं है।

पोर्टेबिलिटी के लिए: एएसपी.नेट अनुप्रयोग पोर्ट के लिए आसान हैं, क्योंकि जिनके पास Win32 पर कोई निर्भरता नहीं है और आप SQL सर्वर या अन्य लोकप्रिय डेटाबेस का भी उपयोग कर सकते हैं (मोनो के साथ बहुत सारे बंडल डेटाबेस प्रदाता हैं)।

विंडोज़.फॉर्म पोर्टिंग कभी-कभी ट्रिकियर होती है क्योंकि डेवलपर्स .NET सैंडबॉक्स से बचने के लिए पसंद करते हैं और पी / डब्ल्यूपीआरएम में बीसीडी फॉर्म में एन्कोड किए गए दो बेजियर पॉइंट्स के रूप में व्यक्त कर्सर ब्लिंकिंग दर को बदलने के रूप में चीजों को कॉन्फ़िगर करने के लिए अपने मस्तिष्क को आमंत्रित करते हैं। या उस तरह कुछ जंक।


हम इसे एक ऐसे प्रोजेक्ट के लिए इस्तेमाल कर रहे हैं जो लिनक्स पर चलाने के लिए आवश्यक है लेकिन कुछ .NET पुस्तकालयों का पुन: उपयोग करें जिन्हें हमने प्रबंधित सी ++ में बनाया था। मैं बहुत आश्चर्यचकित हूं कि यह कितनी अच्छी तरह से काम कर रहा है। हमारा मुख्य निष्पादन योग्य सी # में लिखा जा रहा है और हम किसी भी मुद्दे के साथ हमारे प्रबंधित सी ++ बाइनरी का संदर्भ दे सकते हैं। विंडोज और लिनक्स के बीच सी # कोड में एकमात्र अंतर आरएस 232 सीरियल पोर्ट कोड है।

एक महीने पहले हुआ एकमात्र बड़ा मुद्दा मैं सोच सकता हूं। लिनक्स बिल्ड में मेमोरी रिसाव था जो विंडोज़ बिल्ड पर नहीं देखा गया था। कुछ मैन्युअल डिबगिंग करने के बाद (लिनक्स पर मोनो के लिए मूल प्रोफाइलर बहुत मदद नहीं करते थे), हम इस मुद्दे को कोड के एक विशिष्ट खंड में सीमित करने में सक्षम थे। हम एक कामकाज को पकड़ने के लिए समाप्त हो गए, लेकिन मुझे अभी भी वापस जाने के लिए कुछ समय ढूंढना होगा और यह पता लगाना होगा कि रिसाव का मूल कारण क्या था।


हां यह निश्चित रूप से है (यदि आप सावधान हैं) हम रा-अजाक्स में मोनो का समर्थन करते हैं (अजाक्स लाइब्रेरी http://ra-ajax.org पर मिली) और हमें ज्यादातर समस्याएं नहीं हैं। आपको कुछ "सबसे पागल चीजों" से सावधान रहना चाहिए। नेट की तरह डब्लूएसई इत्यादि, और शायद आपकी कुछ मौजूदा परियोजनाएं 100% मोनो संगत नहीं होंगी, लेकिन यदि आप विकास के दौरान उनका परीक्षण करेंगे तो नई परियोजनाएं अधिकतर होंगी मोनो के साथ समस्याओं के बिना संगत हो। और मोनो का उपयोग करके लिनक्स आदि का समर्थन करने से लाभ वास्तव में अच्छा है;)

मोनो का समर्थन करने के रहस्य का एक बड़ा हिस्सा मुझे लगता है कि शुरुआत से सही उपकरण का उपयोग करना है, जैसे ActiveRecord, log4net, ra-ajax आदि ...





mono