ओपन-सोर्स प्रोजेक्ट के लिए मजबूत-नाम कुंजी जोड़ी को प्रबंधित करने का अनुशंसित तरीका क्या है?

Question

मैं एक ओपन-सोर्स प्रोजेक्ट का प्रबंधन करता हूं और प्रोजेक्ट के बाइनरी पैकेज में जारी की गई बाइनरी पर हस्ताक्षर करना चाहता हूं। मैं अपने प्रोजेक्ट को प्रबंधित और निर्माण करने के लिए विजुअल स्टूडियो csproj और sln फ़ाइलों का उपयोग करता हूं, और इन फ़ाइलों को प्रोजेक्ट के स्रोत संकुल के हिस्से के रूप में वितरित करता हूं।

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

संपादित:

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

Answer 1

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

यह मेरे आवेदन में मामला है इसलिए मुझे एक अलग दृष्टिकोण अपनाने की आवश्यकता है।

मैंने मूल रूप से एक अलग फ़ोल्डर विरासत में sln और csproj फ़ाइलों की एक प्रति बनाई और csproj फ़ाइलों को निम्नानुसार संशोधित किया।

• मूल स्रोतों को इंगित करते हुए लिंक के सभी फ़ाइल संदर्भों को बदल दिया।
• एक मजबूत नाम के साथ InternalsVisibleToAttribute के उपयोग को रखने के लिए प्रत्येक AssemblyInfo.cs फ़ाइल की प्रतिलिपि बनाई और संशोधित की गई।
• संशोधित प्रत्येक csproj फ़ाइल ताकि snk फ़ाइल संदर्भ एक रिश्तेदार पथ (हटाता है प्रत्येक परियोजना के लिए snk फाइल कॉपी करने की आवश्यकता)

मैं पहली बार यह सब मैन्युअल रूप से किया है, लेकिन फिर महसूस किया कि यह कर सकते हैं कि एक सीधा तरीके से स्वचालित हो। पहले और तीसरे चरण को एक्सएसएलटी के साथ कार्यान्वित किया जा सकता है, जहां दूसरे चरण को रेगेक्स खोज/प्रतिस्थापन फ़ंक्शन के साथ कार्यान्वित किया जा सकता है।

चूंकि मुझे अब दो समाधान बनाए रखने की आवश्यकता है, इसलिए भविष्य में सिरदर्द से बचने के लिए इस कार्य को स्वचालित करना समझदारी है।

भंडार में स्रोत मजबूत नामों के साथ असेंबली नहीं बनाते हैं, जो ठीक है, क्योंकि मैं अंतिम उपयोगकर्ताओं पर किसी भी निर्माण प्रतिबंध या प्रक्रियाओं को लागू नहीं करना चाहता हूं।

Answer 2

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

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