वेब साइट वह है जो आप ASP.NET वेब सर्वर जैसे IIS में तैनात करते हैं। बस फाइलों और फ़ोल्डरों का एक गुच्छा। एक वेब साइट में कुछ भी नहीं है जो आपको विज़ुअल स्टूडियो से जोड़ता है (कोई प्रोजेक्ट फ़ाइल नहीं है)। वेब पेजों के कोड-जेनरेशन और संकलन (जैसे .aspx, .ascx, .master) को रनटाइम के दौरान गतिशील रूप से किया जाता है , और इन फ़ाइलों में परिवर्तन की रूपरेखा द्वारा पता लगाया जाता है और स्वचालित रूप से पुन: संकलित किया जाता है। आप उस कोड को डाल सकते हैं जिसे आप विशेष App_Code फ़ोल्डर में पृष्ठों के बीच साझा करना चाहते हैं , या आप इसे पूर्व-संकलन कर सकते हैं और असेंबली को बिन फ़ोल्डर में डाल सकते हैं।
वेब एप्लिकेशन एक विशेष विजुअल स्टूडियो प्रोजेक्ट है। वेब साइट्स के साथ मुख्य अंतर यह है कि जब आप प्रोजेक्ट बनाते हैं तो सभी कोड फाइलें एक ही असेंबली में संकलित की जाती हैं, जिसे बिन डायरेक्टरी में रखा जाता है। आप वेब सर्वर पर कोड फ़ाइलों को तैनात नहीं करते हैं। साझा कोड फ़ाइलों के लिए एक विशेष फ़ोल्डर रखने के बजाय आप उन्हें कहीं भी रख सकते हैं, ठीक वैसे ही जैसे आप क्लास लाइब्रेरी में करते हैं। क्योंकि वेब एप्लिकेशन में ऐसी फाइलें होती हैं, जो तैनात नहीं होती हैं, जैसे प्रोजेक्ट और कोड फाइलें, वेब साइट को एक निर्दिष्ट स्थान पर आउटपुट करने के लिए विजुअल स्टूडियो में पब्लिश कमांड होती है।
App_Code बनाम बिन
साझा कोड फ़ाइलों को नियोजित करना आमतौर पर एक बुरा विचार है, लेकिन इसका मतलब यह नहीं है कि आपको वेब एप्लिकेशन चुनना होगा। आपके पास एक वेब साइट हो सकती है जो एक क्लास लाइब्रेरी प्रोजेक्ट को संदर्भित करती है जो वेब साइट के लिए सभी कोड रखती है। वेब एप्लिकेशन इसे करने का एक सुविधाजनक तरीका है।
कोड के पीछे
यह विषय .aspx और .ascx फ़ाइलों के लिए विशिष्ट है। यह विषय ASP.NET MVC और ASP.NET वेब पेज जैसे नए एप्लिकेशन फ्रेमवर्क में प्रासंगिक रूप से प्रासंगिक है जो कोडबाइंड फ़ाइलों का उपयोग नहीं करते हैं।
वेब अनुप्रयोगों में .aspx पृष्ठों और .ascx नियंत्रणों की कोडबीहाइंड फ़ाइलों सहित एक ही असेंबली में संकलित सभी कोड फ़ाइलों के होने से , आपको हर छोटे बदलाव के लिए फिर से निर्माण करना होगा, और आप लाइव परिवर्तन नहीं कर सकते। यह विकास के दौरान एक वास्तविक दर्द हो सकता है, क्योंकि आपको परिवर्तनों को देखने के लिए फिर से निर्माण करना पड़ता है, जबकि वेब साइट्स के साथ रनटाइम द्वारा परिवर्तन का पता लगाया जाता है और पृष्ठों / नियंत्रणों को स्वचालित रूप से पुनर्नवीनीकरण किया जाता है।
रनटाइम का प्रबंधन करने के बाद कोडबीहिंड असेंबली आपके लिए कम काम करती है, क्योंकि आपको अलग-अलग नामस्थानों में पृष्ठों / नियंत्रणों को अद्वितीय नाम देने या उन्हें व्यवस्थित करने के बारे में चिंता करने की आवश्यकता नहीं है।
मैं यह नहीं कह रहा हूं कि कोड फ़ाइलों को तैनात करना हमेशा एक अच्छा विचार है (विशेष रूप से साझा कोड फ़ाइलों के मामले में नहीं), लेकिन कोडबेहाइंड फ़ाइलों में केवल यूआई विशिष्ट कार्य करने वाले कोड, वायर-अप ईवेंट हैंडलर आदि शामिल होने चाहिए, आपका आवेदन होना चाहिए। स्तरित ताकि बिन फ़ोल्डर में महत्वपूर्ण कोड हमेशा समाप्त हो। अगर ऐसा है, तो कोडबाइंड फ़ाइलों को तैनात करना हानिकारक नहीं माना जाना चाहिए।
वेब एप्लिकेशन की एक और सीमा यह है कि आप केवल प्रोजेक्ट की भाषा का उपयोग कर सकते हैं। वेब साइट्स में आपको C # में कुछ पेज, VB में कुछ आदि हो सकते हैं, विशेष Visual Studio समर्थन की कोई आवश्यकता नहीं है। यह बिल्ड प्रदाता की सुंदरता का विस्तार है।
इसके अलावा, वेब एप्लिकेशन में आपको पृष्ठों / नियंत्रणों में त्रुटि का पता नहीं चलता है क्योंकि संकलक आपके कोडबिहिन वर्गों को संकलित करता है न कि मार्कअप कोड (एमवीसी में आप इसे MvcBuildViews विकल्प का उपयोग करके ठीक कर सकते हैं), जिसे रनटाइम पर संकलित किया गया है।
दृश्य स्टूडियो
क्योंकि वेब एप्लिकेशन विजुअल स्टूडियो प्रोजेक्ट हैं, इसलिए आपको कुछ ऐसी सुविधाएं मिलती हैं जो वेब साइट्स में उपलब्ध नहीं हैं। उदाहरण के लिए, आप विभिन्न प्रकार के कार्यों को करने के लिए बिल्ड इवेंट्स का उपयोग कर सकते हैं, उदाहरण के लिए जावास्क्रिप्ट फ़ाइलों को छोटा और / या संयोजित करें।
विज़ुअल स्टूडियो 2010 में पेश की गई एक और अच्छी सुविधा वेब.कॉन्फिग ट्रांसफॉर्मेशन है ।यह वेब साइट्स में भी उपलब्ध नहीं है। अब वीएस 2013 में वेब साइटों के साथ काम करता है।
एक वेब अनुप्रयोग का निर्माण एक वेब साइट के निर्माण की तुलना में तेज है, विशेष रूप से बड़ी साइटों के लिए। यह मुख्य रूप से है क्योंकि वेब अनुप्रयोग मार्कअप कोड संकलित नहीं करते हैं। MVC में यदि आप MvcBuildViews को true पर सेट करते हैं तो यह मार्कअप कोड को संकलित करता है और आपको एरर डिटेक्शन मिलता है, जो बहुत उपयोगी है। नीचे की ओर यह है कि हर बार जब आप समाधान का निर्माण करते हैं तो यह पूरी साइट बनाता है, जो धीमा और अक्षम हो सकता है, खासकर यदि आप साइट को संपादित नहीं कर रहे हैं। मैं खुद को MvcBuildViews को चालू और बंद करता हुआ पाता हूं (जिसके लिए प्रोजेक्ट अनलोड करना पड़ता है)। दूसरी ओर, वेब साइट्स के साथ आप चुन सकते हैं कि आप साइट को समाधान के हिस्से के रूप में बनाना चाहते हैं या नहीं। यदि आप नहीं चुनते हैं, तो समाधान का निर्माण बहुत तेज है, और आप वेब साइट नोड पर हमेशा क्लिक कर सकते हैं और बिल्ड का चयन कर सकते हैं, यदि आपने बदलाव किए हैं।
MVC वेब एप्लिकेशन प्रोजेक्ट में आपके पास सामान्य कार्यों के लिए अतिरिक्त कमांड और संवाद होते हैं, जैसे 'Add View', 'Go To View', 'Add Controller', आदि। ये MVC वेब साइट में उपलब्ध नहीं हैं।
यदि आप IIS एक्सप्रेस को विकास सर्वर के रूप में उपयोग करते हैं, तो वेब साइट्स में आप वर्चुअल निर्देशिकाओं को जोड़ सकते हैं। यह विकल्प वेब एप्लिकेशन में उपलब्ध नहीं है।
NuGet पैकेज पुनर्स्थापना वेब साइटों पर काम नहीं करता है, आपको पैकेजों पर सूचीबद्ध संकुल को मैन्युअल रूप से स्थापित करना होगापैकेज रिस्टोर अब NuGet 2.7 शुरू करने वाले वेब साइट्स के साथ काम करता है
