मेरी प्रोजेक्ट में, मुझे इसकी निर्भरता पदानुक्रम के साथ समस्या है। मैं अपने कोड में एक लाइब्रेरी (WriteableBitmapExtensions) का उपयोग करता हूं, और मेरे पास एक और तृतीय पक्ष लाइब्रेरी है जो WriteableBitmapExtensions का भी उपयोग करती है। केवल दूसरी लाइब्रेरी एक विशिष्ट, पुराने संस्करण से दृढ़ता से बंधी हुई है, और मेरे कोड को अपने नवीनतम संस्करण में कार्यक्षमता की आवश्यकता है।तृतीय पक्ष निर्भरताओं से कई असेंबली संस्करणों को हल/उपयोग करना
यहाँ निर्भरता का चित्रण है: 
वहाँ इसी तरह के सवाल & समाधान कर रहे हैं, लेकिन वे विधानसभा एक कॉन्फ़िग फ़ाइल के माध्यम से रनटाइम पर बाध्यकारी उसका समाधान है, लेकिन मुझे नहीं लगता कि यह एक Silverlight आवेदन के लिए संगत है।
Referencing 2 different versions of log4net in the same solution
Using different versions of the same assembly in the same folder
3rd party libraries refer to different versions of log4net.dll
How to deal with multiple versions of dependencies?
तो वहाँ एक सिल्वरलाइट संदर्भ में विधानसभा निर्भरता के इन विभिन्न संस्करणों को हल करने के लिए एक रास्ता है? यदि ऐसा नहीं है, तो मुझे लगता है कि मेरे विकल्प हैं:
1) संभवतः मैं तृतीय पक्ष लाइब्रेरी के विक्रेता को लिखने योग्य बिटमैप एक्सटेंशन के नवीनतम संस्करण का उपयोग करने के लिए अद्यतन करने के लिए राजी कर सकता हूं, लेकिन मैं इस पर निर्भर नहीं होना चाहूंगा उन्हें अद्यतित रखते हुए। खासकर जब से लिखने योग्य बिटमैप एक्सटेंशन परियोजना अभी भी अपडेट की जा रही है और हम अक्सर अपनी नई सुविधाओं का लाभ उठा रहे हैं।
2) चूंकि लिखने योग्य बिटमैप एक्सटेंशन ओपन-सोर्स है, मुझे लगता है कि मैं अपने स्रोत को "MyWriteableBitmapExtensions" के रूप में एक नई असेंबली के रूप में पुन: संकलित कर सकता हूं और अपने स्रोत कोड में इसका उपयोग कर सकता हूं। लेकिन अगर मैं दो तृतीय पक्ष पुस्तकालयों को WriteableBitmapExtensions के विभिन्न संस्करणों का संदर्भ देता हूं तो मैं इस मुद्दे में फिर से भागूंगा।
मुझे संदेह है कि मैं विकल्प 2 के साथ जा रहा हूं, लेकिन मैं यह जानना चाहता हूं कि ऐसा करने का एक बेहतर तरीका है (जैसे अन्य प्रश्नों में बाध्यकारी रनटाइम असेंबली की तरह) मैं प्रतिबद्ध/रिफैक्टर से पहले। धन्यवाद!
मैंने वास्तव में इस उत्तर को लिखने के बाद केवल लिखने योग्य बिटमैप एक्सटेंशन परियोजना को देखा और अब मुझे एहसास हुआ कि आपने __v1__ के रूप में संदर्भित किया है, वास्तव में लगभग निश्चित रूप से एक _pre-beta_ संस्करण है, जो नवीनतम है __v1 beta__। तो विकल्प (1) एक विकल्प से अधिक हो जाता है - तीसरे पक्ष के विक्रेता को उपलब्ध होने पर गैर-बीटा संस्करण के साथ फिर से रिलीज होना बहुत खुश होना चाहिए। –
मैंने अब इस जवाब को फिर से संपादित किया है क्योंकि यह सिल्वरलाइट _doesn't_ समर्थन असेंबली बाध्यकारी जैसा दिखता है :-( –
हाँ, यह प्रारंभिक भी था। मुझे उम्मीद है कि यह विशेष विक्रेता अपडेट होगा; वे इस तरह से बहुत अच्छे हैं। मुझे सामान्य रूप से अन्य पुस्तकालयों के बारे में चिंता है और यह सोच रहा था कि कोई पूर्ण/उचित समाधान (जैसे असेंबली बाध्यकारी) था, खासकर जब से "ओपन-सोर्स, रीकंपाइल" विकल्प हमेशा उपलब्ध नहीं होगा, लेकिन ऐसा लगता है कि शायद ऐसा नहीं हो सकता है हो। पहचान GUIDs और मजबूत नाम को अपडेट करने के लिए नोट के लिए धन्यवाद, मैंने उनको अनदेखा कर दिया होगा। –