मैं साझा असेंबली और परियोजनाओं के साथ कैसे काम करूं?

Question

प्रस्तावना के लिए, मैं कुछ महीनों के लिए सी # के साथ काम कर रहा हूं, लेकिन मैं तैनाती और असेंबली आदि जैसी अवधारणाओं से पूरी तरह से अपरिचित हूं। मेरे प्रश्न कई और विविध हैं, हालांकि मैं गुस्से में गुगल रहा हूं और उनके बारे में पढ़ रहा हूं कोई फायदा नहीं हुआ (मेरे पास वर्तमान में प्रो सी # 2008 और मेरे सामने .NET 3.5 प्लेटफ़ॉर्म है)।

हमारे पास यह प्रक्रिया है और यह तीन घटकों से बना है: प्रक्रिया के लिए एक इंजन, फ़िल्टर, और तर्क। हम इस प्रक्रिया को इतना प्यार करते हैं कि हम इसे अन्य परियोजनाओं में पुन: उपयोग करना चाहते हैं। तो अब मैं एक समाधान, एक परियोजना से परे अंतरिक्ष का पता लगाने शुरू कर रहा हूँ।

क्या यह ध्वनि सही है? एक बहुत बड़ा समाधान:

• प्रक्रिया ए, exe
• प्रक्रिया बी, exe
• प्रक्रिया सी, exe
• फ़िल्टर, dll
• इंजन, dll

इंजन साझा किया जाता है सभी प्रक्रियाओं के लिए कोड, तो मुझे लगता है कि एक साझा असेंबली हो सकती है? यदि एक साझा असेंबली एक ऐसे समाधान के समान समाधान में है जो इसे उपभोग करती है, तो यह जीएसी में होने पर कैसा लगता है? मैंने पोस्ट बिल्ड इवेंट के बारे में कुछ पढ़ा है। क्या इसका मतलब है कि इंजन निर्माण को प्रत्येक बिल्ड पर तैनात किया जाना है?

इसके अलावा, सिद्धांत के कारण हमने फ़िल्टर को अलग कर दिया है (केवल एक प्रक्रिया इसका उपयोग करती है) ताकि हम प्रक्रिया से स्वतंत्र रूप से फ़िल्टर को तैनात कर सकें ताकि प्रक्रिया निष्पादन योग्य को अद्यतन करने की आवश्यकता न हो। भले ही यह सबसे अच्छा अभ्यास है, चलो बस इसके साथ रोल करें। क्या यह संभव है? मैंने पढ़ा है कि असेंबली अन्य असेंबली के विशिष्ट संस्करणों से जुड़ी हैं, इसलिए यदि मैं केवल डीएलएल अपडेट करता हूं, तो इसे वास्तव में छेड़छाड़ माना जाता है। मैं EXE को बदले बिना डीएलएल कैसे अपडेट कर सकता हूं? क्या वह प्रकाशक नीति है?

वैसे, क्या Google में से कोई भी सक्षम या अमेज़ॅन सक्षम है? मुझे क्या खोजना चाहिए? मुझे सी # और .NET के बारे में बहुत सारी किताबें दिखाई देती हैं, लेकिन तैनाती या भवन या परीक्षण या भाषा से संबंधित चीजों के बारे में कोई भी नहीं।

Answer 1

मैं Aequitarum के विश्लेषण से सहमत: MSDN कि आप देख सकते हैं, यहाँ इस विषय से संबंधित प्रलेखन के बहुत सारे है। बस कुछ अतिरिक्त बिंदु:

इंजन प्रक्रियाओं के सभी के लिए कोड साझा किया जाता है, इसलिए मुझे लगता है कि एक साझा विधानसभा हो सकता है यह सोचते हैं रहा हूँ?

यह उचित लगता है।

एक साझा विधानसभा एक परियोजना है कि यह खपत है, अगर यह GAC में होना चाहिए था कैसे करता है यह भस्म हो के रूप में ही समाधान में है, तो?

जादू।

ठीक है, यह जादू नहीं है। मान लीजिए कि आपके समाधान आपकी प्रक्रिया प्रोजेक्ट इंजन प्रोजेक्ट का संदर्भ है। जब आप समाधान बनाते हैं, तो आप एक परियोजना असेंबली का उत्पादन करेंगे जिसमें इंजन असेंबली का संदर्भ है। विजुअल स्टूडियो फिर विभिन्न फ़ाइलों को सही निर्देशिका में कॉपी करता है। जब आप प्रक्रिया असेंबली निष्पादित करते हैं, तो रनटाइम लोडर इंजन असेंबली के लिए वर्तमान निर्देशिका को देखना जानता है। अगर इसे वहां नहीं मिल रहा है, तो यह वैश्विक असेंबली कैश में दिखता है। (यह पॉलिसी लोड करने का एक बेहद सरलीकृत दृश्य है; वास्तविक नीति उस से काफी जटिल है।)

