👨🏽‍🌾 🔆 🃏 .NET / मोनो में ही मंच का उपयोग करते हुए लिपियों 🎣 🗯️ 👨🏿‍🏭

परिचय

यहां एक परियोजना पर काम करते समय, मुझे तीसरे पक्ष के डेवलपर्स द्वारा मक्खी पर परियोजना की कार्यक्षमता का विस्तार करने के लिए ले लिया गया, और मक्खी पर कोड को संपादित करने की क्षमता के साथ जितना संभव हो उतना विस्तार था। तदनुसार, प्लगइन्स इसके लिए बहुत उपयुक्त नहीं थे क्योंकि किसी भी संपादन के बाद उनके निरंतर पुन: उपयोग की आवश्यकता होती है। बाहर निकलें: स्क्रिप्ट। इससे पहले, मैं लंबे समय से स्क्रिप्ट के साथ काम कर रहा था और यह C ++ में Lua था। एक अच्छा विकल्प, अगर कुछ minuses के लिए नहीं:

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

तब मैंने सोचा - शायद .NET / मोनो में स्क्रिप्ट को लागू करने के लिए पहले से ही कुछ है? और जवाब हां था। नामस्थान " System.CodeDom.Compiler " बस वही था जिसकी मुझे ज़रूरत थी - .NET / मोनो पर्यावरण के साथ जितना संभव हो सके लिपियों को लागू करने की क्षमता। सच है, यदि आप अंदर से मेरे स्क्रिप्ट के तंत्र को देखते हैं, तो यह स्क्रिप्ट के लिए भी नहीं होता है, लेकिन C # में लिखा कोड बस गतिशील रूप से संकलित किया गया है और निष्पादन के लिए मेमोरी में लोड किया गया है। हालांकि, इस तरह के "नकली" होने के बावजूद, मैंने परिणाम प्राप्त किया - मैं कोड को सीधे अपने आवेदन में मक्खी पर फिर से जोड़कर संपादित कर सकता था। और एक ही समय में, यह उन मशीनों पर भी काम करेगा जहां विज़ुअल स्टूडियो और अन्य विकास उपकरण स्थापित नहीं हैं, क्योंकि संकलक, कम से कम C # और VB.NET, सही .NET और मोनो के साथ चलते हैं।
लेख में चर्चित उदाहरण को यहाँ डाउनलोड किया जा सकता है: http://zebraxxl.programist.ru/ScriptsInDotNet.zip

Namespace " System.CodeDom.Compiler "

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

और आमतौर पर किन भाषाओं का समर्थन किया जाता है?

यह जानने के लिए, केवल स्थिर विधि CodeDomProvider.GetAllCompilerInfo को कॉल करें। यह विधि ompilerInfo की एक सरणी लौटाएगा । सिद्धांत रूप में, निश्चित रूप से, यह हो सकता है कि एक संकलक एक साथ कई भाषाओं का समर्थन करता है, लेकिन व्यवहार में मुझे अब तक ऐसी बात का सामना नहीं करना पड़ा है। लेकिन जब कंपाइलर .NET / मोनो में कंपाइलर "बहुभाषी" होता है, तो इसे ठीक से बनाया जाता है ताकि पहले हमें व्यक्तिगत कंपाइलरों के बारे में जानकारी मिले और उसके बाद ही हम यह देखें कि कौन किस भाषा का समर्थन करता है। इस जानकारी को उदाहरण से कैसे आउटपुट किया जाए, इसके उदाहरण इस प्रकार हैं:

 0 compiler languages: c# cs csharp 1 compiler languages: vb vbs visualbasic vbscript 2 compiler languages: js jscript javascript 3 compiler languages: vj# vjs vjsharp 4 compiler languages: c++ mc cpp

जैसा कि यहाँ देखा जा सकता है - वास्तव में, मेरे पास अपने निपटान में 5 भाषाएँ हैं: C #, VB.NET, J #, JScript, C ++। आउटपुट यह भी दर्शाता है कि प्रत्येक संकलक एक भाषा परोसता है।
यहां आप इसे अन्य कंप्यूटरों पर जोड़ सकते हैं (विजुअल स्टूडियो स्थापित किए बिना, मेरे दोस्त की मशीन, जिसका आईटी और मेरे उबंटू सर्वर 11.04 से कोई लेना-देना नहीं है, मोनो रिपॉजिटरी (2.6.7) से एक ही परिणाम देता है)।
और कई भाषाओं का समर्थन हमें क्या देता है? और यह हमें देता है कि हम विभिन्न भाषाओं में स्क्रिप्ट लिख सकते हैं और एक ही समय में आवेदन में उनके प्रसंस्करण के बारे में सोचे बिना। और यह बदले में तीसरे पक्ष के डेवलपर्स के प्रवेश के स्तर को बढ़ाता है।

