एक वेबसाइट और एक वेब एप्लिकेशन को संकलित करने के बीच अंतर

ASP.NET मॉड्यूल की कई किस्में हैं जो विभिन्न प्लेटफार्मों जैसे कि वेब फॉर्म, वेब पेज, मॉडल-व्यू-कंट्रोलर (एमवीसी) और नवीनतम - कोर पर आधारित हैं। इस लेख में, मैं एक ASP.NET वेबसाइट और एक ASP.NET वेब एप्लिकेशन को संकलित करने के बीच कई अंतरों को देखना चाहता हूं।



एक वेबसाइट का संकलन (चित्र 1) और एक वेब अनुप्रयोग (छवि 2)।



अंजीर। 1: ASP.NET वेबसाइट और ASP.NET वेबसाइट और ASP.NET वेब अनुप्रयोग के बीच अंतर



अंजीर। 2: ASP.NET वेब अनुप्रयोग और ASP.NET वेबसाइट और ASP.NET वेब अनुप्रयोग के बीच अंतर

यह आलेख ASP.NET प्रोजेक्ट्स की आंतरिक संरचना के बारे में नहीं है, बल्कि एज़्योर ऐप सर्विस प्लेटफ़ॉर्म पर काम करने के दौरान प्राप्त हुए अनुभव के बारे में है। आंतरिक उपकरण पहले से ही यहाँ प्रलेखित है - "आपकी वेबसाइट (C #) को रोकना" ("C में एक वेबसाइट को पहले से तैयार करना")। आपको स्वचालित और स्पष्ट संकलन के बीच अंतर समझना चाहिए। इसके अलावा, यदि आप ASP.NET वेबसाइट के साथ काम कर रहे हैं, तो गंभीरता से aspnet_compiler.exe के साथ precompiling पर विचार करें, जैसा कि कैसे में वर्णित है: Precompile ASP.NET वेबसाइट ASP.NET ")।

यहां कई प्रकाशन हैं जो इस मुद्दे पर आपके क्षितिज को व्यापक बनाने और अन्य विषयों का पता लगाने में आपकी मदद करेंगे:

• "मेरा ASP.NET अनुप्रयोग पुनर्चक्रण क्यों है, पुनः आरंभ हो रहा है" ("ASP.NET अनुप्रयोग पुन: संकलित, पुनः लोड क्यों किया गया है")
• "का उपयोग करना चाहिए, पता होना चाहिए WinDbg कमांड, मेरे सबसे अधिक इस्तेमाल किया" ("WinDbg कमांड्स जो मुझे जानने और लागू करने की आवश्यकता है और जो मैं सबसे अधिक बार उपयोग करता हूं")
• लैब 28: डिबग का प्रभाव = सत्य ("पाठ 28: डीबग का प्रभाव = सत्य")
• "डिबग = सच"
• मेरे सभी ASP.NET लेख

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

public partial class _default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { LabelFileLocation.Text = $"{System.Web.HttpRuntime.CodegenDir}"; rptResults1.DataSource = System.IO.Directory.GetFiles(System.Web.HttpRuntime.CodegenDir, "*.dll"); rptResults1.DataBind(); } }      () <asp:Repeater ID="rptResults1" runat="server"> <HeaderTemplate><table></HeaderTemplate> <ItemTemplate> <tr> <td><%# Container.DataItem %></td> </tr> </ItemTemplate> <FooterTemplate></table></FooterTemplate> </asp:Repeater> 

फिर मैंने इस कोड को ऐप सर्विस प्लेटफॉर्म पर प्रकाशित किया।

जब मैंने पहली बार वेबसाइट एक्सेस की, तो मुझे अंजीर में दिखाया गया परिणाम मिला। 3 (मूल रूप से मेरी ASP.NET वेबसाइट के मूल में तीन पृष्ठ थे)



अंजीर। 3: एज़्योर ऐप सर्विस प्लेटफॉर्म पर ASP.NET वेबसाइट का संकलन

मैंने वेबसाइट और बायनेरिज़ को एक नई असेंबली (चित्र 4) में संकलित किया। यह काफी अप्रत्याशित था, क्योंकि मैंने केवल रिबूट किया और कोई तैनाती या बदलाव नहीं किया।



अंजीर। 4: एज़्योर ऐप सर्विस प्लेटफ़ॉर्म पर ASP.NET वेबसाइट को संकलित करना

मैंने KUDU विधानसभा निर्देशिका में खोज की और इसे नहीं पाया; यह बहुत अजीब था।

"दूसरे पृष्ठ" और "और दूसरे पृष्ठ" लिंक पर क्लिक करने के बाद, मेरे सभी पृष्ठ एक विधानसभा में संकलित किए गए थे, और मुझे यह देखकर बहुत आश्चर्य हुआ, क्योंकि मेरे web.config फ़ाइल में debug = true सेट था।

मुझे निम्नलिखित प्रश्नों के उत्तर जानने की आवश्यकता है:

