2012-01-16 14 views
6

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

मेरा प्रश्न स्रोत नियंत्रण में कुंजी के संग्रहण को घेरता है। जैसा कि मैं प्रत्येक रिलीज के लिए अपने कोड शाखा। कुंजी चाहिए:

ए शाखाओं के बाहर मौजूद नहीं है और branched जा - प्रत्येक शाखा के लिए प्रत्येक शाखा बी के लिए अपने ही कुंजी सुनिश्चित शाखा के भीतर मौजूद हैं, लेकिन हो सकता है एक ही सी शाखा और परिवर्तन के भीतर मौजूद प्रत्येक शाखा डी। अन्य (कृपया निर्दिष्ट करें)

सुझाव कृपया?

SolutionInfo फ़ाइल में निम्नलिखित डालकर डीएलएल पर हस्ताक्षर करने के लिए यह सर्वोत्तम प्रथा भी है या क्या कोई विकल्प है?

[assembly: AssemblyKeyFile("<<absolute path>>\\MyKey.snk")] 

उत्तर

3

अपने विशिष्ट कार्यान्वयन के आधार पर यह आम तौर पर सबसे अच्छा अभ्यास शाखा आप पर काम कर रहे में .snk कुंजी फ़ाइल रखने के लिए है।

उपयोग का मामला है: हम v1.0 और v2.0 के बीच हमारी असेंबली साइनिंग कुंजी बदल रहे हैं। आपकी शाखा (एस) में सही कुंजी के खिलाफ विकास करते समय भी आप ट्रंक में वर्तमान कोड को बनाए रखने में सक्षम होना चाहते हैं।

दूसरे

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

यह अपनी निजी कुंजी है, जो संग्रहित किया जाना चाहिए "रिलीज" के दौरान बिल्ड सर्वर (विंडोज़ कुंजी प्रबंधक में सबसे अधिक संभावना) पर संरक्षित और इस्तेमाल के प्रचार-प्रसार को रोकता है पूरी तरह से विधानसभाओं हस्ताक्षर करने के लिए बनाता है। यदि आपके पास कोई बिल्ड सर्वर नहीं है, तो यह सर्वोत्तम अभ्यास है कि निजी कुंजी के साथ सौंपा गया 1 या 2 लोगों को उस बिंदु पर वे निर्माण के बाद sn.exe के साथ असेंबली पर हस्ताक्षर कर सकते हैं। एक सरल खोल स्क्रिप्ट या बैच फ़ाइल इस प्रक्रिया को स्वचालित कर सकती है।

अन्त में, और केवल यदि आप संकेत देरी करने के लिए चुनते हैं, तो आप सभी डेवलपर वर्कस्टेशन कि/डिबग देरी पर हस्ताक्षर किए विधानसभाओं चलेंगे पर नेट विधानसभा सत्यापन सूची (sn.exe -Vr *,<publicKeyToken>) के लिए एक प्रविष्टि जोड़ने के लिए की आवश्यकता होगी। प्लेटफ़ॉर्म लक्ष्य के आधार पर आपको VS कमांड प्रॉम्प्ट के 32- और 64-बिट संस्करणों में इसे चलाने की आवश्यकता होगी।

उम्मीद है कि मदद करता है।

3

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

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