और अब वह है! संकलन

खैर, अब कुछ संकलन करने की कोशिश करते हैं। आइए C # में कुछ टेस्ट क्लास लिखें। यह फ़ाइल में पाया जा सकता है "TestScript.cs"। कक्षा ही काफी सरल है - सिर्फ दो विधियाँ। एक स्थिर है, दूसरा नहीं है। दोनों बस पाठ को कंसोल पर प्रिंट करते हैं और एक स्ट्रिंग लौटाते हैं। साथ ही, एक पैरामीटर को स्टैटिक में पास किया जाता है।
संकलन शुरू करने के लिए, हमें संकलन करने के लिए कुछ प्राप्त करना होगा। ऐसा करने के लिए, हम स्थिर विधि " CodeDomProvider.CreateProvider " पर अमल करते हैं। एक पैरामीटर के रूप में, यह उस भाषा का नाम लेता है जिसमें हम संकलित कर रहे हैं। पिछले चरण में हमें जो नाम मिले हैं।
अगला कदम संकलन विकल्पों में भरना है। सभी मापदंडों को " कम्पाइलरपैरामीटर " वर्ग में संग्रहीत किया जाता है। सबसे दिलचस्प क्षेत्र:

CompilerOptions - कंपाइलर के अतिरिक्त पैरामीटर (यानी जो पास किया जाएगा, उदाहरण के लिए, Csc के मामले में csc)
GenerateExecutable - एक निष्पादन योग्य फ़ाइल में एक असेंबली जनरेट करें । सामान्य तौर पर, वास्तव में, यह वैसे भी किया जाएगा। केवल यदि यह फ़ील्ड गलत है, तो निष्पादन योग्य फ़ाइल एक अस्थायी फ़ोल्डर में बनाई जाएगी। और अगर सच है, तो वह वह जगह होगी जहां " आउटपुटआसपास " क्षेत्र कहता है
GenerateInMemory - मेमोरी में एक असेंबली जनरेट करें । फिर, वास्तव में, पहली बार विधानसभा निष्पादन योग्य फ़ाइल में होगी, जहां से इसे लोड किया जाएगा।
DeDugugInformation एक बहुत ही उपयोगी क्षेत्र है। यदि आप यहां सही लिखते हैं, तो डिबगिंग जानकारी उत्पन्न होगी और मुख्य एप्लिकेशन के साथ सीधे स्क्रिप्ट को डीबग करना संभव होगा।
रेफ़रेंस एसेम्बलीज़ - संकलन करते समय उपयोग करने के लिए कौन सी असेंबली। वांछित क्षेत्र भी। अपनी परियोजना में, मैंने यहां मुख्य एप्लिकेशन का नाम लिखा है ताकि स्क्रिप्ट की संरचना तक पहुंच हो और यह पूरी तरह से एप्लिकेशन के साथ एकीकृत हो सके।

ठीक है, अब सब कुछ सरल है - हम कोडडोमप्रॉइडर कहते हैं ।CompileAssemblyFrom * इस आधार पर कि हमें स्रोत कहां से मिलता है। तीन विकल्प हैं:

CompileAssemblyFromFile - एक फ़ाइल से। अंतिम पैरामीटर संकलन करने के लिए फ़ाइल नामों की एक सूची है।
CompileAssemblyFromSource - तार से। यह समझा जाता है कि हमने पहले ही स्रोत फ़ाइलों को पढ़ा है और उन्हें अंतिम पैरामीटर में स्ट्रिंग की एक सरणी में संग्रहीत किया जाता है
CompileAssemblyFromDom - DOM सोर्स ट्री से। HTML (या xml) दस्तावेज़ के लिए DOM जैसा कुछ है

इन सभी विधियों में पहला पैरामीटर " कंपाइलरपैरामीटर " पैरामीटर है। नतीजतन, हमें " CompilerResults " मिलता है। यहां से आप सभी जानकारी प्राप्त कर सकते हैं कि संकलन कैसे गया। सबसे दिलचस्प और आवश्यक फ़ील्ड " CompilerResults ":