जीएसी में सामग्री वास्तव में वैश्विक कोड होना चाहिए; कोड जो आप उचित रूप से असमान परियोजनाओं का उपयोग करने की अपेक्षा करते हैं।

क्या इसका मतलब है कि इंजन निर्माण को प्रत्येक बिल्ड पर तैनात किया जाना चाहिए?

मुझे यकीन नहीं है कि "पुनर्वित्त" से आपका क्या मतलब है। जैसे मैंने कहा, यदि आपके पास प्रोजेक्ट-टू-प्रोजेक्ट संदर्भ है, तो बिल्ड सिस्टम स्वचालित रूप से फ़ाइलों को सही स्थानों पर कॉपी कर देगा।

सिद्धांत कारण है कि हम इस प्रक्रिया से फिल्टर अलग (केवल एक प्रक्रिया का उपयोग करता है) है, ताकि हम इतना है कि प्रक्रिया निष्पादन अद्यतन करने की आवश्यकता नहीं है फिल्टर स्वतंत्र रूप से इस प्रक्रिया से तैनात कर सकते हैं

मैं सवाल करता हूं कि यह वास्तव में मूल्यवान है या नहीं। परिदृश्य एक: कोई फ़िल्टर असेंबली नहीं, सभी फ़िल्टर कोड project.exe में है। आप फ़िल्टर कोड को अपडेट करना चाहते हैं; आप project.exe अद्यतन करते हैं। परिदृश्य दो: filter.dll, project.exe। आप फ़िल्टर कोड को अपडेट करना चाहते हैं; आप filter.dll अद्यतन करते हैं। परिदृश्य की तुलना में परिदृश्य दो सस्ता या आसान कैसे है? दोनों स्थितियों में आप एक फ़ाइल अपडेट कर रहे हैं; यह क्यों मायने रखता है कि फ़ाइल का नाम क्या है?

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

मैंने पढ़ा है कि असेंबली अन्य असेंबली के विशिष्ट संस्करणों से लिंक हैं, इसलिए यदि मैं केवल डीएलएल अपडेट करता हूं, तो इसे वास्तव में छेड़छाड़ माना जाता है। मैं EXE को बदले बिना डीएलएल कैसे अपडेट कर सकता हूं? क्या वह प्रकाशक नीति है?

एक असेंबली को "मजबूत नाम" दिया जा सकता है। जब आप अपनी असेंबली Foo.DLL नाम देते हैं, और आप Bar.EXE लिखते हैं, "Bar.EXE Foo.DLL पर निर्भर करता है", तो रनटाइम Foo.DLL नामक कुछ भी लोड करेगा; फ़ाइल नाम मजबूत नहीं हैं। यदि एक बुरा हैकर क्लाइंट मशीन पर Foo.DLL का अपना संस्करण प्राप्त करता है, तो लोडर इसे लोड करेगा। एक मजबूत नाम बार.एक्सईई कहता है कि "बार निगम द्वारा लिखित बार.एक्सई संस्करण 1.2 फू निगम द्वारा लिखित Foo.DLL संस्करण 1.4 पर निर्भर करता है", और सभी सत्यापन फ़ू कॉर्प और बार कॉर्प से जुड़े क्रिप्टोग्राफ़िक रूप से मजबूत कुंजी के विरुद्ध किए जाते हैं।

तो हां, एक असेंबली को केवल एक विशिष्ट कंपनी के विशिष्ट संस्करण के खिलाफ बाध्य करने के लिए बाध्य करने के लिए कॉन्फ़िगर किया जा सकता है। एक नए संस्करण का उपयोग करने के लिए असेंबली को अपडेट करने के लिए आप क्या कर सकते हैं एक छोटी एक्सएमएल फाइल बनाते हैं जो लोडर को बताती है "आप जानते हैं कि मैंने कैसे कहा था कि मैं फू.डीएलएल v1.4 चाहता था? अच्छा, वास्तव में यदि 1.5 उपलब्ध है, तो इसका उपयोग करना ठीक है वह भी।"