1. रिबूट के बाद मेरा आवेदन क्यों नहीं बदला, हालांकि मैंने कोई तैनाती या कॉन्फ़िगरेशन परिवर्तन नहीं किया था?
2. मेरे स्रोत कोड सही होते हुए भी मुझे KUDU में विधानसभा क्यों नहीं मिली?
3. मेरे आवेदन को एक ही विधानसभा में क्यों संकलित किया गया था, हालांकि debug = true को web.config फ़ाइल में सेट किया गया था?

पहले प्रश्न का उत्तर यह था कि मैं वास्तव में KUDU असेंबली को देख रहा था, न कि वह जो ऐप सेवा के लिए संकलित थी। लेख 2 में एक नज़र डालें "अपने धीमे प्रदर्शन वाले वेब ऐप के लिए मेमोरी डंप बनाएँ"। इससे पता चलता है कि KUDU ऐप सेवा की तुलना में एक अलग प्रक्रिया में चल रहा है। इसलिए, KUDU ने उदाहरण बनाते समय खुद को फिर से जोड़ दिया, और यह ऐप सेवा का मेरा उदाहरण नहीं था।

मैंने पहले प्रश्न पर प्राप्त जानकारी के आधार पर दूसरे प्रश्न को भी हल किया। मैं ऐप सेवा प्लेटफ़ॉर्म पर फ़ाइलों के कॉन्फ़िगरेशन के बारे में सभी विवरणों को छोड़ देता हूं और कहता हूं कि मैं इस प्लेटफॉर्म पर अपनी ASP.NET वेबसाइट असेंबली प्रदर्शित करने में सक्षम था: इसके लिए मैंने WEBSITE_DISABLE_SCM_SEPARATION को सही पर सेट किया (चित्र 5 देखें)। यह केवल परीक्षण और (या) डिबगिंग के लिए और अधिक कुछ नहीं के लिए करें। मैं किसी वेबसाइट के कई पृष्ठों को ऐप सेवा में किसी एकल प्रक्रिया में मैप करने की अनुशंसा नहीं करता। डीबगिंग पूर्ण होने के बाद, इस मान को रीसेट करें और प्रक्रियाओं को फिर से अलग करें।



अंजीर। 5: एज़्योर ऐप सेवा में ASP.NET वेबसाइट का संकलन; मुझे KUDU पर अस्थायी ASP.NET फाइलें नहीं मिल रही हैं

तीसरे प्रश्न का उत्तर था कि यदि Web.Debug.config फ़ाइल मौजूद है, तो डिबग = सही विशेषता परिनियोजन प्रक्रिया के दौरान हटा दी जाती है।

 <compilation xdt:Transform="RemoveAttributes(debug)" /> 

मैंने XDT फ़ाइलों के बारे में यहाँ , यहाँ और यहाँ लिखा है , लेकिन इस मामले में मुझे उनके अर्थ को समझने (याद करने, महसूस करने) के लिए थोड़ा सोचना पड़ा।

WEBSITE_DISABLE_SCM_SEPARATION को सही पर सेट करने के बाद, मैंने एक स्टॉप और स्टार्ट किया, दूसरे शब्दों में, एक ठंडी शुरुआत ... और मैंने देखा कि SCM / KUDU और मेरी वेबसाइट दोनों वास्तव में एक ही प्रक्रिया में शुरू हुई थीं (छवि 6.)।



अंजीर। 6: एज़्योर ऐप सेवा में ASP.NET वेबसाइट को संकलित करना; मुझे KUDU पर अस्थायी ASP.NET फाइलें नहीं मिल रही हैं

Default.aspx का प्रकाशन और संकलन शुरू किया गया है, सभी अनुरोधों के बाद असेंबली का नाम अपरिवर्तित रहता है (चित्र 7)।



अंजीर। 7: एज़्योर ऐप सर्विस प्लेटफॉर्म पर ASP.NET वेबसाइट का संकलन

इसे सत्यापित करने के लिए, मैंने प्रक्रिया मेमोरी का एक डंप लिया, मॉड्यूल का एक डंप लिया और इसका विश्लेषण किया। ईमानदारी से, मैं अभी भी विधानसभा द्वारा प्रदर्शित परिणाम से हैरान था, क्योंकि मैंने सभी परीक्षणों के पूरा होने के बाद ही डिबग = सच्चे पैरामीटर का पता लगाया था। कभी-कभी मैं गलत क्रम में लेख लिखता हूं जिसमें घटनाओं का पालन होता है। उलझन में, मैंने बैच संकलन का परीक्षण करने का फैसला किया; इसके बारे में यहाँ पढ़ें: "संकलन तत्व (ASP.NET सेटिंग्स स्कीमा)" ("संकलन तत्व - ASP.NET वेब पैरामीटर आरेख")। मुझे उम्मीद थी कि प्रति पृष्ठ एक विधानसभा संकलित की जाएगी, इसलिए परिणाम (चित्र 8 देखें) एक पूर्ण आश्चर्य था।



अंजीर। 8: एज़्योर ऐप सर्विस प्लेटफ़ॉर्म पर ASP.NET वेबसाइट का संकलन

