👩🏾‍🤝‍👩🏼 👨‍👩‍👦 👒 .Net पर उत्पन्न करें 💃 👊🏻 💳

.Net कोड उत्पन्न करने के कई तरीके हैं:

परावर्तन एमिट। .Net 1.0 संस्करण से उपलब्ध है।
CodeDom। आपको कोडडॉम दृश्य से या सीधे उच्च-स्तरीय भाषाओं में से किसी एक में लिखे स्रोतों से डायनामिक कोड बनाने की अनुमति देता है, उदाहरण के लिए C #, VB या JScript। .Net 1.0 संस्करण से उपलब्ध है।
अभिव्यक्ति के पेड़। .Net 3.5 से उपलब्ध है। आपको एक्सप्रेशन दृश्य से डायनामिक कोड बनाने की अनुमति देता है।

इस लेख में मैं रिफ्लेक्शन एमिट का उपयोग करके कोड जनरेशन तकनीक के बारे में बात करना चाहता हूं।

पीढ़ी के तरीकों के बारे में थोड़ा और

पहली .net वर्चुअल मशीन के लिए CIL कोड की प्रत्यक्ष पीढ़ी (जिसे MSIL या केवल IL के रूप में भी जाना जाता है) है। इस मामले में, उत्पन्न कोड सीआईएल में वर्णित है, जो उपस्थिति में स्टेरॉयड पर कोडांतरक जैसा दिखता है। आउटपुट पर, आपको डायनेमिक क्लासेस और मेथड्स या "नंगे" डायनामिक मेथड के साथ एक डायनामिक असेंबली (डिस्क में इसे सेव करने की संभावना के साथ) मिलती है। फिर अपने विवेक पर उत्पन्न अच्छे का उपयोग करें।
दूसरा उच्च-स्तरीय भाषा (उदाहरण के लिए, C # या VB) में स्रोत कोड की पीढ़ी है, और फिर CIL में स्रोतों का बाद का संकलन है। आउटपुट असेंबली कंपाइलर द्वारा बनाई गई असेंबली है।
तीसरी अभिव्यक्ति ट्री दृश्य से पीढ़ी है। आप एक्सप्रेशन विधियों का उपयोग करते हुए कुछ एएसडी का वर्णन करते हैं, और फिर वही एक्सप्रेशन वर्णित विधि उत्पन्न करता है। आंतरिक रूप से, एक्सप्रेशन एएसडी (एएसटी) के कुछ उपयोगी सत्यापन का उत्पादन करते हुए, अपने प्रतिनिधित्व को तुरंत सीआईएल कोड में बदल देता है। लेकिन अभिव्यक्ति ट्री अपनी क्षमताओं में सीमित है - आप अपने प्रकार और विधानसभाओं को उत्पन्न नहीं कर सकते हैं और तदनुसार, उन्हें डिस्क पर सहेजें।

हम जनगणना करेंगे

CIL में क्यों, और उच्च-स्तरीय भाषा में नहीं? CIL में जनरेशन अधिक कुशल है, क्योंकि एक उच्च-स्तरीय भाषा में जनरेशन का मतलब इस भाषा में स्रोत कोड बनाना और फिर CIL में उन्हें संकलित करना है। इसके अलावा, ऊपरी स्तर की भाषा में पीढ़ी को बाहरी प्रक्रिया - संकलक की भागीदारी की आवश्यकता होती है। और फिर भी - यह एक .net प्रोग्रामर के लिए कोडांतरक के समान कुछ के साथ बेला करने का एक दुर्लभ अवसर है। लेकिन एक उच्च-स्तरीय भाषा में पीढ़ी के अपने फायदे हैं: CIL से निपटने की कोई आवश्यकता नहीं है, आप एक परिचित भाषा में कोड उत्पन्न करते हैं। इसके अलावा, ऐसी कोड पीढ़ी के स्रोतों को हमेशा लॉग में सहेजा जा सकता है या डंप किया जा सकता है, और फिर आंख से सत्यापित या आईडीई में डाला जा सकता है और डीबग किया जा सकता है।

यह कैसा दिखता है

प्रतिबिंब उत्सर्जन का उपयोग करके कोड उत्पन्न करने के लिए, आपको कोडांतरक की न्यूनतम समझ होनी चाहिए। सीआईएल असेंबलर में कोई रजिस्टर, ऑफसेट या चालाक पता नहीं है। वहाँ क्या है? गणना का एक ढेर है, सभी ऑपरेशन केवल इसके साथ काम करते हैं, कोई रजिस्टर नहीं हैं। उसी समय, कंप्यूटिंग स्टैक को एक कारण के लिए नाम दिया गया है, इसमें स्थानीय चर और विधि तर्क शामिल नहीं हैं - CIL के लिए ये अलग-अलग अवधारणाएं हैं। अभी भी ऑपरेशन हैं। वे दो प्रकार के होते हैं: साधारण असेंबलर (विभिन्न प्रकार के संक्रमण, गणितीय संचालन, विधि कॉल आदि) या विशेष सीएलआर (बॉक्स / अनबॉक्स, न्यूबॉज, आइंस्टीन, आदि)। हालांकि, अलगाव विशुद्ध रूप से औपचारिक है।

पर्याप्त शब्द, आइए जनरेट करना शुरू करें

सौ बार सुनने की तुलना में एक बार देखना बेहतर है, और इससे भी बेहतर - पट्टे पर। यह मेरे लिए पर्याप्त शब्द हैं, आइए एक उदाहरण देखें।
कार्य को ऐसा होने दें: कुछ संस्थाओं का एक ट्रांसफार्मर दूसरों में उत्पन्न करें। यानी ऐसी कक्षाएं हैं जो अनिवार्य रूप से समान हैं, लेकिन विभिन्न संपत्ति नामों के साथ। उदाहरण के लिए:

public class TestSrc { public int SomeID { get; set; } } public class TestTarg { public double SomeOtherID { get; set; } }

हमें TestSrc को TestTarg में बदलना होगा। हमारे कन्वर्टर को इस तरह देखें:

 class Mapper<TIn, TOut> { protected delegate TOut MapMethod(TIn src); public TOut Map(TIn source) {...} private MapMethod GenerateMapMethod(IDictionary<string, string> mapping) {...} }

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

गतिशील विधानसभा

पहले हमें एक विकल्प बनाने की आवश्यकता है: हमारा उत्पन्न कोड कहां स्थित होगा? दो विकल्प हैं - एक गतिशील विधानसभा में या एक गतिशील विधि में। वह दोनों, और दूसरा "फ्लाई पर" बनाया गया है।
डायनेमिक असेंबली एक पूर्ण समाधान है, यह आपको वास्तविक कक्षाओं और संरचनाओं को किसी भी तरीके के सेट के साथ उत्पन्न करने की अनुमति देता है। डायनेमिक असेंबली का एक और प्लस बाद में आपके द्वारा वहां उत्पन्न किए गए उपयोग या विश्लेषण के लिए इसे बचाने की क्षमता है। यह मुश्किल मामलों के लिए है।
तो, एक वर्ग और एक स्थिर विधि के साथ एक विधानसभा बनाएं:

 protected MapMethod GenerateMapMethod(IDictionary<string, string> mapping) { var dynGeneratorHostAssembly = AppDomain.CurrentDomain.DefineDynamicAssembly( new AssemblyName("Test.Gen, Version=1.0.0.1"), AssemblyBuilderAccess.RunAndSave); var dynModule = dynGeneratorHostAssembly.DefineDynamicModule( "Test.Gen.Mod", "generated.dll"); var dynType = dynModule.DefineType( "Test.MapperOne", TypeAttributes.Abstract | TypeAttributes.Sealed | TypeAttributes.Public); var dynMethod = dynType.DefineMethod( "callme", MethodAttributes.Static, typeof(TOut), new Type[] { typeof(TIn) }); var prm = dynMethod.DefineParameter(1, ParameterAttributes.None, "source"); GenerateMapMethodBody(dynMethod.GetILGenerator(), prm, mapping); var finalType = dynType.CreateType(); dynGeneratorHostAssembly.Save("generatedasm.dll"); var realMethodInfo = finalType.GetMethod(dynMethod.Name); var methodToken = dynMethod.GetToken().Token; var methodInfo = dynModule.ResolveMethod(methodToken); return (MapMethod)Delegate.CreateDelegate( typeof(MapMethod), (MethodInfo)methodInfo); }

यह कोड क्या करता है? हां, सामान्य तौर पर, जो लिखा जाता है वह क्या करता है - यह वर्तमान डोमेन में एक डायनामिक असेंबली को परिभाषित करता है (आप एक अलग बना सकते हैं) और यह दर्शाता है कि हम असेंबली का उपयोग कैसे करेंगे: केवल रन, केवल सहेजें, या सभी को एक साथ (असेम्बली द्वारा निर्धारित) यदि आप असेंबली को निर्दिष्ट करते हैं तो यह ज्ञात नहीं है कि कोई महत्वपूर्ण ओवरहेड होगा या नहीं। .Net 4 में, पृष्ठांकित डायनामिक असेंबली (असेंबलीब्राउटलअबेल.ऑनएंडकॉलेज) बनाने की क्षमता दिखाई दी है। असेंबली को अनलोड करने के लिए, किसी को इस असेंबली के प्रकारों और स्वयं के प्रकारों का संदर्भ नहीं देना चाहिए, यहां अधिक विवरण देखें।
अगला, हम विधानसभा में मॉड्यूल का निर्धारण करते हैं। हमें याद है कि असेंबली में मॉड्यूल शामिल होते हैं, अक्सर एक विधानसभा एक मॉड्यूल होती है, लेकिन मल्टी-मॉड्यूल असेंबलियां भी हो सकती हैं। एक मॉड्यूल एक भौतिक फ़ाइल से मेल खाता है, इसलिए, एक मॉड्यूल को परिभाषित करते समय, हम इसके लिए फ़ाइल नाम निर्दिष्ट करते हैं।
मॉड्यूल में, हम प्रकार निर्धारित करते हैं - यह एक वर्ग या संरचना हो सकता है। एक साधारण DefineType कॉल ("Test.MapperOne") टेस्ट नाम में एक निजी मैपरऑन क्लास बनाएगी। इस तथ्य के बावजूद कि आपको नाम से उत्पन्न वर्गों और विधियों को संदर्भित नहीं करना पड़ सकता है, उन्हें बेहतर नाम और नाम स्थान देना बेहतर है, क्योंकि, सबसे पहले, वे निशान के ढेर पर दिखाई देते हैं, और दूसरी बात, यदि आप विश्लेषण करते हैं एक परावर्तक के साथ उत्पन्न संरचना स्पष्ट और अधिक सुखद होगी। "बंद करो!", चौकस पाठक कहेंगे। आखिरकार, जो वर्ग हमें मिलता है वह निजी है, और यहां तक कि एक अलग विधानसभा में, क्या हम इसे बदल सकते हैं? ठीक है, वास्तव में, हम कर सकते हैं। लेकिन अगर आप चाहते हैं कि सब कुछ सख्ती से सही हो, तो इस तरह से लिखें:

 var dynType = dynModule.DefineType("Test.MapperOne", TypeAttributes.Abstract | TypeAttributes.Sealed | TypeAttributes.Public);

और अंत में, प्रकार में, हम इसके द्वारा लौटाए गए मूल्य के प्रकार और विधि के इनपुट तर्कों के प्रकार को निर्दिष्ट करके हमारी पद्धति को परिभाषित करते हैं।
अगला, हमें अपनी उत्पन्न विधि को अर्थ के साथ भरने की आवश्यकता है। हम इस प्रक्रिया पर बाद में विस्तार से विचार करेंगे, इसलिए हम GenerateMapMethodBody (dynMethod.GetILGenerator (), prm, मैपिंग) पर कॉल छोड़ें और आगे देखें।
प्रकार की सभी विधियाँ उत्पन्न होने के बाद, हमें dynType.CreateType () विधि को कॉल करके प्रकार बनाना होगा। उसके बाद, प्रकार के साथ कोई गतिशील जोड़तोड़ संभव नहीं हो जाता है। लेकिन तब हमारा प्रकार अब उपयोग के लिए तैयार है। CreateType को कॉल करने से पहले, CLR को हमारे प्रकार और उसमें मौजूद तरीकों के बारे में कुछ नहीं पता है। असेंबली के विपरीत, जो DefineDynamicAssembly कॉल के तुरंत बाद डोमेन में दिखाई देता है, और DefineDynamicModule कॉल के तुरंत बाद असेंबली में दिखाई देने वाला मॉड्यूल।
एक दिलचस्प बिंदु: जब हमने डेफिन टाइप विधि का उपयोग करके एक गतिशील प्रकार को परिभाषित किया, तो यह हमारे लिए टाइपबर्स्टल लौटा। यदि आप TypeBuilder को देखते हैं, तो यह Type से विरासत में मिला है, लेकिन यदि आपका Type TypeBuilder है, तो सभी प्रकार के तरीकों को एक्सेस नहीं किया जा सकता है। यदि आप इसके बारे में सोचते हैं, तो यह तर्कसंगत है, क्योंकि अभी तक कोई प्रकार नहीं है। कुछ प्रकार के गुणों को ओवरराइड किया जाता है ताकि वे हमेशा एक NotSupportedException लौटाएं। कुछ तरीके CreateType को कॉल करने से पहले एक अपवाद को फेंक देते हैं, और फिर संबंधित RuntimeType पर कॉल पुनर्निर्देशित करना शुरू करते हैं। इसी तरह की स्थिति मेथडबॉयल क्लास के साथ है, जो मेथडइनफो से विरासत में मिली है। MethodBuilder भी सभी गुणों और विधियों को लागू नहीं करता है। एक और स्थिति इस तथ्य से जटिल है कि, उदाहरण के लिए, Delegate.CreateDelegate MethodInfo को दूसरे तर्क के रूप में लेता है, लेकिन यदि आप वहां MethodBuilder पास करने का प्रयास करते हैं, तो आपको एक अपवाद मिलेगा (CreateType को कॉल करने के बाद भी)। इसलिए सावधान रहें।

गतिशील विधि

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

 protected MapMethod GenerateMapMethod2(IDictionary<string, string> mapping) { var dynMethod = new DynamicMethod("callme", typeof(TOut), new Type[] { typeof(TIn) }); var prm = dynMethod.DefineParameter(1, ParameterAttributes.None, "source"); GenerateMapMethodBody(dynMethod.GetILGenerator(), prm, mapping); return (MapMethod)dynMethod.CreateDelegate(typeof(MapMethod)); }

उन्होंने एक विधि बनाई, उसे अर्थ से भर दिया और उसके लिए एक प्रतिनिधि लौटा दिया। हो गया। हालाँकि प्रलेखन कहता है कि इस तरह की विधि को डायनेमिक असेंबली, मॉड्यूल और प्रकार की आवश्यकता नहीं है, यदि आप प्रतिबिंब या प्रोसेसएक्सप्लेयर का उपयोग करते हैं, तो आप देखेंगे कि डायनेमिक असेंबली फिर भी बनाई गई है (सभी डायनामिक डोमेन विधियों में से एक)। और यहां तक कि इसमें एक प्रकट मॉड्यूल भी है, लेकिन मैं इसे (परावर्तन द्वारा) हमारी विधि में नहीं ढूंढ सका। फिर भी, वह है और काम करता है। गतिशील विधि और अपनी पीढ़ी के लिए आवंटित सभी मेमोरी को मुक्त कर दिया जा सकता है क्योंकि कोई भी इसे संदर्भित नहीं करता है। इसलिए, यह विधि थोड़ी तेज और अधिक किफायती होगी। इस मामले में, हम विधि के लिए अनाम होस्टिंग (अनाम रूप से होस्ट किए गए) का उपयोग करते हैं, लेकिन मौजूदा मॉड्यूल या यहां तक कि एक वर्ग के लिए हमारी विधि "छड़ी" करने का विकल्प है। इसके लिए विशेष निर्माता हैं जो एक मॉड्यूल या प्रकार को स्वीकार करते हैं, जिसमें हम एक गतिशील विधि जोड़ते हैं। एक मॉड्यूल के मामले में, मॉड्यूल के लिए प्रकार वैश्विक हो जाता है और आंतरिक लोगों सहित सभी प्रकार के मॉड्यूल तक पहुंच होती है। वर्ग के मामले में, हमारे पास अभी भी कक्षा के सभी आंतरिक क्षेत्रों तक पहुंच होगी। लेकिन यहां तक कि अगर आप "अनाम" होस्टिंग का उपयोग करते हैं, तो भी आपके पास एक गतिशील विधि से इन वर्गों और यहां तक कि इन वर्गों के आंतरिक क्षेत्रों तक पहुंचने का अवसर है। ऐसा करने के लिए, स्किपर विजिबिलिटी पैरामीटर के साथ कंस्ट्रक्टर का उपयोग करें और इस पैरामीटर को सही पर सेट करें (यह पैरामीटर इंगित करता है कि JIT सत्यापन छोड़ दिया गया है, CAS सत्यापन से भ्रमित नहीं होना चाहिए)। वैसे, "अनाम" होस्टिंग का उपयोग करने की क्षमता केवल .net 3.0 में दिखाई दी।

विधि शरीर

और अब हम सबसे दिलचस्प हिस्से पर आते हैं - हम कोड कैसे उत्पन्न करते हैं? हमारे उदाहरण में, कोड GenerateMapMethodBody पद्धति (dynMethod.GetILGenerator (), prm, मैपिंग) उत्पन्न करता है। इस पद्धति में, हम ILGenerator, पैरामीटर और मैपिंग को पास करते हैं - एक वर्ग से दूसरे वर्ग के क्षेत्रों का पत्राचार। ILGenerator वर्ग आपको जनरेट किए गए विधि के शरीर में CIL कमांड एम्बेड करने की अनुमति देता है। वह एमिट विधि से ऐसा करता है। ILGenerator आपको DefineLabel पद्धति (सशर्त संरचनाओं को व्यवस्थित करने के लिए) का उपयोग करके संक्रमण के लिए लेबल बनाने की अनुमति देता है, DefineLocal विधि का उपयोग करके स्थानीय चर घोषित करता है, और अपवादों के लिए ब्लॉक बनाता है। उत्तरार्द्ध के लिए, प्रपत्र BeginCatchBlock, BeginExceptFilterBlock, आदि के तरीकों का एक पूरा सेट उपयोग किया जाता है। CIL में अधिकांश कमांड कम्प्यूटेशनल स्टैक के साथ काम करते हैं (मूल्यांकन स्टैक, इसके बाद संक्षिप्तता के लिए यह केवल स्टैक है)। सीएलआर यह सुनिश्चित करता है कि आप स्टैक की सीमाओं से परे न जाएं, एक ही रास्ता या दूसरा। यदि स्टैक ओवरफ्लो होता है, तो आपको एक StackOverflowException मिलेगी, यदि आप किसी खाली स्टैक से मान लेने का प्रयास करते हैं या एक ऐसा मान जो वहां आपकी विधि द्वारा नहीं डाला गया था (अर्थात, विधि केवल "इसके स्टैक के भाग" को देखती है), तो आपको एक InvalidProgramException मिलेगी। आपकी पद्धति में दिए गए तर्क ढेर पर झूठ नहीं बोलते हैं; उन्हें उपयोग करने के लिए आपको OpCodes.Ldarg टीम का उपयोग करने की आवश्यकता है। इस प्रकार, विधि की शुरुआत में, स्टैक मानो खाली है। यह विधि के निष्पादन के बाद खाली होना चाहिए, अन्यथा InvalidProgramException फिर से होगा। और यह CIL कोड जनरेशन के मिनियाज़ में से एक है: उन त्रुटियों को जिन्हें आप एक उच्च-स्तरीय भाषा को संकलित करने के चरण में पकड़ सकते हैं, यहां आपको केवल रनटाइम पर प्राप्त होगा, उदाहरण के लिए, वेरिएबल्स के टाइपिंग या आरंभीकरण से संबंधित त्रुटियां।

IL कोड जनरेट करने के लिए एक सुविधाजनक तकनीक एक उच्च-स्तरीय भाषा में लिखना है, जो आप उत्पन्न करना चाहते हैं उसका एक उदाहरण है, इसे संकलित करें (संकलन से पहले रिलीज़ करने के लिए स्विच करना न भूलें, इष्टतम कोड से उदाहरण लेना) और देखें कि CIL में वांछित कोड के लिए टेम्पलेट कैसा दिखता है। रिफ्लेक्टर के साथ ऐसे टेम्प्लेट कोड को देखना सुविधाजनक है। इसके अलावा, वहाँ भी एक विशेष प्रतिबिंब EmitLanguage प्लगइन है। यह प्लगइन परावर्तक में देखे गए विधि या प्रकार के कोड को नहीं दिखाता है, लेकिन वह कोड जो देखे गए कोड को उत्पन्न करेगा। यदि हाथ में कोई परावर्तक नहीं है, तो आप .net SDK से IL Disassembler (ildasm.exe) का उपयोग करके टेम्पलेट देख सकते हैं। यह ईमानदार सीआईएल को दिखाएगा कि आपकी पद्धति किसमें शामिल है। अगला, हम आपकी आवश्यकताओं के लिए टेम्पलेट को अनुकूलित करते हैं, और आप कर रहे हैं। उसी विधि का उपयोग करके, आप यह पता लगा सकते हैं कि आपको किस विधि या इसके वर्ग में जोड़ने की आवश्यकता है, उदाहरण के लिए, एक मुहरबंद वर्ग या एक आंतरिक आभासी विधि बनाने के लिए।

मान लीजिए, कहीं से हमें कक्षाओं के बीच गुणों के पत्राचार का पता है, तो टेम्पलेट इस तरह दिखाई देगा:

  public static TestTarg GenerateTemplate(TestSrc src) { var result = new TestTarg(); result.SomeOtherID = (double)src.SomeID; return result; }

हम कोड संकलित करते हैं, इसे IL Disassembler में देखते हैं और देखते हैं:

 .method private hidebysig static class ConsoleApplication1.TestTarg GenerateTemplate(class ConsoleApplication1.TestSrc src) cil managed { // Code size 21 (0x15) -  ,   .maxstack 2 // -  CLR   //     .locals init ([0] class ConsoleApplication1.TestTarg result) //     (  +  ) //           IL_0000: newobj instance void ConsoleApplication1.TestTarg::.ctor() //        0 IL_0005: stloc.0 //        0 IL_0006: ldloc.0 //        0 IL_0007: ldarg.0 //  (  ),             .     . IL_0008: callvirt instance int32 ConsoleApplication1.TestSrc::get_SomeID() //  int  double IL_000d: conv.r8 //   ,            ( int) IL_000e: callvirt instance void ConsoleApplication1.TestTarg::set_SomeOtherID(float64) //    IL_0013: ldloc.0 //    IL_0014: ret } // end of method Program::GenerateTemplate

इस टेम्प्लेट कोड को देखने के बाद, हम प्रत्येक ऑपरेशन को कॉल के रूप में ILGenerator.Emit () में स्थानांतरित करते हैं, उदाहरण के लिए:

 //IL_0000: newobj instance void ConsoleApplication1.TestTarg::.ctor() //  var tTarg = typeof(TOut); var targetCtor = tTarg.GetConstructor(new Type[0]); gen.Emit(OpCodes.Newobj, targetCtor); ... //IL_0006: ldloc.0 gen.Emit(OpCodes.Ldloc, locResult); ... //IL_0008: callvirt instance int32 ConsoleApplication1.TestSrc::get_SomeID() var methodSrc = tSrc.GetProperty(methodMap.Key).GetGetMethod(); gen.Emit(OpCodes.Callvirt, methodSrc); ... //IL_0014: ret gen.Emit(OpCodes.Ret);

यदि आप रिफ्लेक्शन.इमिट प्लगइन के साथ रिफ्लेक्टर का उपयोग करते हैं, तो सब कुछ और भी आसान हो जाएगा, यह दिखाएगा कि आपको ILGenerator.Emit () की आवश्यकता है।

यहाँ हमारे टेम्पलेट के लिए प्लगइन है।

 public MethodBuilder BuildMethodGenerateTemplate(TypeBuilder type) { // Declaring method builder // Method attributes System.Reflection.MethodAttributes methodAttributes = System.Reflection.MethodAttributes.Private | System.Reflection.MethodAttributes.HideBySig | System.Reflection.MethodAttributes.Static; MethodBuilder method = type.DefineMethod("GenerateTemplate", methodAttributes); // Preparing Reflection instances MethodInfo method1 = typeof(TestSrc).GetMethod(/*  */); MethodInfo method2 = typeof(TestTarg).GetMethod(/**/); // Setting return type method.SetReturnType(typeof(TestTarg)); // Adding parameters method.SetParameters( typeof(TestSrc) ); // Parameter src ParameterBuilder src = method.DefineParameter(1, ParameterAttributes.None, "src"); ILGenerator gen = method.GetILGenerator(); // Preparing locals LocalBuilder result = gen.DeclareLocal(typeof(TestTarg)); // Writing body gen.Emit(OpCodes.Ldloca_S,0); gen.Emit(OpCodes.Initobj,TestTarg); gen.Emit(OpCodes.Ldloca_S,0); gen.Emit(OpCodes.Ldarg_0); gen.Emit(OpCodes.Callvirt,method1); gen.Emit(OpCodes.Conv_R8); gen.Emit(OpCodes.Call,method2); gen.Emit(OpCodes.Ldloc_0); gen.Emit(OpCodes.Ret); // finished return method; }

प्रत्येक ऑपरेशन के लिए सहायता msdn में देखी जा सकती है, OpCodes वर्ग में सभी ऑपरेशनों की परिभाषाएँ हैं। "माथे" नहीं, कुछ आदेशों को स्थानांतरित करना बेहतर है। उदाहरण के लिए, stloc.0 जैसी आज्ञाएँ, भ्रमित न होने के लिए, इस तरह न लिखना बेहतर है:

 gen.DeclareLocal(yourType); gen.Emit(OpCodes.Ldloc_0);

और इतना:

 var locResult = gen.DeclareLocal(yourType); gen.Emit(OpCodes.Ldloc, localVar);

आप विधियों के मापदंडों के साथ भी ऐसा कर सकते हैं।
ध्यान दें कि कुछ निर्माण जो कहते हैं, C # में समान हैं, CIL में भिन्न होंगे। उदाहरण के लिए:

 var c = new RefType(); // reference  var a = new RefType[0]; //  var s = new ValType(); // value  // reference  var targetCtor = typeof(RefType).GetConstructor(new Type[0]); gen.Emit(OpCodes.Newobj, targetCtor); //  gen.Emit(OpCodes.Newarr, typeof(RefType)); // value  LocalBuilder loc = gen.DeclareLocal(typeof(ValType)); gen.Emit(OpCodes.Ldloca, loc); gen.Emit(OpCodes.Initobj, typeof(ValType));

मैं रेफरी मापदंडों पर भी ध्यान आकर्षित करना चाहूंगा। क्योंकि रेफ मापदंडों के मामले में, पैरामीटर में एक मान नहीं होता है, लेकिन एक लिंक होता है, फिर सीआईएल स्तर पर इसके साथ अलग तरीके से काम करना आवश्यक है। यह एक तरह का अप्रत्यक्ष संबोधन है। यदि यह संदर्भ प्रकार का एक रेफरी पैरामीटर है, तो पैरामीटर में लिंक के लिए एक लिंक होगा, और सरल ldarg कमांड स्टैक पर ऑब्जेक्ट के लिंक को नहीं, बल्कि लिंक को लिंक करेगा (दो चीड़ के पेड़ों में खो जाने का एक शानदार मौका)। स्टैक पर ऑब्जेक्ट संदर्भ प्राप्त करने के लिए, आपको अतिरिक्त रूप से ldind.ref पर कॉल करना होगा।
यदि यह प्रकार मान का रेफ पैरामीटर है (लेकिन संरचना नहीं), तो पैरामीटर में मान का संदर्भ होगा। और स्टैक पर एक मूल्य डालने के लिए, आपको ldarg या starg कमांड का उपयोग करने की आवश्यकता नहीं है, लेकिन ldind या stind।
संरचनाओं के साथ एक समान स्थिति (बिल्कुल विपरीत)। यदि आपके पास संरचना प्रकार का एक पैरामीटर या चर है, तो इसे एक्सेस करने के लिए आपको पहले संरचना का पता स्टैक पर रखना होगा। इसके लिए ldarga कमांड है।

निष्कर्ष

पहेली: regexp और CIL जेनरेशन में क्या समानता है? उत्तर: बेहद मुश्किल रिवर्स इंजीनियरिंग। इसलिए, जनरेटिंग कोड पर टिप्पणी करने में आलस न करें ताकि यह स्पष्ट हो जाए कि आप क्या पैदा कर रहे हैं। ठीक है, या, कहिए, उत्पादन के तरीकों में, टिप्पणियाँ सामान्य से 80% अधिक होनी चाहिए। यदि आमतौर पर आप उन्हें बिल्कुल नहीं लिखते हैं, तो यह शुरू करने का समय है।

कई और सवाल हैं, जिन पर CIL जनरेशन के विषय पर चर्चा की जा सकती है, लेकिन मुझे लगता है कि इस लेख को पहले ही खींच लिया गया है। तो सभी को शुभकामनाएं, और जल्द ही आपको मिलते हैं।

उपयोगी लिंक:

उदाहरण कोड यहां पाया जा सकता है।
ReflectionEmitLanguage रिफ्लेक्टर प्लगइन
MSDN: प्रतिबिंब उत्सर्जन का उपयोग करना
MSDN: OpCodes CIL ऑपरेशन कोड्स
MSDN: पृष्ठांकित असेंबली के साथ कार्य करना

युपीडी:
टिप्पणियों में स्मार्ट लोगों का सुझाव है कि यह आपको सृजन के कठिन कार्य में भी मदद कर सकता है:

मैंने उनके साथ काम नहीं किया और मैं उनके बारे में कुछ नहीं कह सकता।

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

.Net पर उत्पन्न करें