मुझे क्या देखना चाहिए? मुझे सी # और .NET के बारे में बहुत सारी किताबें दिखाई देती हैं, लेकिन तैनाती या भवन या परीक्षण या भाषा से संबंधित चीजों के बारे में कोई भी नहीं।

पुस्तकों में तैनाती को अक्सर उपेक्षित किया जाता है, मैं सहमत हूं।

यदि आप प्रबंधित विंडोज अनुप्रयोगों की तैनाती में रूचि रखते हैं तो मैं "क्लिकऑन" की खोज करके शुरू करूंगा।

Answer 2

परियोजनाएं असेंबली या परियोजनाओं का संदर्भ दे सकती हैं।

जब आप किसी अन्य असेंबली/प्रोजेक्ट का संदर्भ देते हैं, तो आपको संदर्भित असेंबली में सभी सार्वजनिक कक्षाओं/enums/structs आदि का उपयोग करने की अनुमति है।

आपको उन सभी को एक समाधान में रखने की आवश्यकता नहीं है। आपके पास तीन समाधान हो सकते हैं, प्रत्येक प्रक्रिया के लिए एक, और सभी तीन समाधान इंजन और फ़िल्टर लोड कर सकते हैं।

इसके अलावा, आप प्रोसेस बी और प्रोसेस सी इंजन और फ़िल्टर के संकलित असेंबली (.dll) का संदर्भ ले सकते हैं और इसी तरह के प्रभाव पड़ सकते हैं।

जब तक आप एक विशिष्ट संस्करण की आवश्यकता के लिए किसी असेंबली के संदर्भ में संपत्ति सेट नहीं करते हैं, तो आप डीएलएल को केवल चिंता के बिना अद्यतन कर सकते हैं, केवल डीएलएल में कोड परिवर्तन ही प्रदान करते हैं।

इसके अलावा, सिद्धांत कारण है कि हम प्रक्रिया (केवल एक प्रक्रिया का उपयोग करता है) से फिल्टर अलग है ताकि हम फिल्टर स्वतंत्र रूप से प्रक्रिया से इतना है कि प्रक्रिया निष्पादन योग्य नहीं है तैनात कर सकते हैं अद्यतन करने की आवश्यकता है। चाहे यह सबसे अच्छा अभ्यास है, चलो बस इसके साथ रोल करें। क्या यह संभव है?

मैं वास्तव में अद्यतन करने की इस विधि को प्राथमिकता देता हूं। कम ओवरहेड केवल उन फ़ाइलों को अपडेट करने के लिए जो हर बार सब कुछ के बजाय बदल जाते हैं।

जीएसी का उपयोग करने के लिए, जटिलता के अन्य स्तर के स्तर में मैं प्रवेश नहीं करूंगा।

आपकी असेंबली को छेड़छाड़ करके उन पर हस्ताक्षर करके किया जा सकता है, जिसे पहले स्थान पर जीएसी का उपयोग करने की आवश्यकता होती है, लेकिन आपको अभी भी ठीक होना चाहिए क्योंकि एक विशिष्ट संस्करण की आवश्यकता नहीं है।

मेरी सिफारिश .NET ढांचे के बारे में एक पुस्तक को पढ़ना है। इससे आपको सीएलआर और आप क्या कर रहे हैं समझने में मदद मिलेगी।

Applied Microsoft .NET Framework Programming एक पुस्तक थी जिसे मैंने वास्तव में पढ़ने का आनंद लिया।

Answer 3

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

यदि आप विशिष्ट संस्करण की देखभाल किए बिना डीएलएल की गतिशील रूप से लोडिंग और अपने प्रोसेसर से सदस्य विधियों को कॉल करना चाहते हैं, तो आप कुछ मार्गों पर जा सकते हैं। सबसे आसान तरीका यह है कि जब आप संदर्भ जोड़ते हैं तो Specific Version प्रॉपर्टी को False पर सेट करना है। यह आपको बाद में डीएलएल को बदलने की स्वतंत्रता देगा, और जब तक आप विधि हस्ताक्षर के साथ गड़बड़ नहीं करते हैं, यह कोई समस्या नहीं होनी चाहिए। दूसरा विकल्प MEF है (जो प्रतिबिंब का उपयोग करता है और .NET 4.0 में ढांचे का हिस्सा होगा)। एमईएफ के साथ विचार यह है कि आप डीएलएल के लिए "प्लगइन्स" स्टाइल फ़ोल्डर स्कैन कर सकते हैं जो विशिष्ट कार्यक्षमता को लागू करता है और फिर उन्हें गतिशील रूप से कॉल करता है। यह आपको कुछ अतिरिक्त लचीलापन देता है जिसमें आप अपने संदर्भों को संशोधित करने की आवश्यकता के बिना बाद में नई असेंबली जोड़ सकते हैं।