मुझे प्रति पृष्ठ एक असेंबली देखने की उम्मीद थी, क्योंकि मुझे लगा कि मैं डिबग = सच्चे पैरामीटर के साथ काम कर रहा हूं। बैच संकलन के बारे में पढ़ना, मैंने महसूस किया कि यह एक विशिष्ट निर्देशिका में सम्‍मिलित सभी पृष्ठों को संकलित करता है। इसलिए मैंने दो डायरेक्टरी बनाई और उनमें से प्रत्येक में .aspx फाइलें डालीं। पीआईडी ​​में बदलाव नहीं हुआ, इसलिए "कोल्ड स्टार्ट" (चित्र 9) नहीं था।



अंजीर। 9: एज़्योर ऐप सर्विस प्लेटफॉर्म पर ASP.NET वेबसाइट का संकलन

हालाँकि, साइट को वास्तव में किसी अन्य बाइनरी फ़ाइल में बदला गया था, लेकिन उसी निर्देशिका (पथ) (चित्र 10) में बनी रही।



अंजीर। 10: एज़्योर ऐप सर्विस प्लेटफ़ॉर्म पर ASP.NET वेबसाइट को संकलित करना

मैंने अपने निष्कर्षों की शुद्धता को पूरी तरह से सत्यापित करने के लिए मेमोरी को डंप कर दिया। और, जैसे ही मैं साइट की जड़ की ओर मुड़ा और देखा कि निर्देशिका के सभी पृष्ठ संकलित थे, मुझे एहसास हुआ कि बैच संकलन के बारे में मेरी परिकल्पना की पुष्टि की गई थी (चित्र 11)।



अंजीर। 11: एज़्योर ऐप सर्विस प्लेटफ़ॉर्म पर ASP.NET वेबसाइट का संकलन

मैंने लिंक "डायरेक्ट्री 1" का पालन किया और एक और असेंबली (छवि 12) देखी।



अंजीर। 12: एज़्योर ऐप सर्विस प्लेटफ़ॉर्म पर ASP.NET वेबसाइट का संकलन

मैंने मेमोरी को फिर से डंप किया, मॉड्यूल डंप को हटा दिया और देखा कि यह वास्तव में "डायरेक्टरी 1" पेज (छवि 13) से मेल खाती है।



अंजीर। 13: एज़्योर ऐप सर्विस प्लेटफ़ॉर्म पर ASP.NET वेबसाइट का संकलन

मैंने डायरेक्टरी 2 पेज (चित्र 14 और 15) के लिए भी यही किया है।



अंजीर। 14: एज़्योर ऐप सर्विस प्लेटफॉर्म पर ASP.NET वेबसाइट का संकलन



अंजीर। 15: एज़्योर ऐप सर्विस प्लेटफ़ॉर्म पर ASP.NET वेबसाइट का संकलन

मुझे एससीएम / केयूडीयू (छवि 16) में खुद विधानसभाओं में जाने का अवसर मिला।



अंजीर। 16: एज़्योर ऐप सर्विस प्लेटफॉर्म पर ASP.NET वेबसाइट का संकलन

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

उपयोगी संसाधन

क्लाउड एप्लिकेशन आर्किटेक्चर गाइड

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

• अपने आवेदन या समाधान के लिए सही क्लाउड एप्लिकेशन आर्किटेक्चर शैली चुनना;
• उचित कंप्यूटिंग और डेटा भंडारण प्रौद्योगिकियों का चयन;
• एक स्केलेबल, लचीला, और प्रबंधनीय अनुप्रयोग बनाने के लिए 10 विकास सिद्धांतों को लागू करना;
• गुणवत्ता सॉफ़्टवेयर बनाने के पांच सिद्धांतों का पालन करना जो आपके क्लाउड एप्लिकेशन की सफलता की गारंटी देता है;
• समस्या को हल करने के लिए डिज़ाइन किए गए डिज़ाइन पैटर्न का उपयोग करना।

→ डाउनलोड करें

Azure डेवलपर की मार्गदर्शिका

Azure Developer's मार्गदर्शिका के इस अद्यतन में, आप देखेंगे कि Azure सॉफ़्टवेयर प्लेटफ़ॉर्म के लिए सेवाओं का पूरा सेट आपकी आवश्यकताओं को कैसे पूरा करता है। यहां आपको आर्किटेक्चर दृष्टिकोण और क्लाउड एप्लिकेशन बनाते समय उत्पन्न होने वाली सबसे सामान्य स्थितियों के बारे में जानकारी मिलेगी।


→ डाउनलोड करें

Microsoft Azure मूल बातें

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

इस पुस्तक में निम्नलिखित विषय शामिल हैं:

• Azure से शुरुआत करना;
• Azure अनुप्रयोग सेवा और वेब अनुप्रयोग;
• आभासी मशीनें;
• भंडारण सेवा;
• डेटाबेस;
• अतिरिक्त Azure सेवाएँ।

→ डाउनलोड करें

उपयोगी लिंक

• ASP.NET प्रलेखन
• ASP.NET कोर ट्यूटोरियल