CompiledAssembly - परिणामस्वरूप असेंबली मेमोरी में लोड की गई (यदि GenerateInMemory फ़ील्ड सेट की गई थी
त्रुटियां - त्रुटियां और चेतावनी जो संकलक जारी करता है

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

क्या स्क्रिप्ट सरल है?

स्क्रिप्ट के रूप में इस तरह की शक्तिशाली भाषा का उपयोग करना निश्चित रूप से अच्छा है - यह एप्लिकेशन की कार्यक्षमता के विस्तार के लिए शानदार अवसर खोलता है, लेकिन कुछ मामलों में यह एक माइक्रोस्कोप के साथ कील क्लॉजिंग हो सकता है। कोड जटिलता के लिए दो विकल्पों में अंतर स्पष्ट है:

 using System; namespace Script { public class Script { public static void M() { Console.WriteLine(“Hello world”); } } }

या यह विकल्प:

 WriteLine(“Hello World”);

दो कोड जो मूल रूप से एक ही काम करते हैं (बशर्ते कि दूसरे संस्करण में, WriteLine का मतलब System.Console.WriteLine पर कॉल है) - लेकिन जैसा कि वे कहते हैं: "अंतर महसूस करें।"
इस सरलीकरण को प्राप्त करने के कई तरीके हैं। और उनमें से प्रत्येक के अपने फायदे और नुकसान होंगे। हालांकि, वे सभी एक चीज के लिए नीचे आएंगे: गतिशील रूप से "छोटे" एक से "बड़ा" कोड उत्पन्न करना। उदाहरण के लिए, मैंने सबसे आसान तरीका निकाला, जिसके साथ मैं आ सकता था:

मैंने एक अलग वर्ग बनाया (इसके बाद कार्यान्वयन वर्ग के रूप में जाना जाता है) जिसमें वे सभी विधियाँ हैं जो लिपियों में वैश्विक हैं (उदाहरण के लिए, MiniScriptWorker वर्ग)।
"बड़ी" कोड बनाने के लिए एक टेम्पलेट बनाया गया - कार्यान्वयन वर्ग का एक बच्चा एक खाली विधि के साथ (फ़ाइल "ScriptTemplate" .cs))
"छोटा" कोड बस उस खाली वर्ग-टेम्पलेट पद्धति के कार्यान्वयन में डाला जाता है (फ़ाइल "MiniScript.cs")

निष्कर्ष

ऐसे सरल तरीके से, हमें अतिरिक्त निर्भरता को खींचने की आवश्यकता के बिना .NET / मोनो एप्लिकेशन में लगभग काफी शक्तिशाली स्क्रिप्ट मुफ्त में मिलती हैं। हां - कुछ मामलों में, यह विधि शायद बेमानी भी होगी, लेकिन यह सब कार्य पर निर्भर करता है - मेरे मामले में, इस तरह का कार्यान्वयन सबसे अच्छा और सबसे सुविधाजनक था।
एक बार फिर से, इस पद्धति के नियम: स्क्रिप्ट के रूप में आपके पास .NET / मोनो पर्यावरण तक लगभग पूर्ण पहुँच के साथ एक शक्तिशाली भाषा होगी (यह पूरा करना आपके लिए यह तय करना है कि आप जो संकलन समय पर जोड़ते हैं, वह स्क्रिप्ट के लिए उपलब्ध होगा)। इसके अलावा, बस स्क्रिप्ट के लिए असेंबली की सूची में अपने आवेदन को जोड़ते हुए, आपको अपने आवेदन के साथ लगभग पूर्ण एकीकरण और इसे संशोधित करने की क्षमता मिलेगी जिस तरह से आप या स्क्रिप्ट डेवलपर चाहते हैं।
हालाँकि, विपक्ष भी इससे बढ़ता है। कभी-कभी स्क्रिप्ट से मुख्य एप्लिकेशन के कुछ टुकड़े को छिपाना आवश्यक हो सकता है। आप ऐसे हिस्सों को " आंतरिक " दायरे में छिपाकर खुद को इससे बचा सकते हैं। सच है, इस सुरक्षा को एक और समस्या द्वारा दरकिनार किया जा सकता है - .NET / मोनो पर्यावरण के लिए इस तरह की व्यापक पहुंच के कारण सुरक्षा ग्रस्त है। उदाहरण के लिए, पासवर्ड के साथ कुछ फ़ाइल खोलने के लिए System.IO.FileStream का उपयोग करके हमें कुछ भी नहीं रोका जा सकता है और फिर चुपचाप अपनी सामग्री को गलत हाथों में भेज सकते हैं। दुर्भाग्य से, मेरे पास अभी तक इस समस्या का समाधान नहीं है - मैंने इस मुद्दे को अधिक विस्तार से पार्स करने का प्रबंधन नहीं किया।