ध्यान देने योग्य एक और बात यह है कि विजुअल स्टूडियो में निर्मित सेटअप और परिनियोजन प्रोजेक्ट टेम्पलेट्स हैं जिनका उपयोग आप अपनी परियोजनाओं को तैनात करने के लिए एमएसआई पैकेज जेनरेट करने के लिए कर सकते हैं।

http://msdn.microsoft.com/en-us/library/ybshs20f%28VS.80%29.aspx

Answer 4

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

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

जब आपके पास डीएलएल पर निर्भरता के साथ कई स्थापित ऐप्स हैं तो बग फिक्स अपडेट को तैनात करना अजीब हो सकता है। चूंकि आपको प्रत्येक ऐप के लिए बार-बार डीएलएल में प्रतिलिपि बनाना पड़ता है। और जब आप कुछ ऐप्स अपडेट करते हैं लेकिन दूसरों को नहीं तो आप परेशानी में पड़ सकते हैं। खासकर जब डीएलएल इंटरफ़ेस में ब्रेकिंग परिवर्तन होता है जिसके लिए ऐप को फिर से सम्मिलित करने की आवश्यकता होती है। वह डीएलएल नरक दस्तक दे रहा है, जीएसी इसे हल कर सकता है।

Answer 5

हमें एमएसडीएन में इस मुद्दे पर some guidance मिला। हमने बिना किसी साझा कोड के दो अलग-अलग समाधान के साथ शुरुआत की, और फिर साझा साझा असेंबली को समानताएं व्यक्त कीं। हमने केवल उन परियोजनाओं को प्रभावित करने के लिए साझा कोड में बदलावों को अलग करने के तरीकों से संघर्ष किया जो इसके लिए तैयार थे। हम Open/Close पर भयानक थे।

हमने कोशिश की

• प्रत्येक परियोजना है कि यह प्रयोग किया जाता है के लिए साझा कोड शाखाओं और समाधान
• में शामिल साझा समाधान से साझा विधानसभा को कॉपी जब हम कोडिंग पूर्व निर्माण परिवर्तन किए
• साझा कोड समाधान बनाने के लिए घटनाएं और असेंबली

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

जहां तक ​​तैनाती है, हमारी बिल्ड स्क्रिप्ट कोड बनाने के लिए सेट की गई हैं और हमारे वातावरण में असेंबली समेत केवल उन्हीं फ़ाइलों को कॉपी करती हैं।

Answer 6

डिफ़ॉल्ट रूप से, आपके पास अपनी प्रोजेक्ट (1.0.0.0) में हार्डकोडेड संस्करण संख्या है। जब तक आप इसे नहीं बदलते, आप प्रक्रिया असेंबली के साथ सभी फ़िल्टर बिल्ड का उपयोग कर सकते हैं (यह केवल जानता है कि इसे 1 का उपयोग करना चाहिए।0.0.0 संस्करण)। हालांकि, यह सबसे अच्छा समाधान नहीं है, क्योंकि आप विभिन्न बिल्डों के बीच कैसे अंतर करते हैं?

एक और विकल्प उसी प्रक्रिया द्वारा फ़िल्टर के विभिन्न संस्करणों का उपयोग करता है। आपको प्रक्रिया प्रोजेक्ट में एक app.config फ़ाइल जोड़नी चाहिए, और एक बाध्यकारी रेडियोधर्मी तत्व शामिल करें (दस्तावेज़ देखें)। जब भी रनटाइम फ़िल्टर के किसी विशेष संस्करण की तलाश करता है, तो यह कॉन्फ़िगरेशन में संकेतित संस्करण पर "पुनर्निर्देशित" होता है। दुर्भाग्यवश, इसका मतलब है कि यद्यपि आपको प्रक्रिया असेंबली को अपडेट करने की आवश्यकता नहीं है, आपको कॉन्फ़िगरेशन फ़ाइल को नए संस्करण के साथ अपडेट करना होगा।

जब भी आपको संस्करण की समस्याएं आती हैं, तो आप इन समस्याओं का निवारण करने के लिए Fuslogvw.exe (फ़्यूज़न लॉग व्यूअर) का उपयोग कर सकते हैं।

मज़े करो!

Ulu