एंटरप्राइज़ विंडोज़-आधारित समाधानों के लिए, .NET कभी-कभी सबसे अच्छा विकल्प है। मोनो को उन उद्यमों द्वारा कैसे देखा जाता है जिन्हें लिनक्स का उपयोग करना है (या बल्कि लिनक्स का उपयोग करना पसंद करते हैं)? यह मानते हुए कि डेवलपर्स कोई समस्या नहीं है और वे .NET / मोनो और जावा जैसे अन्य संभावित प्रतियोगियों से परिचित हैं।
क्या एक मध्यम / बड़ी कंपनी जावा जैसी प्रौद्योगिकियों के विपरीत मोनो को अपने सर्वर पर चलाएगी? क्या आप ऐसी किसी कंपनी के बारे में जानते हैं?
जवाबों:
हमने इसका उपयोग बड़े निगम में किया जहां मैं काम करता हूं। हमने इस परियोजना की शुरुआत से इस पर योजना नहीं बनाई थी लेकिन इसने इस तरह से काम किया।
हमारे पास एक आंतरिक परियोजना थी जो हमने .NET में विकसित की थी, एक बार जब हम UAT में आ गए, तो व्यवसाय के मालिक कुछ ग्राहकों के साथ-साथ आंतरिक कर्मचारियों के लिए भी ऐप खोलना चाहते थे। हमारे बाहरी (DMZ) सर्वरों में से अधिकांश लिनक्स आधारित हैं और Windows सर्वर जो DMZ में हैं, वे एक अच्छे फिट (क्षमता के करीब) नहीं थे। नए हार्डवेयर खरीदने के बजाय किसी ने मोनो पर ऐप चलाने का सुझाव दिया। हमने अपनी टेस्टिंग करते हुए कुछ दिन बिताए और फिर QA, फिर UAT को ऐप जारी किया। हमारे पास कोई मुद्दा नहीं था।
यदि हमें परियोजना की शुरुआत में आवश्यकता दी गई थी, तो हमने इसे .NET में लिखने के लिए नहीं चुना हो सकता है, लेकिन यह बहुत, बहुत देर से आवश्यकता परिवर्तन के लिए एक अच्छा परिणाम था। अब हमें पूरा विश्वास है कि अगर यह फिर से आया तो हम सफलतापूर्वक मोनो को तैनात कर सकते हैं (हालांकि मुझे लगता है कि अंततः हमें कुछ कोड को ट्विस्ट करना होगा, मुझे लगता है कि हम अभी भाग्यशाली हैं)।
मैंने व्यावसायिक रूप से मोनो का उपयोग नहीं किया है, लेकिन मैं इसे निजी तौर पर उपयोग करता हूं, क्योंकि मैं एक विंडोज कंपनी में काम करता हूं, लेकिन निजी तौर पर एक लिनक्स उपयोगकर्ता हूं (इसलिए मैं जो काम करता हूं उसका पुन: उपयोग कर सकता हूं)।
कुल मिलाकर, मैं मिगुएल डे इकजा से सहमत हूं जो कहते हैं:
- .NET के 25% एप्लिकेशन मोनो के साथ बॉक्स से बाहर काम करते हैं
- एक और 25% एक दिन या उससे कम समय में काम करने के लिए बनाया जा सकता है
- आगे 25% एक सप्ताह के भीतर काम करने के लिए बनाया जा सकता है
- अंतिम 25% को एप्लिकेशन के पूर्ण पुनर्लेखन की आवश्यकता होती है (WinForms / COM)
मोनो काफी अच्छी तरह से काम करता है, लेकिन कुछ समस्याएं हैं:
- VB.NET केवल .NET <= 2.0 के लिए समर्थन करता है
- विंडोज प्रमाणीकरण लागू नहीं किया गया
- WPF लागू नहीं किया गया
- WCF समर्थन अधूरा है
- एंटिटी फ्रेमवर्क लागू नहीं हुआ और न ही कोई योजना लागू की गई
- "ASP.NET वेब पार्ट्स" लागू नहीं किया गया
- कोई COM- इंटरॉप समर्थन
- संस्करण 15.5 के लिए साइबेस कनेक्शन (नवीनतम) काम नहीं करता है
- सी # क्लास लाइब्रेरी में कीड़े और अपूर्णता (जैसे XML मोनो में छोटी गाड़ी थी <<2.6)
- लिनक्स वेब-ब्राउज़र नियंत्रण के लिए GTK # की आवश्यकता है
फिर छोटी समस्याएं:
- विंडोज फॉर्म काम करते हैं, लेकिन हमेशा सही तरीके से प्रस्तुत नहीं किए जाते हैं
- MonoDevelop विंडोज़ रूपों को डिज़ाइन नहीं कर सकता है
- 'डिबगिंग' के माध्यम से मोनोएडवैल 'कदम वास्तव में काम नहीं करता है
- 5 घंटे के बाद मोनो-सर्विस क्रैश ...
फार्म मैं क्या कह सकता हूँ:
- WebServices उत्कृष्ट रूप से कार्य करता है
- यदि आप एक WebApplication चलाते हैं, तो यह काफी अच्छी तरह से काम करता है (यदि यह WebParts का उपयोग नहीं करता है)।
- यदि आप WindowsForms चलाते हैं, तो यह हमेशा बहुत अच्छा नहीं लगेगा (कम से कम कहने के लिए)।
- Microsoft रिपोर्टिंग सेवा के लिए कोई समतुल्य काम नहीं कर रहा है (FYIreporting इसके सबसे करीब है, लेकिन यह धीमी, छोटी और बहुत अधूरी है, साथ ही एक वर्ष से अधिक समय से कोई गतिविधि नहीं है)
- यदि आपको Word या Excel दस्तावेज़ बनाने की आवश्यकता है, तो आप समस्याओं का अनुभव करेंगे।
यदि आप लिनक्स पर .NET विकसित करना चाहते हैं
- आप ASP.NET का विकास कर सकते हैं (बहुत बुरी तरह से काम करता है)
- आप वास्तव में लिनक्स पर WinForms विकसित नहीं कर सकते
- आपको WinForms के बजाय GTK # का उपयोग करने की आवश्यकता है
दूसरे शब्दों में:
- मोनो के पास वेब एप्लिकेशन और WebServices और MailServers चलाने के लिए जगह है।
- लेकिन WindowsForms एप्लिकेशन चलाने के लिए यह व्यवहार्य नहीं है, आपको GTK # के साथ एप्लिकेशन लिखने की आवश्यकता है
- यह एक रिपोर्टिंग समाधान और एमएस फ़ाइल प्रारूप समर्थन (या इसलिए काम कर पुस्तकालयों) का अभाव है
संपादित करें (2015 अद्यतन):
मैं चाहता था कि अब तक 'डिबगिंग के माध्यम से' कदम उत्कृष्ट रूप से काम करता है, और आप लिनक्स पर वेब अनुप्रयोगों को विकसित करने के लिए मोनूडेवलप का उपयोग कर सकते हैं, यहां तक कि nuGet निर्भरता के साथ भी। एक्सेल और वर्ड लाइब्रेरी की समस्या भी दूर हो गई है, और इकाई-ढांचा अब खुला-स्रोत है। बाकी बहुत अधिक "जैसा है" (पता नहीं है कि मोनो-सर्विस तय है, लेकिन मुझे आशा है कि ऐसा होगा)।
साथ ही जो सुधार हुआ है वह यह है कि अब आप अपने डिस्ट्रो के लिए वर्तमान पैकेज रख सकते हैं, जिसका अर्थ है कि आपको अगले रिलीज तक इंतजार करने की आवश्यकता नहीं है, डेबियन / उबंटू कहते हैं, जब तक आपको नवीनतम मोनो संस्करण नहीं मिलते (बिना उन्हें अपने आप को संकलित करने के लिए )। यह एक प्रमुख समय-सुरक्षित है।
इसके अलावा, रोज़लिन की रिहाई के साथ, निकट भविष्य में VB.NET समर्थन को बहुत बेहतर होना चाहिए।
मेरी कंपनी एक प्रमुख ज्यादातर- .NET डेस्कटॉप एप्लिकेशन विकसित करती है और मोनो पर चलने वाले लिनक्स संस्करण जारी करती है, इसलिए मैं कहूंगा कि हां, एंटरप्राइज़ विंडोज-आधारित समाधान में मोनो के लिए एक जगह निश्चित रूप से है।
हम अपने एप्लिकेशन की स्थापना के साथ मोनो को पैकेज करते हैं, उपयोगकर्ताओं को इसे अलग से इंस्टॉल करने की आवश्यकता नहीं है (और इस तरह हम संस्करण को नियंत्रित करते हैं, भी)।
मुझे लगता है कि कई कॉरपोरेट्स की मुख्य चिंता मोनो और माइक्रोसॉफ्ट के बीच लाइसेंस के मुद्दे हैं। मेरी समझ यह है कि जब Microsoft औपचारिक रूप से सहमत हो गया है कि मोनो कोर .NET प्रौद्योगिकियों का उपयोग कर सकता है, लेकिन इसके अलावा, बहुत ही सामान्य रूप से उपयोग किए जाने वाले सामानों सहित, एक ग्रे क्षेत्र का अधिक कानूनी रूप से Microsoft द्वारा इस पर कोई फर्म स्थिति नहीं बताते हुए एक तरीका है या अन्य।
यह स्पष्ट रूप से इस संभावना को खोलता है कि लाइन के नीचे वे लाइसेंस फीस की मांग करेंगे या पेटेंट उल्लंघन के लिए मुकदमा करेंगे। यह संभावना नहीं है कि या तो जिस तरह से वे अभी व्यवहार कर रहे हैं उससे होगा, लेकिन ज्यादातर कॉर्पोरेट्स अनिश्चितता के उस प्रकार को पसंद नहीं करते हैं, खासकर जब यह संभावित देनदारियों और लागतों के साथ आता है।
मुझे नहीं लगता कि वहां मोनो के लिए बहुत जगह है:
जावा लिनक्स पर पहले से ही स्थापित मंच है, जिसमें विशाल समुदाय और उद्यम गुणवत्ता पुस्तकालयों और उपकरणों की प्रचुरता है, दोनों वाणिज्यिक और ओपन-सोर्स। जब तक कि कुछ विशिष्ट परिस्थिति न हो, तब तक लिनक्स (या मैक) को लक्षित करने वाली नई परियोजना शुरू करते समय मुझे जावा पर मोनो लेने का कोई कारण नहीं दिखता है (वाल्टर का उत्तर देखें)।
मोनो का उपयोग करने से पहले, हमें सीरियल पोर्ट के लिए पथ स्ट्रिंग (उपयोग Path.Combine ()) या "COM" उपसर्ग (बस पूर्णांक के बजाय स्ट्रिंग को स्वीकार करें) के लिए कोई हार्डकोड नहीं करना है।
क्या अच्छा काम करता है:
समस्यांए सामने आई है:
एक नियंत्रित वातावरण के रूप में आंतरिक रूप से (जैसे ईआरपी सिस्टम) मोनो का उपयोग करना बेहतर है।
मोनो एक बढ़िया विकल्प है यदि आपके पास पहले से ही .NET कोड है जिसे क्रॉस-प्लेटफ़ॉर्म वातावरण पर चलाने की आवश्यकता है। विशेष रूप से इस बहुत समस्या को हल करने के लिए विशेष रूप से व्यापारिक दुनिया में मोनो का बड़े पैमाने पर उपयोग किया जाता है।
मैं .NET के साथ एक परियोजना शुरू करने के लिए एक बहाने के रूप में मोनो के अस्तित्व का उपयोग करने के खिलाफ तर्क दूंगा कि आपको पता है कि क्रॉस-प्लेटफॉर्म होना चाहिए। इसका कारण मोनो के विकास की गति बनाम .NET के साथ अत्याधुनिक के बीच अंतराल है।
दूसरी ओर, यदि आप करते हैं एक भविष्य परियोजना में मोनो उपयोग करना चाहते हैं, मैं तुम्हें मोनो ढांचे को लक्षित और नेट पर चलने के लिए सावधानी के रूप में मोनो के बाद से एक माध्यमिक विकल्प काफी हद तक पूरा नेट कार्यक्षमता का एक सबसेट है जाएगा।